{"uuid": "78ba2baa-5549-4e4a-bb24-ad807a6e51fa", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-71647", "type": "seen", "source": "https://gist.github.com/DongJiaxin0422/1bd1523591973e7c2e1bea862669d343", "content": "# CVE-2026-71647\n\n[CVE ID]\n\nCVE-2026-71647\n\n\n[PRODUCT]\n\nEGO-Planner-v2\n\n\n[VERSION]\n\nEGO-Planner-v2 commit 5c99a95880401e2599638d567abc0e240396cb42.\n\n\n[PROBLEM TYPE]\n\nDenial of Service (DoS) caused by unbounded recovery-state oscillation in the replanning state machine.\n\n\n[DESCRIPTION]\n\nEGO-Planner-v2 contains a recovery-state-machine issue involving `checkCollisionCallback()`, `execFSMCallback()`, and `planFromGlobalTraj()` in `ego_replan_fsm.cpp`.\n\nWhen a UAV remains close to an obstacle or another UAV, `checkCollisionCallback()` may repeatedly detect the same safety condition and attempt local replanning. If local replanning fails and the predicted collision is imminent, the FSM enters `EMERGENCY_STOP`.\n\nOnce the UAV velocity falls below the recovery threshold, `execFSMCallback()` can transition the FSM from `EMERGENCY_STOP` to `GEN_NEW_TRAJ` without verifying that the underlying close-distance conflict has actually been resolved.\n\nIf `planFromGlobalTraj(10)` then fails, the FSM immediately retries `GEN_NEW_TRAJ`. At the same time, `checkCollisionCallback()` continues running during recovery states and may detect the same unresolved hazard again, causing another transition to replanning or `EMERGENCY_STOP`.\n\nThis interaction can repeatedly cycle the UAV through safety-triggered replanning, `EMERGENCY_STOP`, and `GEN_NEW_TRAJ`.\n\n\n[IMPACT]\n\nAn affected UAV may become trapped in a persistent recovery loop and fail to resume stable trajectory execution.\n\nThe repeated replanning and emergency-recovery transitions can generate a large number of safety events, prevent task completion, and cause prolonged loss of availability. In multi-UAV scenarios, several UAVs may simultaneously enter the same recovery behavior, further preventing the swarm from making progress.\n\nThis condition can therefore cause denial of service and mission failure. In crowded environments, the unstable recovery behavior may also interfere with safe vehicle motion.\n\n\n[ROOT CAUSE]\n\nThe recovery logic does not provide a bounded or coordinated mechanism for resolving persistent obstacle or inter-UAV conflicts.\n\nSeveral behaviors combine to create the oscillation:\n\n1. `checkCollisionCallback()` continues executing during states such as `GEN_NEW_TRAJ`, `EMERGENCY_STOP`, and `REPLAN_TRAJ`, allowing safety checks to repeatedly interrupt an ongoing recovery process.\n\n2. `EMERGENCY_STOP` may transition to `GEN_NEW_TRAJ` when `odom_vel_.norm() < 0.1` without confirming that the obstacle or swarm-clearance condition that triggered the emergency stop has been resolved.\n\n3. When `planFromGlobalTraj(10)` fails in `GEN_NEW_TRAJ`, the FSM transitions back to `GEN_NEW_TRAJ` and retries without a bounded retry count, cooldown period, backoff mechanism, or dedicated recovery-failure state.\n\n4. Multiple UAVs can perform these recovery actions simultaneously without a priority or yielding mechanism, allowing the same close-distance conflict to persist.\n\nAs a result, an unresolved safety condition can repeatedly drive the FSM between recovery states without making progress, producing an effectively unbounded recovery loop.", "creation_timestamp": "2026-09-08T07:32:24.662865Z"}