Skip to content
Braincap
← All articles

CubePilot hit by DNS hijacking: when the "green padlock" can hide an attacker

by Claudiu Hulea · IT Management Consultant

Illustration of a DNS hijacking attack redirecting traffic to an attacker server

On July 24, 2026, Australian drone autopilot maker CubePilot was hit by a DNS hijacking attack: attackers took control of the DNS records for the cubepilot.org domain, obtained fraudulent TLS certificates for all subdomains, and redirected users to their own servers — with a seemingly valid HTTPS “green padlock.” It’s a textbook case for an uncomfortable lesson: the DNS and domain layer is critical infrastructure, and a “valid” HTTPS connection doesn’t guarantee you’re talking to who you think.

In brief

  • Who is CubePilot? A maker of flight controllers and autopilots for drones (UAVs) used in surveying, search-and-rescue, agriculture and defense/government applications.
  • What happened: DNS hijacking of cubepilot.org (July 24, 2026) — DNS records redirected to the attacker’s infrastructure.
  • Aggravating factor: the attackers obtained fraudulent TLS certificates covering all subdomains → “valid” HTTPS connections to servers they controlled (man-in-the-middle).
  • Affected services: portal, community forum, documentation platform, OEM services, ERP system.
  • Response: domain control was regained the same day, certificates were revoked, evidence preserved; services stayed offline during the investigation. The incident was reported to the Australian Cyber Security Centre (ACSC).

How DNS hijacking works

DNS is the internet’s “phone book”: it translates a name (cubepilot.org) into a server address. Whoever controls a domain’s DNS records can send every visitor to their own server, without breaking into the real one. And if the attacker also manages to issue TLS certificates for the domain, the browser shows the padlock and “secure connection” — even though the attacker’s server is behind it. The result: a man-in-the-middle that looks perfectly legitimate.

What could be intercepted

  • Credentials entered on July 24 on the portal and the forum.
  • Firmware downloads: CubePilot advised not to flash images downloaded on July 24–25 pending integrity verification; firmware from before July 24 remains safe.

Here’s the crux: drone firmware is a supply-chain component — a compromised image served from a fake server would land directly on users’ equipment.

Why it matters to you

  • The attack is upstream of your infrastructure. You don’t have to be “breached” on the server to be affected — compromising DNS or the registrar account bypasses every defense inside the application.
  • The HTTPS padlock doesn’t guarantee identity if the attacker can issue their own certificates for the domain. Visual trust (“it’s https, so it’s fine”) is not enough.
  • Compromised firmware/artifacts are a direct supply-chain channel to the end customer.

What to do

If you’re a CubePilot user:

  1. Change your passwords, especially if you reused them elsewhere.
  2. Don’t flash firmware downloaded on July 24–25; use only verified images.
  3. Verify by phone any payment request, with a known contact.

Lessons for any organization with its own domain:

  1. Protect the registrar and DNS account — 2FA, “registrar lock,” and DNSSEC where possible.
  2. Monitor certificates issued for your domains via Certificate Transparency — a new, unexpected certificate is a warning sign.
  3. Sign your firmware and artifacts and publish signatures/hashes so users can verify integrity independently of the download channel.
  4. Alert on DNS changes — record modifications should trigger notifications.

The takeaway

DNS and the registrar sit at the foundation of your online identity — they are the “keys to the kingdom,” and compromising them bypasses everything you built at the application layer. The real defenses are upstream: registrar lock + DNSSEC, Certificate Transparency monitoring, and artifact signing. A security audit checks exactly these points — your domain, DNS and delivery-chain configuration — and a penetration test confirms where an attacker could catch you.

Sources

Frequently asked questions

What happened to CubePilot?

On 24 July 2026, drone autopilot maker CubePilot was hit by DNS hijacking: attackers took over the DNS records for the cubepilot.org domain, obtained fraudulent TLS certificates for all subdomains, and redirected users to their own servers, with a seemingly valid HTTPS "green padlock" (man-in-the-middle).

Why isn't the HTTPS "green padlock" enough?

Because the padlock only confirms an encrypted connection, not the server's real identity. If the attacker controls the DNS and can issue their own certificates for the domain, the browser shows "secure connection" even though the attacker's server is behind it. Visual trust ("it's https, so it's fine") is not enough.

Why does it concern me, even if I'm not a CubePilot user?

Because the attack is upstream of your infrastructure: compromising DNS or the registrar account bypasses every defense inside the application — you don't have to be "breached" on the server to be affected. Any organization with its own domain has the same exposure.

How do I protect my domain from DNS hijacking?

Protect the registrar and DNS account (2FA, registrar lock, DNSSEC), monitor certificates issued for your domains via Certificate Transparency (a new, unexpected certificate is a warning sign), sign your firmware and artifacts with published signatures/hashes, and alert on any change to DNS records.