The CubePilot DNS hijacking incident highlights a serious supply-chain and infrastructure-security risk: when attackers control DNS, they can redirect trust itself.

CubePilot is an Australian company that develops flight controllers, autopilot hardware, and related software used in drones and unmanned aerial vehicles. Its products are used in areas such as surveying, agriculture, search and rescue, government, and defense-related applications. That makes the incident more sensitive than an ordinary website outage.

The reported attack involved unauthorized control of CubePilot’s domain DNS settings. DNS is the system that tells browsers and devices where a domain should connect. If attackers gain control of DNS records, users may type the correct domain name and still be sent to attacker-controlled infrastructure.

That is the dangerous part. The user may not click a suspicious link, visit a fake-looking domain, or ignore obvious warning signs. They may visit the legitimate CubePilot domain, but because DNS has been hijacked, the traffic can be silently redirected elsewhere. Apparently, even typing the correct address now needs a threat model. Lovely progress.

The incident became more serious because the attacker reportedly obtained TLS certificates covering CubePilot subdomains. TLS certificates are what make the browser show a valid HTTPS connection. If an attacker controls DNS and obtains valid certificates, users may see the expected secure-lock behavior while still connecting to malicious infrastructure.

This breaks a common user assumption. Many people believe that HTTPS means the site is safe. In reality, HTTPS mainly confirms that the browser has a valid encrypted connection to the domain presented by the certificate. If attackers manage to control the domain’s DNS and certificate path, HTTPS can protect the encrypted connection to the wrong destination. A locked door is not helpful if someone moved the house.

CubePilot warned that credentials entered into affected services on July 24 may have been captured, including portal and forum credentials. Users who logged in during the affected period should change their CubePilot passwords immediately. If the same password was reused anywhere else, it should be changed there too.

Password reuse is especially dangerous in this scenario. A stolen portal or forum password may seem limited, but if that password is reused for email, GitHub, cloud services, vendor portals, forums, business apps, or infrastructure tools, attackers can attempt credential stuffing against other accounts. One compromised password should never become a master key across unrelated systems.

The firmware warning is also important. CubePilot advised users not to flash firmware images downloaded on July 24 to 25 until integrity checks confirm safety. This is a serious supply-chain concern. If attackers had an opportunity to redirect download traffic, users may need to verify whether firmware files, software tools, documentation links, installers, update files, or checksums were accessed from legitimate sources.

For drone and embedded-device ecosystems, firmware integrity is critical. A malicious or tampered firmware image can create risks far beyond an infected laptop. It may affect device behavior, telemetry, navigation, command handling, communication, safety controls, data collection, or operational reliability.

Users should avoid installing or flashing any firmware downloaded during the affected window unless CubePilot confirms its integrity. They should redownload firmware only from verified official channels after the company completes its checks and service restoration.

Organizations using CubePilot products should inventory any devices, firmware files, update packages, configuration downloads, portal credentials, forum credentials, and operational documents obtained during the affected period. Any downloaded files should be compared against vendor-published hashes or replaced with freshly verified copies.

For customers operating drones in sensitive environments, including government, defense, critical infrastructure, emergency services, mapping, or industrial monitoring, the response should be more disciplined. Devices should not be updated using potentially affected firmware. Operational teams should verify software provenance, review recent configuration changes, and document which assets may have interacted with CubePilot services during the incident window.

The risk of traffic interception also means users should consider what data may have been transmitted during the DNS hijack. This could include login credentials, session cookies, API tokens, support portal data, forum messages, downloads, update requests, billing or ERP interactions, and other account-related information.

If a user entered payment details or acted on payment instructions during the affected period, those actions should be verified directly through known CubePilot contacts. CubePilot also advised customers not to act on payment requests claiming to be from the company without confirming by phone with their usual contact.

That is sensible guidance because DNS hijacking can support invoice fraud and payment redirection. If attackers can convincingly impersonate a trusted vendor portal or service, they may attempt to send altered payment instructions, fake invoices, or urgent account notices. A real domain and a valid certificate can make this type of fraud much harder to spot.

