CubePilot's Domain Seized, Firmware Channels at Risk
On July 24, 2026, unknown threat actors seized control of DNS records for cubepilot.org, the primary domain of CubePilot — an Australian company that manufactures the Cube series of flight controllers, widely deployed across commercial UAVs, research drones, and defence-adjacent platforms.
By gaining control of the domain's DNS delegation, the attackers redirected traffic intended for CubePilot's website, ERP portal, and firmware distribution endpoints to attacker-controlled infrastructure. Critically, the attackers also obtained valid TLS certificates covering all cubepilot.org subdomains — meaning any user who connected to the hijacked pages would have seen browser-trusted HTTPS connections with no certificate warnings, making impersonation effectively undetectable to end users.
CubePilot CEO Philip Rowse confirmed the incident via LinkedIn and issued urgent warnings to the drone operator community. The company's ERP portal was taken offline as a precautionary measure.
Why This Attack Is Especially Dangerous
DNS hijacking of a hardware manufacturer is particularly severe when that company distributes firmware to safety-critical systems.
The Firmware Supply Chain Risk
CubePilot hosts firmware images for its flight controllers — devices running ArduPilot and PX4, the two dominant open-source autopilot frameworks used in commercial UAV fleets worldwide. If the attackers served a trojanized firmware image through the hijacked domain during the July 24–25 window, affected operators could unknowingly install malicious firmware that:
- Alters flight behaviour or disables safety systems
- Enables persistent remote access to the UAV's flight computer
- Exfiltrates telemetry data to attacker-controlled servers
- Triggers failure conditions at a time of the attacker's choosing
CubePilot has explicitly warned operators not to flash any firmware downloaded on July 24–25, 2026. Firmware obtained before July 24 is considered safe.
The Invoice Fraud Angle
Rowse's LinkedIn warning also cautioned that any payment requests or invoices purportedly from CubePilot during the incident window should be verified by phone with a known CubePilot contact before action is taken. This suggests business email compromise or invoice fraud may have been a secondary objective — a common tactic when attackers gain control of a company's domain and can intercept inbound email.
How DNS Hijacking Works at This Scale
The exact attack vector for the initial DNS seizure has not been confirmed. Likely scenarios include:
| Vector | Description |
|---|---|
| Registrar account compromise | Credential theft or phishing targeting the registrar account, bypassing MFA |
| BGP route hijacking | Manipulating routing to intercept DNS resolution traffic upstream |
| Registrar support abuse | Social engineering registrar support staff to reassign DNS delegation |
The subsequent TLS certificate issuance for all subdomains indicates the attackers used an automated certificate authority (likely Let's Encrypt via the ACME protocol), which requires only proof of DNS control — not domain ownership verification via human review. This is by design for automation purposes, but means any attacker with DNS control can quickly obtain trusted certificates.
Timeline:
Jul 24 — Attackers gain control of cubepilot.org DNS
Jul 24 — Attacker-obtained TLS certs issued for all subdomains
Jul 24-25 — Traffic to cubepilot.org infrastructure redirected to attacker servers
Jul 25 — CubePilot ERP portal taken offline
Jul 25-28 — CubePilot works to recover DNS control and revoke attacker certs
Jul 28 — Public disclosure and operator warnings issued
What Drone Operators Should Do
Immediate Actions
- Do not flash any firmware downloaded from cubepilot.org on July 24 or 25, 2026
- Verify payment requests attributed to CubePilot by phone using a known contact number — do not rely on contact details from emails received during the incident window
- Rotate credentials if you authenticated to any CubePilot portal during July 24–25
- Check your UAVs — if firmware was flashed from the incident window, ground the aircraft and contact CubePilot directly for integrity guidance
- Monitor CubePilot's official channels for confirmation that firmware distribution has been restored and certified safe
For Fleet Operators
If your organisation operates a fleet of CubePilot-based UAVs, treat any aircraft that had firmware updated during July 24–25 as potentially compromised until CubePilot provides cryptographic integrity confirmation for those images.
The Broader Implications
This attack underscores a systemic risk in the drone industry: firmware update channels are rarely cryptographically signed end-to-end, relying primarily on HTTPS integrity (TLS) for authenticity. When an attacker obtains trusted TLS certificates through DNS control — a realistic threat model — TLS alone provides no protection against firmware substitution.
The drone industry's response to this class of threat will likely accelerate interest in:
- Code-signing for firmware images with manufacturer-held private keys, independent of DNS/TLS
- In-aircraft firmware verification against manufacturer-published hashes before installation
- Certificate transparency monitoring — alerts when unexpected certs are issued for a domain
- Registrar-level 2FA and registry lock (registrar lock prevents DNS changes without out-of-band confirmation)
CubePilot's recovery path requires regaining registrar control, purging attacker DNS records, revoking the attacker-obtained TLS certificates via CA revocation, and auditing ERP logs for data access.
References
- BleepingComputer — CubePilot Hit by DNS Hijacking
- CubePilot Official Statement via Philip Rowse / LinkedIn