ASEC
Closing the Exposure Window00
Research 08.10.2026 9 min read

Infected Drones: when the aircraft attacks the ground station.

UASGCSDisclosure

Six ground-control and middleware projects, fifteen findings, one broken trust boundary. A compromised drone does not have to stay on the vehicle — it can reach up the command chain and own the operator.

Drone operations stopped being one pilot, one aircraft a while ago. A handful of operators now supervise dozens or hundreds of vehicles from a few ground control stations. That shifts where the value sits. The ground station is where the operator works, where mission data lives, where a full desktop operating system runs, and where every other aircraft in the fleet is one link away.

Almost all drone security research — ours included — has pointed at the vehicle. Infected Drones turns it around and asks a different question: once a single aircraft is compromised, what can it do to the station that connects to it?

06GCS and middleware projects audited
15Findings, one root cause
10Fixes filed upstream

One trust boundary, six projects

We audited six widely used independent projects across the MAVLink ecosystem: QGroundControl, Mission Planner, MAVSDK, MAVProxy, MAVROS and DroneKit. They are written by different teams, in different languages, for different jobs. They share the same assumption: whatever arrives from the vehicle is trustworthy.

MAVLink gives a vehicle a lot to say. It announces its cameras and their names, points the ground station at metadata and camera-definition files, serves directory listings and logs over MAVLink-FTP, streams parameter names and free-text status messages. Each of those fields is attacker-controlled the moment the vehicle — or anything on its bus — is not what it claims to be. In all six projects, at least one of them reached a file path, a URL fetcher, a parser or a shell without being validated first.

What goes wrong

Fifteen findings, but only a few shapes. Each one is the same mistake meeting a different sink.

  • The vehicle names a file and the GCS writes it. Camera names, MAVLink-FTP directory entries and metadata URIs end up as part of an output path without being reduced to a bare filename. The result is file writes — or file destruction — outside the directory the application meant to use. QGroundControl, Mission Planner and MAVSDK.
  • The vehicle supplies a URL and the GCS fetches it. Metadata and camera-definition URIs are fetched with no scheme allow-list, turning the ground station into a server-side request forger on the operator’s network, and in some cases a local file reader. QGroundControl and MAVSDK.
  • Vehicle text reaches something that executes. A status message rendered as a clickable link that is handed to the operating system shell, with a label that does not have to match its target. A video-stream URI handed to a media pipeline that can read and write files. Mission Planner.
  • Parsers that trust vehicle-supplied lengths. Flight-log records and FTP replies whose length fields are believed, leading to out-of-bounds reads, process memory returned to the sender, endless loops and crashes. QGroundControl and MAVROS.
  • Unbounded resources. A compressed camera definition with no decompression limit — roughly 150 KB on the wire became 1 GiB on disk, and it stays in the cache. A parameter map with no cap. A value typed as a float where the UI thread expects an integer, crashing the station on connect. MAVSDK, MAVROS and Mission Planner.
  • Libraries that hand the problem on. DroneKit passes raw parameter names and status text straight to application callbacks. That is a documented trust boundary rather than a library bug, but every application built on it inherits the job of validating that data.

From a file write to the operator’s workstation

Two of the findings go all the way to code execution on the operator’s machine, and both are file-write bugs that land somewhere the system later runs.

  • QGroundControl 5.1.0 – 5.1.4 on Windows — zero-click, CVSS 9.8. The component-metadata download path lets a vehicle-supplied value decide where a downloaded file is saved. Chained with the metadata translation step, the file survives and runs as the operator at next logon. It fires on connection; the operator does nothing. It is a regression introduced in 5.1 and does not affect 5.0.x or 4.4.x.
  • Mission Planner on Windows — one click, CVSS 8.8. A vehicle-supplied MAVLink-FTP filename escapes the download folder. Mission Planner compiles and loads plugin source files from its own directory at start-up, with no signature check, so one Download click becomes code execution on the next launch. The upload path in the same file already strips directory components correctly. The download path simply does not.