For businesses, this incident is a reminder that DNS is part of the security perimeter. DNS records, registrar accounts, domain administration portals, certificate issuance paths, and hosting records must be protected like critical infrastructure. They are not boring administrative settings. They decide where customers, users, software, and automated systems connect.

Organizations should protect domain registrar accounts with strong multifactor authentication, phishing-resistant authentication where available, role-based access control, hardware security keys for privileged users, domain locking, registry lock, change approvals, and alerting on DNS changes.

DNS change monitoring is essential. Security teams should receive immediate alerts when nameservers, A records, CNAME records, MX records, TXT records, certificate validation records, or other critical DNS entries are modified. DNS changes should be logged, reviewed, and tied to approved change records.

Certificate transparency monitoring should also be used. Organizations should monitor for newly issued certificates covering their domains and subdomains. If attackers obtain fraudulent or unexpected certificates, rapid detection can reduce the time available for traffic interception.

Subdomain inventory matters too. Attackers often look for forgotten subdomains, stale DNS records, abandoned cloud services, expired third-party integrations, and unmanaged infrastructure. A trusted domain is valuable even when the underlying service has been forgotten. The internet, naturally, never forgets your old CNAME records. It just waits for someone worse to notice them.

Organizations should also review domain recovery processes. If DNS is hijacked, response must be fast: regain registrar control, revoke fraudulent certificates, restore correct DNS records, notify certificate authorities, preserve logs, notify affected users, rotate credentials, validate downloads, and communicate clearly.

Credential rotation should be part of the response. Users who logged into affected CubePilot services during the incident window should change passwords. Administrators should also rotate tokens, API keys, portal credentials, support accounts, and any integration secrets that may have traversed the affected services.

Session invalidation is equally important. If session cookies were captured, password resets alone may not be enough. Services should revoke active sessions, invalidate exposed tokens, and require fresh authentication after recovery.

For vendors distributing firmware or software, signed updates are critical. Firmware and software packages should be digitally signed, and devices or update tools should verify signatures before installation. TLS protects transport, but code signing protects the artifact itself. If download traffic is redirected, signature verification can still prevent installation of tampered binaries.

Customers should also verify hashes and signatures for downloaded firmware where available. In high-risk environments, firmware should be downloaded through controlled systems, stored in internal repositories, scanned, validated, and approved before deployment to field devices.

This incident also shows why supply-chain trust includes more than source code. DNS, certificates, update servers, firmware portals, documentation sites, support portals, ERP systems, forums, and customer communication channels are all part of the trust chain. Attackers do not care which link is “supposed” to be security-critical. They care which link can be abused.

For drone ecosystems, the stakes can be higher because software trust affects devices operating in the physical world. A compromised update path or credential portal can influence systems used for navigation, telemetry, mission planning, mapping, inspection, or field operations.

The key lesson is that DNS hijacking can convert a trusted brand domain into attacker-controlled infrastructure. When combined with valid TLS certificates, the attack becomes especially deceptive because users may see a secure connection while still being intercepted.

CubePilot users should change passwords used during the affected period, avoid reusing credentials, verify any payment requests by phone, avoid flashing firmware downloaded on July 24 to 25 unless validated, and redownload critical files only after official integrity confirmation.

Organizations should use this incident to review DNS security, registrar protections, certificate monitoring, signed firmware validation, domain-change alerts, credential rotation, and software supply-chain controls.

DNS is not just plumbing. It is the map that tells users and devices where trust lives. If attackers can rewrite that map, even careful users can be led to the wrong destination while believing they did everything right.

CubePilot, an Australian firm that designs flight controllers for drones (UAVs), announced a severe operational disruption caused by a DNS hijacking attack. [...]

Source: CubePilot drone software dev hit by DNS hijacking to intercept traffic via Bleeping Computer — published 28 Jul 2026.