Focus on dronecode vulnerabilities and metrics.
Last updated: 29 Mar 2026, 22:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with dronecode. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total dronecode CVEs: 26
Earliest CVE date: 03 Jul 2020, 15:15 UTC
Latest CVE date: 19 Mar 2026, 00:16 UTC
Latest CVE reference: CVE-2026-32743
30-day Count (Rolling): 10
365-day Count (Rolling): 11
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): 0%
Year Variation (Calendar): 83.33%
Month Growth Rate (30-day Rolling): 0.0%
Year Growth Rate (365-day Rolling): 83.33%
Average CVSS: 0.93
Max CVSS: 7.5
Critical CVEs (≥9): 0
| Range | Count |
|---|---|
| 0.0-3.9 | 22 |
| 4.0-6.9 | 2 |
| 7.0-8.9 | 2 |
| 9.0-10.0 | 0 |
These are the five CVEs with the highest CVSS scores for dronecode, sorted by severity first and recency.
PX4 is an open-source autopilot stack for drones and unmanned vehicles. Versions 1.17.0-rc2 and below are vulnerable to Stack-based Buffer Overflow through the MavlinkLogHandler, and are triggered via MAVLink log request. The LogEntry.filepath buffer is 60 bytes, but the sscanf function parses paths from the log list file with no width specifier, allowing a path longer than 60 characters to overflow the buffer. An attacker with MAVLink link access can trigger this by first creating deeply nested directories via MAVLink FTP, then requesting the log list. The flight controller MAVLink task crashes, losing telemetry and command capability and causing DoS. This issue has been fixed in this commit: https://github.com/PX4/PX4-Autopilot/commit/616b25a280e229c24d5cf12a03dbf248df89c474.
PX4 autopilot is a flight control solution for drones. Prior to 1.17.0-rc1, a heap-use-after-free is detected in the MavlinkShell::available() function. The issue is caused by a race condition between the MAVLink receiver thread (which handles shell creation/destruction) and the telemetry sender thread (which polls the shell for available output). The issue is remotely triggerable via MAVLink SERIAL_CONTROL messages (ID 126), which can be sent by an external ground station or automated script. This vulnerability is fixed in 1.17.0-rc1.
PX4 autopilot is a flight control solution for drones. Prior to 1.17.0-rc2, A logic error in the PX4 Autopilot MAVLink FTP session validation uses incorrect boolean logic (&& instead of ||), allowing BurstReadFile and WriteFile operations to proceed with invalid sessions or closed file descriptors. This enables an unauthenticated attacker to put the FTP subsystem into an inconsistent state, trigger operations on invalid file descriptors, and bypass session isolation checks. This vulnerability is fixed in 1.17.0-rc2.
PX4 autopilot is a flight control solution for drones. Prior to 1.17.0-rc2, An unauthenticated path traversal vulnerability in the PX4 Autopilot MAVLink FTP implementation allows any MAVLink peer to read, write, create, delete, and rename arbitrary files on the flight controller filesystem without authentication. On NuttX targets, the FTP root directory is an empty string, meaning attacker-supplied paths are passed directly to filesystem syscalls with no prefix or sanitization for read operations. On POSIX targets (Linux companion computers, SITL), the write-path validation function unconditionally returns true, providing no protection. A TOCTOU race condition in the write validation on NuttX further allows bypassing the only existing guard. This vulnerability is fixed in 1.17.0-rc2.
PX4 autopilot is a flight control solution for drones. Prior to 1.17.0-rc2, the Zenoh uORB subscriber allocates a stack VLA directly from the incoming payload length without bounds. A remote Zenoh publisher can send an oversized fragmented message to force an unbounded stack allocation and copy, causing a stack overflow and crash of the Zenoh bridge task. This vulnerability is fixed in 1.17.0-rc2.
PX4 autopilot is a flight control solution for drones. Prior to 1.17.0-rc2, tattu_can contains an unbounded memcpy in its multi-frame assembly loop, allowing stack memory overwrite when crafted CAN frames are processed. In deployments where tattu_can is enabled and running, a CAN-injection-capable attacker can trigger a crash (DoS) and memory corruption. This vulnerability is fixed in 1.17.0-rc2.
PX4 autopilot is a flight control solution for drones. Prior to 1.17.0-rc2, The crsf_rc parser accepts an oversized variable-length known packet and copies it into a fixed 64-byte global buffer without a bounds check. In deployments where crsf_rc is enabled on a CRSF serial port, an adjacent/raw-serial attacker can trigger memory corruption and crash PX4. This vulnerability is fixed in 1.17.0-rc2.
PX4 autopilot is a flight control solution for drones. Prior to 1.17.0-rc2, the BST telemetry probe writes a string terminator using a device-provided length without bounds. A malicious BST device can report an oversized dev_name_len, causing a stack overflow in the driver and crashing the task (or enabling code execution). This vulnerability is fixed in 1.17.0-rc2.
PX4 Autopilot versions 1.12.x through 1.15.x contain a protection mechanism failure in the "Re-arm Grace Period" logic. The system incorrectly applies the in-air emergency re-arm logic to ground scenarios. If a pilot switches to Manual mode and re-arms within 5 seconds (default configuration) of an automatic landing, the system bypasses all pre-flight safety checks, including the throttle threshold check. This allows for an immediate high-thrust takeoff if the throttle stick is raised, leading to loss of control.
PX4 Autopilot versions 1.12.x through 1.15.x contain a logic flaw in the mode switching mechanism. When switching from Auto mode to Manual mode while the drone is in the "ARMED" state (after landing and before the automatic disarm triggered by the COM_DISARM_LAND parameter), the system lacks a throttle threshold safety check for the physical throttle stick. This flaw can directly cause the drone to lose control, experience rapid uncontrolled ascent (flyaway), and result in property damage
A vulnerability was found in PX4 PX4-Autopilot up to 1.16.0. Affected by this issue is the function MavlinkLogHandler::state_listing/MavlinkLogHandler::log_entry_from_id of the file src/modules/mavlink/mavlink_log_handler.cpp. The manipulation results in stack-based buffer overflow. The attack is only possible with local access. The patch is identified as 338595edd1d235efd885fd5e9f45e7f9dcf4013d. It is best practice to apply a patch to resolve this issue.
Stack Buffer Overflow in PX4-Autopilot v1.14.3, which allows attackers to execute commands to exploit this vulnerability and cause the program to refuse to execute
PX4-Autopilot v1.14.3 was discovered to contain a buffer overflow via the topic_name parameter at /logger/logged_topics.cpp.
A buffer overflow in PX4-Autopilot v1.12.3 allows attackers to cause a Denial of Service (DoS) via a crafted MavLink message.
PX4 Autopilot v.1.14 allows an attacker to fly the drone into no-fly zones by breaching the geofence using flaws in the function.
An issue in PX4 Autopilot v1.14 and before allows a remote attacker to execute arbitrary code and cause a denial of service via the Breach Return Point function.
An issue in PX4 Autopilot v.1.14.0 allows an attacker to manipulate the flight path allowing for crashes of the drone via the home point location of the mission_block.cpp component.
A Race Condition discovered in geofence.cpp and mission_feasibility_checker.cpp in PX4 Autopilot 1.14 and earlier allows attackers to send drones on unintended missions.
PX4 Autopilot 1.14 and earlier, due to the lack of synchronization mechanism for loading geofence data, has a Race Condition vulnerability in the geofence.cpp and mission_feasibility_checker.cpp. This will result in the drone uploading overlapping geofences and mission routes.
PX4 autopilot is a flight control solution for drones. In affected versions a global buffer overflow vulnerability exists in the CrsfParser_TryParseCrsfPacket function in /src/drivers/rc/crsf_rc/CrsfParser.cpp:298 due to the invalid size check. A malicious user may create an RC packet remotely and that packet goes into the device where the _rcs_buf reads. The global buffer overflow vulnerability will be triggered and the drone can behave unexpectedly. This issue has been addressed in version 1.14.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.
PX4-Autopilot provides PX4 flight control solution for drones. In versions 1.14.0-rc1 and prior, PX4-Autopilot has a heap buffer overflow vulnerability in the parser function due to the absence of `parserbuf_index` value checking. A malfunction of the sensor device can cause a heap buffer overflow with leading unexpected drone behavior. Malicious applications can exploit the vulnerability even if device sensor malfunction does not occur. Up to the maximum value of an `unsigned int`, bytes sized data can be written to the heap memory area. As of time of publication, no fixed version is available.
Buffer Overflow vulnerability in PX4-Autopilot allows attackers to cause a denial of service via handler function handling msgid 332.
An issue discovered in Yuneec Mantis Q and PX4-Autopilot v 1.11.3 and below allow attacker to gain access to sensitive information via various nuttx commands.
The Micro Air Vehicle Link (MAVLink) protocol presents authentication mechanisms on its version 2.0 however according to its documentation, in order to maintain backwards compatibility, GCS and autopilot negotiate the version via the AUTOPILOT_VERSION message. Since this negotiation depends on the answer, an attacker may craft packages in a way that hints the autopilot to adopt version 1.0 of MAVLink for the communication. Given the lack of authentication capabilities in such version of MAVLink (refer to CVE-2020-10282), attackers may use this method to bypass authentication capabilities and interact with the autopilot directly.
The Micro Air Vehicle Link (MAVLink) protocol presents no authentication mechanism on its version 1.0 (nor authorization) whichs leads to a variety of attacks including identity spoofing, unauthorized access, PITM attacks and more. According to literature, version 2.0 optionally allows for package signing which mitigates this flaw. Another source mentions that MAVLink 2.0 only provides a simple authentication system based on HMAC. This implies that the flying system overall should add the same symmetric key into all devices of network. If not the case, this may cause a security issue, that if one of the devices and its symmetric key are compromised, the whole authentication system is not reliable.
This vulnerability applies to the Micro Air Vehicle Link (MAVLink) protocol and allows a remote attacker to gain access to sensitive information provided it has access to the communication medium. MAVLink is a header-based protocol that does not perform encryption to improve transfer (and reception speed) and efficiency by design. The increasing popularity of the protocol (used accross different autopilots) has led to its use in wired and wireless mediums through insecure communication channels exposing sensitive information to a remote attacker with ability to intercept network traffic.