Neither needs the attacker to touch the ground station directly. Both need only that the operator connects to the wrong aircraft.

How the bad data arrives

Some findings need nothing more than a single frame reaching the station. Others need the attacker to be the conversational peer — to answer a file listing or a log download. Which ones are reachable depends on the delivery path:

  • An infected flight controller: a demo unit, a rental, a second-hand or seized airframe with implanted firmware. That includes forensic analysts who plug a recovered vehicle into their own workstation to pull its logs.
  • A malicious or counterfeit peripheral on the vehicle’s own bus — a camera, gimbal, ADS-B receiver or rangefinder that speaks MAVLink.
  • A compromised companion computer running mavlink-router or MAVProxy.
  • A Wi-Fi or UDP telemetry bridge.
  • A TCP or cloud relay between the vehicle and the station.
  • The radio itself. A SiK telemetry radio is a transparent serial bridge; it does not parse MAVLink and, by default, does not encrypt it. One rogue radio is enough for the single-frame findings; a rogue pair in the middle owns the whole conversation. Our SiKW00F toolkit works on that link.

For maintainers

The fixes are small and they are the same fixes, which is the encouraging part. If you maintain anything that speaks MAVLink to a ground station:

  • Treat every string from the vehicle as untrusted input: names, URIs, parameter IDs, status text, FTP listings, log headers.
  • Never let a vehicle-supplied value become a path. Reduce it to a bare filename, reject separators and traversal, then confirm the resolved path is still inside the directory you intended.
  • Allow-list URI schemes and hosts before fetching anything a vehicle points you at. A CRC supplied alongside the URI is a cache key, not an integrity check.
  • Bound everything: string lengths, record lengths against the bytes actually received, decompressed sizes, map sizes, loop iterations.
  • Never hand vehicle data to a shell, a media pipeline description or a plugin loader. Show it; do not execute it.
  • Enable MAVLink 2 message signing and make the station fail closed when the peer does not sign.

For operators

  • Update QGroundControl, Mission Planner, MAVSDK and MAVROS as these fixes land, and watch the projects’ security advisories.
  • Do not connect an unknown, second-hand, rented or recovered aircraft to your primary ground station. Use an isolated, disposable machine for anything you did not build yourself.
  • Run the ground station as a standard user, not an administrator.
  • Load only the GCS modules you need. Several of these findings live in optional features.
  • Treat the telemetry link as an untrusted network interface, because that is what it is.

Disclosure

Every finding was reported to its project. Ten of the fifteen ship with a patch we filed against the vendor’s own repository — four for QGroundControl, four for Mission Planner and two for MAVSDK. One MAVProxy finding was reported and fixed independently by another researcher before we got to it, and is credited to them. Status for each finding is tracked in the research repository.

Proof-of-concept code is deliberately left out of this post while fixes make their way into releases.

See the talk

Infected Drones: How Compromised Autonomous Systems Pwn Ground Control Stations is being presented at the PX4 Developer Summit at Open Source Summit Europe in Prague (8 October 2026), at No Hat 2026, and at Nullcon Berlin (5–6 November 2026). If you maintain one of these projects and want to talk through a fix, get in touch.

Same stack. Different aircraft.

If this reads like something in your programme, it probably is. Send us the architecture and we'll come back with a scope.

Talk to us

Research
02.09.2026

Damn Vulnerable Drone: a whole aircraft you are allowed to break.

The training range we build and maintain in the open — a simulated airframe, ground station, and radio link, free for anyone learning to attack autonomous systems.

4 minRead →
Research
19.08.2026

MAVLink without a seatbelt.

A field study of telemetry links across eleven commercial aircraft, and what it takes to fly one from the ground.

12 minRead →
Research
22.07.2026

Signed, but not verified.

Four vendors shipped secure boot with signature checks that never ran. We show the extraction, the patch, and the fix.

14 minRead →