CVE-2024-40427

Imagine the autopilot has a small “scratchpad” area in memory. This bug lets specially crafted input overflow that scratchpad, which can be turned into command execution and can also make the autopilot stop working.

The practical result is that the drone can refuse to execute (causing mission failure) and, in worst cases, an attacker may be able to run commands on the system.

This matters if you use or operate drones running PX4-Autopilot, particularly version 1.14.3. If someone can access the drone’s autopilot system locally (and can supply the triggering input), this could disrupt operation.

Reachability details (whether it’s reachable in the default configuration) are not known from the provided records, so the safe assumption is to treat it as a risk wherever the attacker can reach the affected PX4 component on the device.

This is an AMBER issue because it involves a memory-safety flaw that can lead to command execution and denial of service, and it’s tied to PX4-Autopilot v1.14.3.

Even though no KEV listing and no public exploit code were found in the records reviewed, you should still upgrade promptly as part of your normal security patch cycle, because real-world access to the drone can turn this into an operational safety problem.

1. Confirm exposure

   • Identify the exact PX4-Autopilot version/build deployed on each drone autopilot computer.
   • If you are running PX4-Autopilot v1.14.3, treat it as exposed per the reported vulnerability scope.

2. Apply the fix

   • Update PX4-Autopilot to the vendor-fixed state referenced by PX4.
   • Use the vendor commit: e03e0261a1a0c82f545e66a1e3795956c886db71.
   • Vendor advisory: GHSA-55wq-2hgm-75m4 (as provided in the findings).

3. Validate after upgrade

   • Reboot the autopilot and confirm it starts normally.
   • Verify your standard arming/mission-start workflow completes successfully.
   • Perform a low-risk test (bench/sim or controlled environment) before resuming normal operations.

4. Temporary mitigation if you can’t patch immediately

   • Reduce anyone’s ability to interact with the autopilot system locally (for example, lock down access paths used to send commands/inputs to the autopilot device).
   • Assume the local attacker model applies: limit physical access to the drone and restrict who/what can communicate with the autopilot computer on the device.

5. What to monitor

   • Look for autopilot crashes, repeated restarts, or abnormal refusal to execute missions after any attempted command/input.
   • Track any changes in operator workflow or new interfaces that might increase “local access” to the autopilot.

Severity is high (CVSS 7.9, per the provided record). The weakness is CWE-120 (stack buffer overflow). The findings describe the outcome as command execution with potential denial of service (the program refusing to execute / stopping running).

Attack vector is listed as local, and authentication is listed as low, with user interaction required in the record. “Reachable in default config” and specific preconditions are unknown in the findings, so exposure depends on how your drone setup allows local interaction with the vulnerable code path.

KEV (CISA Known Exploited Vulnerabilities) is not listed, and no public exploit code was found in the records reviewed. A predicted EPSS value is present in the findings, but it is a prediction and should not be treated as proof of active exploitation. The fix is provided by PX4 via commit e03e0261a1a0c82f545e66a1e3795956c886db71 / GHSA-55wq-2hgm-75m4.