{"uuid": "1110e78b-ade6-4f43-9e6d-3da951321c02", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-71643", "type": "seen", "source": "https://gist.github.com/DongJiaxin0422/0d9b5d8d3bff919f626ae20040b90727", "content": "# CVE-2026-71643\n\n[CVE ID]\n\nCVE-2026-71643\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 inconsistent swarm-collision semantics during post-emergency recovery.\n\n\n[DESCRIPTION]\n\nEGO-Planner-v2 contains an issue in the `EGOReplanFSM` recovery logic where the swarm safety checker and trajectory optimizer apply different collision-distance models, clearance thresholds, and trajectory-expiration rules.\n\nAfter two UAVs enter `EMERGENCY_STOP` and come to rest, the safety checker may consider their separation sufficient to begin recovery planning. However, the trajectory optimizer can still classify the same configuration as violating swarm-clearance constraints because it uses an ellipsoidal distance model and enlarged clearance thresholds.\n\nThe optimizer also continues using another UAV's expired trajectory by extrapolating from its terminal state. For an emergency-stop trajectory whose terminal velocity is zero, this causes the other UAV to be treated as permanently stationary at its stopping position.\n\nAs a result, both UAVs may repeatedly fail to generate a valid recovery trajectory. When `planFromGlobalTraj(10)` fails, the FSM transitions back to `GEN_NEW_TRAJ` and retries without a global retry limit or alternative recovery state, causing an indefinite recovery loop.\n\n\n[IMPACT]\n\nAffected UAVs may successfully enter emergency stop but become permanently unable to resume motion.\n\nAlthough the safety checker allows recovery planning to begin, the trajectory optimizer may reject every recovery trajectory because the current configuration remains inside its stricter swarm-clearance margin.\n\nThis can cause two or more UAVs to remain indefinitely stopped while repeatedly executing recovery planning, resulting in denial of service, mission incompletion, and loss of swarm availability.\n\n\n[ROOT CAUSE]\n\nThe issue is caused by inconsistent recovery semantics across the safety-checking and trajectory-optimization components.\n\nThe safety checker uses Euclidean inter-UAV distance and the base pairwise clearance, while the optimizer uses an ellipsoidal distance model together with enlarged swarm-clearance thresholds for optimization and final validation. Therefore, a configuration considered sufficiently separated by the safety checker may still be rejected by the optimizer.\n\nIn addition, the optimizer continues using expired swarm trajectories by extrapolating from their terminal position and velocity. Because emergency-stop trajectories have zero terminal velocity, a stopped UAV is effectively treated as a permanent static obstacle.\n\nThe recovery logic does not provide an escape mode for starting configurations that already violate the optimizer's clearance margin, nor does it provide a deterministic yielding mechanism for simultaneously stopped UAVs.\n\nFinally, failed `GEN_NEW_TRAJ` recovery attempts are retried indefinitely without a global retry bound, backoff mechanism, or dedicated recovery-failure state. These behaviors can make post-emergency recovery permanently infeasible.", "creation_timestamp": "2026-09-08T07:39:57.420343Z"}