Millions of drones run PX4. That includes research platforms, commercial inspection aircraft, emergency response systems, and military-adjacent projects. It is one of the most widely deployed open-source flight controllers on the planet, and last week it got a serious problem.
The US Cybersecurity and Infrastructure Security Agency (CISA) has issued an official advisory for CVE-2026-1579, a critical vulnerability in PX4 Autopilot software. The flaw scores 9.8 out of 10 on the Common Vulnerability Scoring System. For context, a 10 is about as bad as it gets. This is not a theoretical edge case. CISA classified it as a high-risk threat affecting the Transportation Systems, Emergency Services, and Defense Industrial Base sectors.
The short version: an attacker on the same network as a PX4-powered drone can send it commands, hijack its flight path, and potentially bring it down. No credentials required.
What Is PX4 Autopilot?
PX4 is an open-source flight controller software stack maintained under the Dronecode project, which sits under the Linux Foundation. Development started in 2009 at ETH Zurich and has grown into one of the most capable and widely used autopilot platforms in the world.
Unlike proprietary systems baked into consumer drones, PX4 is an open platform. It supports multirotors, fixed-wing aircraft, VTOL configurations, ground rovers, and even underwater vehicles. Developers, universities, startups, and enterprise operators all use it. You will find it running on everything from hobbyist racing frames to commercial survey drones to research platforms testing autonomous flight algorithms.
It communicates using MAVLink, a lightweight messaging protocol designed specifically for UAV control. Think of MAVLink as the language spoken between a drone and its ground control station. Every command, from “go here” to “land now” to “return to home,” travels over MAVLink.
That protocol is where the problem lives.
The Actual Flaw: No Authentication by Default
MAVLink 2.0 introduced message signing in 2016. When enabled, signing ensures that every command sent to a drone carries a cryptographic signature that the aircraft can verify. If a command lacks a valid signature, the drone ignores it. Simple, effective.
The problem is that PX4 ships with this feature turned off by default.
That means any device that can reach the MAVLink interface on UDP ports 14550 or 14540 can send commands to the drone. No handshake. No authentication. The drone accepts whatever it receives.
CYVIATION, the aviation cybersecurity firm that discovered the vulnerability, describes the attack chain plainly. An attacker identifies the MAVLink interface on the network, crafts MAVLink packets containing arbitrary shell commands, sends them to the autopilot, and the drone executes them at the operating system level. This is remote code execution on a flying vehicle.
The affected version confirmed by CISA is PX4 Autopilot v1.16.0_SITL_latest_stable, though security researchers note that any PX4 deployment running standard MAVLink without signing enabled is potentially exposed.
Who Should Actually Be Worried?
If you fly a consumer DJI drone, this does not affect you. DJI runs its own proprietary firmware and protocols. Same goes for Autel and most other consumer brands.
This vulnerability matters to a specific and growing group:
Commercial drone operators running PX4-based platforms for inspection, surveying, or agriculture. Many enterprise drones in this space are built on open hardware and software stacks, including PX4.
Developers and researchers using PX4 for simulation, testing, and prototype flights. Academic institutions and R&D teams often run PX4 with default configurations simply because it works out of the box.
Defense-adjacent operators using PX4 for logistics, surveillance, or perimeter security. The CISA advisory specifically named the Defense Industrial Base sector as at-risk.
Emergency services integrating drones into search and rescue, fire management, or disaster response workflows.
The common thread is that many of these operators have put enormous effort into the mission-specific aspects of their drone programs and less attention on the underlying communications security. Default configurations tend to stay default.
What an Attacker Can Actually Do
Remote code execution on an autopilot is not a minor bug. Once someone has shell access to the flight controller, the possibilities are significant.
They can alter the drone’s flight path, forcing it to land in a controlled location, return to an attacker-defined “home” point, or simply fly into an obstacle. They can disable sensors or spoof sensor data, causing the autopilot to make decisions based on false readings. In worst-case scenarios involving drones operating near people or critical infrastructure, a compromised flight controller becomes a physical safety risk.
Security researchers at CYVIATION note that the barrier to entry is low. Tools for generating and sending MAVLink traffic are publicly available. Anyone with basic networking knowledge and access to the target network could execute this attack. No sophisticated capability required.
There has been no confirmed real-world exploitation as of the CISA advisory date. But the combination of wide deployment, default insecure configuration, and low technical barrier makes waiting a bad strategy.
What You Need to Do Right Now
The good news is that this is a configuration problem, not a hardware flaw. You do not need to replace any equipment. You need to change settings and tighten your network posture.
1. Enable MAVLink 2.0 Message Signing
This is the primary fix. In PX4, set the MAV_LINK_SIGNING parameter to 1. This activates cryptographic signing on MAVLink communications. You also need to distribute the secret signing key to your ground control station so it can send properly signed commands. Your GCS software, whether QGroundControl or a custom implementation, needs to be configured to sign outbound messages.
Without this step, all the other mitigations are supporting measures at best.
2. Lock Down Your Network
MAVLink should never be accessible from the public internet. Full stop. Use firewall rules to restrict access to UDP ports 14550 and 14540, and limit traffic to known, trusted IP addresses. If you are running drone operations over a corporate or organisational network, put the drone communication system on a dedicated VLAN, isolated from general business traffic.
If remote access to the ground control station is required, use a properly configured VPN. Keep that VPN software updated. A VPN with outdated firmware is only marginally better than no VPN.
3. Check Physical Port Access
The vulnerability extends to physical interfaces. An attacker with physical access to the drone’s telemetry ports, specifically USB and serial connections, can inject MAVLink commands the same way. If your aircraft operate in environments where unauthorised physical access is possible, disable or seal unused ports and enforce signing on physical channels too.
4. Follow PX4’s Security Hardening Guide
PX4 maintains a security hardening guide in its official documentation at docs.px4.io. It covers signing configuration, network isolation, parameter lockdown, and more. Now is a good time to go through it step by step rather than treating it as optional reading.
5. Watch for a Patched Release
CYVIATION and CISA have both flagged the need for a PX4 update that ships with signing enabled by default. Monitor the PX4 GitHub repository and official CISA advisories for a patched release. When it arrives, update promptly.
The Bigger Picture
This vulnerability is part of a pattern. As drones have matured into serious operational tools, their attack surface has grown. The industry spent the last decade solving flight time, camera quality, payload capacity, and autonomy. Cybersecurity got considerably less attention.
MAVLink without authentication is not a new concern. Security researchers have been raising it for years. What is new is that drones are now embedded deeply enough in critical infrastructure that CISA is treating drone software vulnerabilities as industrial control system advisories, the same category as SCADA systems and power grid controllers.
CYVIATION says it is actively investigating other flight control systems and drone communication networks. More findings are likely. This is probably not the last time a drone autopilot ends up in a CISA advisory.
For anyone running PX4 today, the message is clear: enable signing, isolate your network, and stop treating cybersecurity as something to deal with later. Later just became now.
Sources: CISA ICS Advisory ICSA-26-090-02, CYVIATION security research, PX4 Autopilot documentation.