CubePilot, an Australian firm designing autopilots and navigation hardware for unmanned aerial vehicles, disclosed that an attacker seized control of the cubepilot[.]org domain’s DNS settings on July 24, 2026. The attacker obtained TLS certificates covering every subdomain, meaning any user visiting CubePilot’s services during the attack window saw a valid HTTPS padlock while connected to attacker-controlled infrastructure. Credentials entered on any CubePilot service — including the customer portal and community forum — on July 24 may have been captured. CubePilot reported the incident to the Australian Cyber Security Centre and law enforcement.
How the DNS Hijacking Enabled Credential Interception
DNS hijacking at the registrar level is one of the most effective credential-collection techniques available to attackers because it does not require compromising any system the target organization controls. By altering the DNS records for cubepilot[.]org to point to attacker-controlled servers, the attacker redirected all traffic intended for CubePilot’s web services to their own infrastructure. Users attempting to reach the customer portal or community forum were silently redirected without any visual indication of the substitution.
The TLS certificates covering every cubepilot[.]org subdomain are the critical detail. HTTPS connections display a padlock and the correct domain name in the browser’s address bar — the standard visual cue users rely on to confirm they are connected to a legitimate service. Because the attacker obtained valid TLS certificates for the entire subdomain namespace, that padlock appeared on every attacker-controlled page. Users who entered usernames and passwords on these pages had no technical means to detect the interception through normal visual inspection.
Which Services Were Exposed and for How Long
The attack occurred on July 24. CubePilot regained control of the domain on July 24, meaning the exposure window was confined to that day. However, the attacker’s window — even a single day — is sufficient to capture any credentials entered by active users of the customer portal and community forum during that period.
CubePilot also warned that firmware images downloaded on July 24–25 are under evaluation for tampering. Firmware obtained before July 24 is considered safe. The company took down its ERP portal as a precautionary measure alongside the other affected services. All OEM services, the community forum, and the documentation portal remain offline as investigation and recovery continue.
CubePilot’s Defense and Government Exposure
CubePilot’s products are not purely commercial. The company designs autopilots used in drones for surveying, search and rescue, agriculture, defense, and government applications. CubePilot has publicly supported Ukraine, and the company’s products have been delivered there as part of Australian government assistance. That context raises the stakes of the DNS hijacking beyond a standard commercial incident: the customer base includes defense-sector operators, government agencies, and military-adjacent organizations for whom credential compromise could have consequences beyond a typical B2B vendor breach.
Firmware Integrity Questions in a Defense-Adjacent Supply Chain
The advisory that firmware downloaded on July 24–25 is under evaluation — rather than confirmed safe — adds a supply chain dimension to the incident. Firmware for drone autopilots is a high-value tampering target: modified firmware could alter navigation behavior, disable safety systems, or introduce backdoor communication channels accessible to an attacker. CubePilot has not confirmed that any firmware tampering occurred, and the explicit statement that firmware before July 24 is safe implies that tampering is being actively investigated as a possibility rather than ruled out.
For defense-sector customers who downloaded firmware on July 24 or 25, the appropriate response is to treat those downloads as potentially compromised until CubePilot issues a definitive finding. Devices running firmware from that window should not be deployed on sensitive missions until the firmware’s integrity is confirmed.
Response and What Affected Users Should Do
CubePilot revoked the fraudulently issued TLS certificates and preserved forensic evidence in coordination with ACSC and law enforcement. The company advises all users to change passwords used on CubePilot services, with particular urgency if those passwords were reused across other platforms. Password reuse is the primary downstream risk: if a captured CubePilot credential matches a credential used on another service, the attacker’s access extends beyond CubePilot’s platform to any reused account.
CubePilot also warned customers to verify any payment requests by phone before acting on them — a standard advisory when credentials to financial-adjacent portals may have been captured, given the risk of fraudulent invoices or payment-redirect attacks directed at customers who logged in during the compromise window.
