PX4 Autopilot EUVD-2026-89109

Requires the attacker to already have access to the PX4 nsh command shell - via a physical serial/USB console or an exposed MAVLink shell over the vehicle's telemetry link - and the firmware build must include the 'file2' diagnostic/test command (part of the systemcmds/tests suite, not guaranteed in all production images). Exploitation is then trivial: supply an excessively large value to the '-c' write-chunk-size option, which is not validated before driving a stack allocation. Limiting factors: pre-existing shell access is mandatory, the test command must be compiled into the running firmware, and impact is confined to crashing the controller (denial of service) with no code execution or data disclosure.

The vendor CVSS 4.0 vector (AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H) scores 7.1 and correctly characterizes this as an availability-only issue (VA:H) with no confidentiality or integrity impact - consistent with CWE-789 uncontrolled stack allocation leading to a crash. However, there is a meaningful tension between the PR:N metric and the description, which explicitly requires the attacker to already have shell access to the PX4 nsh console; the low PR reflects that the PX4 shell itself is typically unauthenticated rather than that no access is needed. Attack vector is also debatable: the vendor chose AV:A (adjacent, likely reasoning about the MAVLink shell over a telemetry radio link), but console/serial access is local - so real-world reachability depends on deployment (physical port vs. exposed MAVLink shell). There is no EPSS score, no CISA KEV listing, and no public exploit provided in the intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Net: this is a genuine but bounded denial-of-service against a flight controller that requires pre-existing shell access and (typically) a diagnostic/test build - a real safety concern for a drone but a low-to-moderate priority as an internet-facing security risk. A patch is confirmed available from the vendor (PR #28586 adding a 4096-byte MAX_WRITE_CHUNK bound), which is the decisive mitigating factor.

An attacker who has reached the PX4 nsh shell - via a physical serial/USB console or an exposed MAVLink shell over the vehicle's telemetry link - invokes the diagnostic 'file2' test command and passes an excessively large value to the '-c' (write chunk size) option. The unvalidated size drives an uncontrolled stack allocation, overflowing the stack and crashing the flight controller. No public exploit code is identified at time of analysis; the fix simply rejects chunk sizes outside 1-4096.