Written by: Marceli Śliwiak, Ricardo Fradique, Tanner Smith, Andrzej Olchawa, Milenko Starcik
ArduPilot is one of the most widely adopted open-source autopilot platforms, powering autonomous operation across multi-rotor drones, fixed-wing aircraft, rovers, boats, and submarines. Its flexibility, rich feature set, and strong community adoption make it a cornerstone of both commercial and research unmanned systems.
A recent security assessment of ArduPilot version 4.6.3 identified critical input validation flaws in mission and geofence file handling. These vulnerabilities can be exploited to trigger floating-point exceptions (SIGFPE), resulting in immediate autopilot crashes, loss of Ground Control Station (GCS) connectivity, and disruption of active missions.
Successful exploitation causes the autopilot process to terminate unexpectedly, resulting in:
-
Immediate loss of Ground Control Station (GCS) connectivity
-
Termination of active missions
-
Potential loss of vehicle control during flight
Key Findings
The assessment identified two closely related vulnerabilities affecting mission and fence file processing:
-
SIGFPE via incorrect numeric type conversion during mission file upload
-
SIGFPE via incorrect numeric type conversion during fence (geofence) file upload
Both issues originate from insufficient bounds checking of externally supplied parameters, allowing extreme numeric values or non-numeric values to reach unsafe type conversions.
SIGFPE via Incorrect type Conversion on mission file upload
A SIGFFPE signal is raised in the function mavlink_int_to_mission_cmd (AP_Mission.cpp) during an attempted upload of a crafted mission file with invalid values of parameter param1.
Floating point exception occurs due to unchecked float-to-integer type conversion, leading to immediate autopilot process termination and loss of Ground Control Station (GCS) – vehicle communication.
This vulnerability affects ArduCopter, ArduRover, and ArduSub vehicles, and can be exploited to launch a Denial-of-Service attack, effectively disrupting mission availability.
Steps To Reproduce
Vulnerability is triggered by uploading mission file with param1 set to out-of-range value.
That leads to failure during unchecked float (32 bit) to uint_16_t (16 bit) conversion in mavlink_int_to_mission_cmd (AP_Mission.cpp) function. Below demonstration uses a sample crafted mission file (Figure 1) following plain-text format [RD-3], with param1 set to 1e+10 (10 billion), that was uploaded to ArduCopter using MAVProxy wp load method.
QGC WPL 110
0 0 0 0 1E+10 0 0 0 0 0 0 0
Figure 1: Content of input mission file with out-of-range param1 value (mission.txt)
To reproduce the vulnerability for ArduCopter in SITL environment, follow below steps:
- Run SITL simulation for ArduCopter in debug mode
$ Tools/autotest/sim_vehicle.py -v ArduCopter –console –map -w -D -G
- Wait for vehicle to initialize into PreArm state
- pre-arm good
- Upload mission file to the vehicle using MAVProxy GCS console
> wp load mission.txt
- Observe GCS connection (Figure 2) and vehicle process (Figure 3) termination
Figure 2: Connection lost after mission upload to the Copter – MAVProxy GCS Console
Figure 3: SIGFPE signal caused by arithmetic exception raised upon mission upload to Copter
Figure 4: Backtrace of observed exception (gdb)
Backtrace of the error (Figure 4) shows that insecure type conversion occurs within the mavlink_int_to_mission_cmd (AP_Mission.cpp) function, which converts MAVLinkmessage into a Mission_Command object to be stored in EEPROM vehicle memory. SIGFPE signal is raised at line 1103 due to an arithmetic exception caused by an unsafe assignment between mismatched types with vastly different ranges:
- packet.param1 is a 32-bit float with range with an approximate range of about to .
- cmd.p1 is a 16-bit unsigned integer (uint16_t) with range of 0 to 65,535.
Figure 5: Affected part of code – function mavlink_int_to_mission_cmd (AP_Mission.cpp)
The root cause of this vulnerability is the lack of sufficient bounds checking on param1 prior to type conversion, allowing out-of-range values to trigger a hardware exception. Existing sanitization function sanity_check_params(Figure 6) only performs minimal validation by rejecting infinite or selectively NaN values for parameters 1–4 and does not enforce any command-specific numeric ranges or limits, making this protection highly insufficient.
Figure 6: Mission parameters (1-4) sanity checks – part of AP_Mission::sanity_check_params() function
The impact of this vulnerability is severe, affecting both operational reliability and flight safety across all affected ArduPilot vehicles including ArduCopter, ArduRover and ArduSub.
When an attacker in the network or unintentional operator uploads improperly constructed mission file, the autopilot software immediately crashes due to unhandled exception.
As a direct result, the connection between the GCS and the vehicle is abruptly lost, so any ongoing automated mission is terminated. For vehicle in the air, this loss of control may lead to dangerous situations including uncontrolled flight, failure to perform fail-safe procedures, or even a crash.
Summary
Vulnerability Type: Incorrect Conversion between Numeric Types
Attack type: Remote
Impact: Denial of Service
Affected components: AP_Mission (ArduCopter / ArduRover / ArduSub)
Recommendations
-
Strict validation of all fence parameters before use
-
Explicit rejection of NaN and non-finite values
-
Range validation for parameters mapped to small integer types
-
Fail-safe parsing logic that rejects invalid fence definitions without terminating the autopilot process
Conclusion
The vulnerabilities identified in ArduPilot demonstrate how insufficient input validation at trust boundaries, such as mission and fence file uploads, can create serious operational and safety risks in autonomous systems.
Although ArduPilot includes basic parameter checks, these protections are currently insufficient to prevent arithmetic exceptions caused by malformed input values. Strengthening validation logic and defensive parsing mechanisms is essential to maintain system reliability and flight safety.
As unmanned systems continue to become more autonomous and interconnected, robust input validation and defensive programming practices must be treated as safety-critical requirements.
-
Strict bounds checking for all mission parameters prior to type conversion
-
Command-specific validation for parameter ranges
-
Explicit rejection of values outside allowed numeric ranges
-
Improved error handling to safely reject malformed missions rather than terminating the process
SIGFPE via Incorrect type Conversion on Fence file upload
A SIGFFPE signal is raised in functions convert_MISSION_ITEM_INT_to_AC_PolyFenceI_item_int (MissionItemProtocol_Fence.cpp) and/or is_positive (AP_Math.h) during an attempted upload of a crafted fence files with invalid values of parameter param1. Floating point exception occurs due to unchecked type conversions, leading to immediate autopilot process termination and loss of GCS – vehicle communication. This vulnerability affects all Ardupilot vehicles and can be exploited to launch a Denial-of-Service attack.
Steps To Reproduce
Vulnerability can be triggered by uploading fence files withparametersset to invalid values:
- fence-oor.txt (Figure 7) – with param1 set to “-1e+10” (minus 10 billion)
QGC WPL 110
0 0 0 5001 -1E+10 0 0 0 0 0 0 0
Figure 7: Content of input fence file with out-of-range param1 value (fence-oor.txt)
b. fence-nan.txt (Figure 8)– withparam1 set to“NaN” (Not-a-Number)
QGC WPL 110
0 0 0 5003 NAN 0 0 0 0 0 0 0
Figure 8: Content of input fence file with NaN param1 value (fence-nan.txt)
To reproduce the vulnerability for ArduCopter in SITL environment, follow below steps:
- Run SITL simulation for ArduCopter in debug mode
$ Tools/autotest/sim_vehicle.py -v ArduCopter –console –map -w -D -G -ubsan
- Wait for vehicle to initialize into PreArm state
- pre-arm good
- Upload one of the fence files to the vehicle using MAVProxy GCS console
> fence load fence-oor.txt
> fence load fence-nan.txt
- Observe GCS connection (Figure 9) and vehicle process (Figure 10) termination
Figure 9: Connection lost after fence upload to the Copter – MAVProxy GCS Console
Figure 10: SIGFPE signals caused by arithmetic exception raised (left – file fence-oor.txt, right – file fence-nan.txt)
Figure 11: Backtraces of observed exceptions (above – file fence-oor.txt, below – file fence-nan.txt)
As presented above, both input files had a similar effect upon upload (Figure 9), resulting in the Floating-Point Arithmetic Exception (Figure 10) due to unchecked type conversions, but raised in different parts of the code (Figure 11):
- fence-oor.txt (Figure 7) – function convert_MISSION_ITEM_INT_to_AC_PolyFenceI_item_int responsible for converting MAVLink mission item into an AC_PolyFenceItem structure,
- performs an unchecked assignment of param1 value to vertex_count of type uint_8_t.
Figure 12: Affected function convert_MISSION_ITEM_INT_to_AC_PolyFenceI_item_int (MissionItemProtocol_Fence.cpp)
- fence-nan.txt (Figure 8)- function is_positive, which simply checks whether a float is greater than zero, makes a float-to-NaN comparison between fVal1 (holding param1 value) and FLT_EPSILON (of type float), which raises floating-point operation exception.
Figure 13: Affected function is_positive (AP_Math.h)
The root cause of this vulnerability is the lack of sufficient validation of parameters carried by param1, allowing out-of-range or non-numerical values to trigger an unhandled exception. Existing sanitization routine(Figure 6) performs none or minimal input validation by doing only upper bound check (>255) for selected parameters, making it highly insufficient.
Also keep in mind that demonstrated examples exploit only single case for specific
commands (5001 and 5003), but the same vulnerability is present in all fence-specific commands listed in the Table 1.
| Command | Parameter | Value |
| MAV_CMD_NAV_FENCE_POLYGON_VERTEX_INCLUSION(5001) | vertex_count | =< (-10000000000) |
| MAV_CMD_NAV_FENCE_POLYGON_VERTEX_EXCLUSION (5002) | vertex_count | =< (-10000000000) |
| MAV_CMD_NAV_FENCE_CIRCLE_INCLUSION (5003) | radius | NaN |
| MAV_CMD_NAV_FENCE_CIRCLE_EXCLUSION (5004) | radius | NaN |
Table 1: Fence-specific commands and its parameters that lack proper validation
The impact of this vulnerability is severe, affecting both operational reliability and flight safety across all ArduPilot vehicles. When an attacker in the network or unintentional operator uploads improperly constructed fence file, the autopilot software immediately crashes due to unhandled exception. As a direct result, the connection between the GCS and the vehicle is abruptly lost, so any ongoing automated mission is terminated. For vehicle in the air, this loss of control may lead to dangerous situations including uncontrolled flight, failure to perform failsafe procedures, or even a crash.
Summary
Vulnerability Type: Incorrect Conversion between Numeric Types
Attack type: Remote
Impact: Denial of Service
Affected components: AP_Fence (ArduCopter / ArduPlane / ArduRover / ArduSub)
Recommendations
-
Strict validation of all fence parameters before use
-
Explicit rejection of NaN and non-finite values
-
Range validation for parameters mapped to small integer types
-
Fail-safe parsing logic that rejects invalid fence definitions without terminating the autopilot process
Conclusion
The vulnerabilities identified in ArduPilot demonstrate how insufficient input validation at trust boundaries, such as mission and fence file uploads, can create serious operational and safety risks in autonomous systems.
Although ArduPilot includes basic parameter checks, these protections are currently insufficient to prevent arithmetic exceptions caused by malformed input values. Strengthening validation logic and defensive parsing mechanisms is essential to maintain system reliability and flight safety.
As unmanned systems continue to become more autonomous and interconnected, robust input validation and defensive programming practices must be treated as safety-critical requirements.
