CVE-2026-71647 in EGO-Planner-v2
Summary
by MITRE • 09/11/2026
An issue in EGO-Planner-v2 All versions up to commit 5c99a95880401e2599638d567abc0e240396cb42 allows an attacker to cause a denial of service via the checkCollisionCallback, execFSMCallback, planFromGlobalTraj in ego_replan_fsm.cpp
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified within EGO-Planner-v2 represents a critical reliability flaw affecting all versions prior to commit 5c99a95880401e2599638d567abc0e240396cb42. This software component is integral to autonomous navigation systems, particularly in robotics and unmanned aerial vehicles where real-time path planning and collision avoidance are paramount for safe operation. The core of the issue resides within the ego_replan_fsm.cpp module, specifically targeting three primary functions: checkCollisionCallback, execFSMCallback, and planFromGlobalTraj. These functions form the backbone of the system's decision-making loop during replanning events, where the planner must dynamically adjust its trajectory based on real-time sensor data and state machine transitions. The presence of a denial-of-service condition in these specific entry points suggests that under certain conditions or with crafted inputs, the application fails to handle exceptions or edge cases gracefully, leading to an abrupt termination of the process rather than a controlled recovery or error handling sequence.
From a technical perspective, this flaw aligns closely with CWE-400, which describes Uncontrolled Resource Consumption, and potentially CWE-252, Check for Errors after Critical Calls if the failure stems from unchecked return values leading to null pointer dereferences or invalid memory access. The vulnerability likely manifests when the system encounters unexpected states during collision checking or trajectory planning phases. For instance, the checkCollisionCallback may fail to properly validate input data structures before processing them against occupancy grids, while execFSMCallback might enter an infinite loop or crash due to improper state transition logic. Similarly, planFromGlobalTraj could suffer from buffer overflows or segmentation faults if it attempts to access memory regions that have been deallocated or are out of bounds during the replanning process. These failures result in a complete halt of the planning engine, effectively causing a denial of service by rendering the autonomous platform unable to navigate safely or respond to environmental changes.
The operational impact of this vulnerability is severe for any deployment relying on EGO-Planner-v2 for critical navigation tasks. In an unmanned aerial vehicle context, such as those utilizing PX4 and ROS 2 as indicated in related advisories, a crash during flight could lead to loss of control, potential crashes, or unsafe landings if the fallback mechanisms are not robust enough. For ground-based robots operating in dynamic environments like warehouses or hospitals, a denial-of-service event means the robot becomes an obstacle itself, potentially causing collisions with humans or other equipment due to its inability to replan around newly detected obstacles. The lack of graceful degradation means that instead of slowing down or stopping safely, the system simply ceases operation, which is particularly dangerous in high-speed or complex navigation scenarios where continuous planning updates are required for stability and safety.
This vulnerability maps directly to MITRE ATT&CK technique T1499, Endpoint Denial of Service, as it involves exploiting a flaw in software logic to disrupt service availability rather than compromising confidentiality or integrity. It also relates to the broader category of resource exhaustion attacks where an attacker might trigger these specific callbacks repeatedly with malformed data to exhaust system resources or force repeated crashes. The attack vector is likely local if the planner receives inputs from internal sensors, but could be remote if sensor data can be spoofed via network interfaces in a ROS-based architecture. An adversary capable of injecting false obstacle data or manipulating state machine triggers could systematically crash the navigation stack, effectively neutralizing the robot's utility and potentially causing physical damage through uncontrolled movement prior to the crash.
Mitigation strategies must focus on both immediate patching and long-term architectural improvements. The primary remediation is to upgrade EGO-Planner-v2 to a version released after commit 5c99a95880401e2599638d567abc0e240396cb42, which presumably contains the necessary code fixes to handle these edge cases. Developers should implement rigorous input validation within checkCollisionCallback and planFromGlobalTraj to ensure that all geometric calculations operate on valid data structures with proper bounds checking. Additionally, execFSMCallback requires robust state management logic to prevent invalid transitions from causing crashes. It is advisable to wrap critical planning functions in try-catch blocks or equivalent error handling mechanisms appropriate for the C++ environment to catch exceptions and log them without terminating the process. Furthermore, integrating watchdog timers that can detect if the planner has stopped responding and trigger a safe stop procedure rather than allowing an unhandled exception to crash the node is recommended. Security testing should include fuzzing these specific callbacks with malformed trajectory data or collision meshes to verify resilience against such denial-of-service attempts before deployment in production environments.