CubePilot takes drone services offline after attacker hijacks DNS and TLS
CEO Philip Rowse warned users to change reused passwords and avoid firmware downloaded July 24th-25th while CubePilot verifies published images.
By Ryan Merket · Published
Why it matters
CubePilot's breach reached the trust layer around drone hardware: valid certificates, customer credentials and firmware distribution. Its checksum review will determine whether the incident remained an account compromise or touched aircraft software.

CubePilot, led by CEO Philip Rowse, took its firmware, documentation, community forum and OEM services offline after an attacker seized control of its domain-name settings and obtained valid security certificates for every cubepilot.org subdomain.
The attacker controlled CubePilot's DNS for part of July 24th and used it to intercept traffic intended for internal business systems, according to CubePilot's security notice. Credentials entered into the portal, forum or other affected services that day may have been captured. BleepingComputer reported that the certificates would have allowed attacker-controlled services to display valid HTTPS connections.
CubePilot regained control of the domains and restored its nameservers on July 24th, then revoked the fraudulently issued certificates. As of July 29th, CubePilot's notice still marked the incident as open. Reseller and OEM ordering, quotes and support remained offline, along with the documentation portal and community forum. Firmware checks were still in progress. Email on cubepilot.com was operating.
The incident reaches into a sensitive part of the drone component stack. CubePilot supplies flight controllers, navigation hardware and related systems used to configure and operate uncrewed aircraft. Those products serve commercial applications including surveying and agriculture, alongside government and defense deployments. A breach of the channels used to distribute firmware and technical instructions creates a different class of risk from a conventional corporate-site compromise.
A trusted connection to the wrong server
DNS converts a domain such as cubepilot.org into the network address a user's computer contacts. Control of those records allowed the attacker to direct CubePilot traffic to infrastructure outside CubePilot's control. The valid TLS certificates removed a warning that might otherwise have alerted users: browsers could show a normal encrypted connection while sending information to the attacker's server.
CubePilot has told anyone who entered credentials on July 24th to change reused passwords. It also warned customers to treat requests for passwords, verification codes or payment details as hostile, and to confirm changed bank details or payment requests by calling their usual CubePilot contact.
Those instructions point to two immediate risks. The first is credential reuse, which can turn one captured password into access to unrelated corporate systems. The second is invoice fraud against resellers and drone manufacturers already accustomed to receiving quotes, support messages and payment instructions through CubePilot's business infrastructure.
CubePilot said it preserved evidence, notified relevant service providers, reported the incident to the Australian Cyber Security Centre and referred it to law enforcement. CubePilot is working through which data was reachable during the unauthorized-access period.
Firmware verification sets the stakes
The most consequential review concerns firmware images downloaded on July 24th and July 25th. CubePilot instructed users to avoid flashing those files while it verifies checksums for every published image. CubePilot considers images obtained before July 24th unaffected.
The warning does not establish that firmware was altered. It shows that CubePilot cannot yet rely on the affected distribution path as proof that users received the files CubePilot intended to publish. Checksum verification should determine whether the downloadable images match known builds.
That distinction matters for autopilot hardware. Firmware can govern sensors, navigation, communications and flight behavior. A corrupted business portal can expose accounts and invoices; a compromised firmware image could cross from information systems into an aircraft. CubePilot's current evidence establishes intercepted traffic and possible credential theft. The firmware review is the control that separates that confirmed incident from a possible software supply-chain compromise.
Rowse built his career around the hardware now under review. ArduPilot's commercial-support directory credits him with years of autopilot design work, including the Pixhawk 2.1, sold as the CubePilot CubeBlack and used in the 3DR Solo. The Pixhawk project lists CubePilot as the current manufacturer of the Pixhawk 2 design.
CubePilot also has deep ties to the open-source software used by drone builders. Rowse said in a 2024 CubePilot forum post that fellow director Michael Oborne is part of CubePilot Global. Oborne created Mission Planner, the open-source ground-control application used to configure and operate ArduPilot aircraft. The Mission Planner repository contains thousands of commits and documents dependencies on multiple firmware, update and support services.
That history gives CubePilot credibility among engineers who assemble aircraft from interoperable hardware and open-source software. It also concentrates trust in documentation, downloads, forums and support systems that sit outside the aircraft itself. Builders need those services to configure boards, resolve faults and decide which software to install.
Drone supply-chain scrutiny moves up the stack
CubePilot has spent years positioning its manufacturing and ownership for government and defense buyers. Rowse wrote in 2024 that CubePilot Global had moved operations to Australia and Taiwan, with most products made in Taiwan or the US. CubePilot Global is an active Australian private company registered from July 2023, according to the Australian Business Register.
Hardware provenance is only one part of that procurement case. The July 24th incident shows that control over domains, certificate issuance, firmware hosting and customer portals can become equally important. A trusted circuit board can still receive software or instructions through a compromised distribution channel.
CubePilot's response reduced the immediate exposure by restoring the nameservers, revoking certificates and shutting services down. The operational cost is visible: customers cannot use normal ordering, documentation or support channels while verification continues. For a specialist supplier serving drone manufacturers, resellers and government-linked programs, those channels are part of the product. Their security determines whether customers can trust the hardware after it leaves the factory.