What happened
CubePilot said an attacker gained control of the cubepilot.org domain’s DNS settings on July 24, 2026, and obtained TLS certificates covering every cubepilot.org subdomain. CubePilot warned that credentials entered into affected services that day, including its portal and forum, may have been captured. The company said it regained domain control, revoked the fraudulently obtained certificates, preserved evidence and reported the incident to the Australian Cyber Security Centre and law enforcement. No actor attribution has been established.
CubePilot took OEM services, its community forum, documentation portal and ERP portal offline during the investigation. The company advised customers not to flash firmware images downloaded on July 24–25, 2026, while integrity checks continued; firmware obtained before July 24, 2026, was considered safe at the time of the notice. The cited sources did not publish malicious IP addresses, replacement domains, certificate fingerprints, file hashes or confirmed evidence that firmware was altered.
Why this matters now
DNS control combined with valid TLS certificates defeats the visual trust signals users normally rely on. A victim could reach an attacker-controlled service through the expected hostname and receive a valid HTTPS connection. Password resets must therefore extend beyond CubePilot where credentials were reused, and identity teams should review subsequent authentication events rather than treating the reset itself as proof that misuse did not occur.
The firmware warning creates a supply-chain decision for operators of unmanned systems. CubePilot has not confirmed that images were modified, but it has explicitly withheld confidence in downloads from the affected period. Organisations should quarantine those files, compare them with supplier-published trusted hashes when available and prevent deployment until integrity is established. Operational urgency must not override provenance controls.
The decision for security leaders
Identify users who accessed CubePilot services during the stated window and force resets for portal, forum and any reused credentials. Review authentication logs for anomalous locations, devices, reset attempts and privilege changes. Finance and procurement should independently verify invoices, banking changes and payment requests using established telephone contacts rather than email or portal messages.
Drone and embedded-systems teams should inventory firmware acquired during the affected period, quarantine copies and record whether any image was deployed. Where deployment occurred, obtain supplier guidance and compare device state with a trusted baseline. Require CubePilot to provide validated hashes, certificate and DNS remediation evidence, affected-service scope and notification criteria before normal trust is restored.
Evidence of closure
- Password-reset records cover all identified CubePilot users.
- Quarantined firmware matches supplier-validated cryptographic hashes.
- Payment controls require out-of-band supplier verification.
- Supplier assurance confirms restored DNS and certificate control.
The Security.io assessment
The confirmed compromise concerns DNS and certificate control, with a credible risk of credential interception. Public evidence does not establish that firmware was modified, so organisations should not describe deployed devices as compromised solely because an image was downloaded. The correct posture is quarantine, validation and heightened identity monitoring while the supplier completes its investigation.
This incident illustrates why third-party assurance must cover domain registrars, DNS administration and certificate issuance, not only source-code and build security. Our assessment changes materially if CubePilot publishes evidence of modified firmware, identifies misuse of intercepted credentials or confirms customer-specific traffic capture. Until then, the highest-confidence actions are credential resets, out-of-band transaction verification and software provenance checks.
Questions for the morning meeting
- Which operational systems rely on CubePilot downloads or portals?
- Did any user reuse a CubePilot password elsewhere?
- Can firmware provenance be verified independently?
- Are supplier payment changes always confirmed out of band?