{"vulnerability": "cve-2026-7164", "sightings": [{"uuid": "6238c293-cf75-4f02-9703-3ba2a6bb77b7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-7164", "type": "seen", "source": "https://bsky.app/profile/thehackerwire.bsky.social/post/3mkq7ffyvby2t", "content": "\ud83d\udfe0 CVE-2026-7164 - High (7.5)\n\nIncorrect packet validation allowed unbounded recursion parsing SCTP chunk parameters.  This can ...\n\nhttps://www.thehackerwire.com/vulnerability/CVE-2026-7164/\n\n#infosec #cybersecurity #CVE #vulnerability #security #patchstack", "creation_timestamp": "2026-04-30T18:07:37.935726Z"}, {"uuid": "f9d19389-eced-4d43-93de-51a5b33c72ae", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-7164", "type": "seen", "source": "https://bsky.app/profile/pigondrugs.bsky.social/post/3mkzuipjhgo2f", "content": "~Cybergcca~\nCCCS released 5 advisories covering critical updates for IBM, Dell, FreeBSD, Ubuntu, and CISA ICS products.\n-\nIOCs: CVE-2026-42511, CVE-2026-7270, CVE-2026-7164\n-\n#PatchManagement #ThreatIntel #Vulnerability", "creation_timestamp": "2026-05-04T14:19:13.297015Z"}, {"uuid": "99ff4720-eea2-4f73-a70b-cac05aa381d0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2026-7164", "type": "seen", "source": "https://cyber.gc.ca/en/alerts-advisories/freebsd-security-advisory-av26-415", "content": "", "creation_timestamp": "2026-05-04T06:44:59.000000Z"}, {"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"}, {"uuid": "81e8e904-b4c9-4602-86c9-fabf2d1eab42", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-71641", "type": "seen", "source": "https://gist.github.com/DongJiaxin0422/91656fd120c49a779992aba62c1d58af", "content": "# CVE-2026-71641\n\n[CVE ID]\n\nCVE-2026-71641\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 stale non-zero velocity state during emergency recovery.\n\n\n[DESCRIPTION]\n\nEGO-Planner-v2 contains an issue caused by the interaction between `traj_server`, `poscmd_2_odom`, and the `EGOReplanFSM` emergency recovery logic.\n\nWhile a local trajectory is active, `traj_server` publishes `PositionCommand` messages containing position, velocity, acceleration, and jerk. However, once the trajectory reaches its duration, command publication stops and no final hover or zero-velocity command is sent.\n\n`poscmd_2_odom` stores and continues reusing the last received `PositionCommand`. If the final stored command contains a non-zero velocity, the generated odometry may continue reporting that non-zero velocity even after the trajectory has ended and the position has stopped changing.\n\nWhen the FSM is in `EMERGENCY_STOP` with `flag_escape_emergency_ == false`, recovery requires `odom_vel_.norm() < 0.1` before transitioning to `GEN_NEW_TRAJ`. Because the stale non-zero velocity remains latched, this condition may never become true, leaving the FSM permanently stuck in `EMERGENCY_STOP`.\n\n\n[IMPACT]\n\nAn affected UAV may become unable to exit `EMERGENCY_STOP` after the active trajectory has finished.\n\nThis prevents the planner from resuming trajectory generation and can leave the UAV permanently unavailable for the remainder of the mission. In multi-UAV scenarios, one or more affected vehicles may stop participating in the coordinated task, resulting in denial of service, mission incompletion, or loss of swarm availability.\n\nThe reported odometry can also become internally inconsistent, with the position remaining stationary while the velocity remains non-zero.\n\n\n[ROOT CAUSE]\n\nThe issue is caused by inconsistent handling of trajectory completion and stale command data across multiple components.\n\nFirst, `traj_server` only publishes commands while `t_cur < traj_duration_`. After the trajectory expires, there is no unconditional branch that continues publishing the final trajectory position together with zero velocity, acceleration, and jerk.\n\nSecond, `poscmd_2_odom` stores the most recent `PositionCommand` and does not apply a timeout or invalidate stale command data when new commands stop arriving. Therefore, the final non-zero velocity command may remain latched indefinitely.\n\nThird, `EGOReplanFSM` uses `odom_vel_.norm() < 0.1` as a required condition for leaving `EMERGENCY_STOP`. Because the odometry velocity can remain stale and non-zero, the recovery condition may never be satisfied.\n\nThe combination of missing end-of-trajectory zero-velocity publication, indefinite reuse of stale command data, and a velocity-dependent recovery condition creates a permanent emergency-recovery deadlock.", "creation_timestamp": "2026-09-08T07:35:49.969706Z"}, {"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"}, {"uuid": "e4a9fb17-db04-40e8-9e50-6319acae6878", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-71644", "type": "seen", "source": "https://gist.github.com/DongJiaxin0422/6c39c3c59236bc2c8ec4b4182284fa7e", "content": "# CVE-2026-71644\n\n[CVE ID]\n\nCVE-2026-71644\n\n\n[PRODUCT]\n\nRACER\n\n\n[VERSION]\n\nRACER commit abcdef1234567890.\n\n\n[PROBLEM TYPE]\n\nUnsafe trajectory planning and potential UAV collision caused by missing swarm-trajectory publication in the IDLE state.\n\n\n[DESCRIPTION]\n\nRACER contains an issue in `FastExplorationFSM::swarmTrajTimerCallback()` where a UAV stops publishing its swarm trajectory after entering the `IDLE` state.\n\nThe callback publishes `fd_->newest_traj_` while the UAV is in `EXEC_TRAJ` and publishes a virtual stationary trajectory at the current position while the UAV is in `WAIT_TRIGGER`. However, there is no corresponding trajectory-publication branch for `IDLE`.\n\nAs a result, a UAV that remains physically stationary in the environment after entering `IDLE` no longer continuously broadcasts a trajectory representing its occupied position. Other UAVs may therefore receive only stale trajectory information or eventually have no valid up-to-date trajectory representation for the idle UAV.\n\nThis can cause other UAVs to perform trajectory planning or collision checking without an accurate representation of the idle UAV's current occupied position.\n\n\n[IMPACT]\n\nOther UAVs may plan trajectories based on incomplete or stale swarm-state information and fail to correctly account for an idle UAV that is still physically present in the shared environment.\n\nThis can result in unsafe trajectory planning, unsafe inter-UAV proximity, and potential UAV collisions. The exact manifestation depends on how receiving UAVs cache and expire previously received swarm trajectories.\n\n\n[ROOT CAUSE]\n\n`FastExplorationFSM::swarmTrajTimerCallback()` does not handle the `IDLE` state when publishing swarm trajectories.\n\nThe callback explicitly publishes a moving trajectory in `EXEC_TRAJ` and a virtual stationary trajectory in `WAIT_TRIGGER`, but neither publishes the existing trajectory nor constructs a stationary trajectory when the FSM is in `IDLE`.\n\nTherefore, once a UAV enters `IDLE`, its physical occupancy is no longer continuously represented through the swarm trajectory communication mechanism.\n\nThis is inconsistent with the existing `WAIT_TRIGGER` behavior, which explicitly publishes a stationary virtual trajectory at the current UAV position to avoid collisions.", "creation_timestamp": "2026-09-08T08:18:15.166651Z"}, {"uuid": "b45cc3b0-442d-424e-9108-b5f7dd9a87d2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-71645", "type": "seen", "source": "https://gist.github.com/DongJiaxin0422/5c01ce9ab3211463b20dc8e86e6464de", "content": "# CVE-2026-71645\n\n[CVE ID]\n\nCVE-2026-71645\n\n\n[PRODUCT]\n\nRACER\n\n\n[VERSION]\n\nRACER commit abcdef1234567890.\n\n\n[PROBLEM TYPE]\n\nDenial of Service (DoS) caused by an unbounded trajectory-planning retry loop in the exploration state machine.\n\n\n[DESCRIPTION]\n\nRACER contains an issue in the exploration state machine where a UAV may remain indefinitely in the `PLAN_TRAJ` state when the currently selected `next_viewpoint` becomes unreachable.\n\nWhen trajectory planning returns `FAIL`, the FSM only sets `fd_->static_state_ = true` and remains in `PLAN_TRAJ`. It does not limit the number of retries, invalidate the unreachable target, select another viewpoint or frontier, or transition to an alternative recovery state.\n\nIf A* cannot find a path to the current `next_pos_`, `planTrajToView()` returns `FAIL`. During collision-avoidance or return-related replanning, the system may continue attempting to plan toward the same existing `next_pos_` instead of performing a complete exploration-planning cycle and selecting a different target.\n\nAs a result, the FSM can repeatedly attempt to reach the same unreachable viewpoint without making exploration progress.\n\n\n[IMPACT]\n\nAn affected UAV may become trapped in a persistent replanning loop and stop making exploration progress.\n\nThe UAV can repeatedly execute unsuccessful A* searches and trajectory-planning operations, continuously generate warning and error logs, and fail to select another reachable frontier or viewpoint.\n\nThis condition can persist until the mission or experiment times out, resulting in denial of service and mission incompletion. In multi-UAV exploration, the affected UAV may also reduce overall swarm exploration efficiency because it remains assigned to an unreachable or temporarily blocked target.\n\n\n[ROOT CAUSE]\n\nThe exploration FSM does not implement a bounded recovery mechanism for repeated trajectory-planning failures involving the same target.\n\nWhen `callExplorationPlanner()` returns `FAIL` in `PLAN_TRAJ`, the failure branch only sets `fd_->static_state_ = true`. It does not increment a retry counter, mark the current viewpoint as unreachable, invalidate `next_pos_`, trigger frontier reselection, or transition to another recovery state.\n\nIn addition, when replanning is triggered by collision avoidance or return behavior, the planner can continue calling `planTrajToView()` using the existing `ed_->next_pos_` and `ed_->next_yaw_`. Therefore, an unreachable target may be retried repeatedly without forcing a new exploration-planning decision.\n\nThe absence of retry bounds, target invalidation, target reselection, and fallback-state handling allows the FSM to remain indefinitely in `PLAN_TRAJ`.", "creation_timestamp": "2026-09-08T08:19:53.454130Z"}, {"uuid": "c0bc52f4-c623-45a9-8420-0c003826853f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-71646", "type": "seen", "source": "https://gist.github.com/DongJiaxin0422/747d8e6c8afc0a364454b741b39bb98c", "content": "# CVE-2026-71646\n\n[CVE ID]\n\nCVE-2026-71646\n\n\n[PRODUCT]\n\nRACER\n\n\n[VERSION]\n\nRACER commit abcdef1234567890.\n\n\n[PROBLEM TYPE]\n\nDenial of Service (DoS) caused by a cooldown bypass in repeated pair-opt attempts.\n\n\n[DESCRIPTION]\n\nRACER contains an issue in `FastExplorationFSM::optTimerCallback()` where failed pair-opt attempts can bypass the intended attempt cooldown and be retried at timer frequency.\n\nThe pair-opt mechanism uses `recent_attempt_time_` together with `attempt_interval_` to prevent repeated optimization attempts within a short time interval.\n\nHowever, when a pair-opt attempt determines that the reallocated assignment has a higher cost, the callback may return immediately before updating `recent_attempt_time_`.\n\nBecause the failed attempt is not recorded by the cooldown mechanism, the next invocation of `optTimerCallback()` can immediately pass the same cooldown check and execute the same pair-opt computation again.\n\nIf the same condition persists, the callback repeatedly performs the failed pair-opt operation at timer frequency.\n\n\n[IMPACT]\n\nAn affected UAV may repeatedly execute unsuccessful pair-opt computations without respecting the configured cooldown interval.\n\nThis can cause excessive CPU consumption, repeated error logging, and unnecessary task-reallocation processing. The repeated optimization attempts may also interfere with normal exploration-state-machine execution and reduce overall exploration progress.\n\nIf the condition persists, the affected system may spend substantial computation repeatedly processing the same failed pair-opt operation, resulting in denial of service or mission degradation.\n\n\n[ROOT CAUSE]\n\nThe cooldown timestamp `recent_attempt_time_` is updated only after the pair-opt processing reaches a later stage of `optTimerCallback()`.\n\nWhen the reallocated assignment is determined to have a higher cost, the callback executes an early `return` before this timestamp update occurs.\n\nAs a result, the failed pair-opt attempt is not recorded as an attempt. On the next timer invocation, the elapsed-time check against `attempt_interval_` still succeeds, allowing the same pair-opt operation to be retried immediately.\n\nThe cooldown mechanism therefore applies only to attempts that reach the later timestamp-update path, rather than to all pair-opt attempts. This control-flow ordering allows rejected pair-opt attempts to bypass the intended rate limit and repeat at timer frequency.", "creation_timestamp": "2026-09-08T08:22:24.831406Z"}, {"uuid": "87e7abc4-c837-4f82-bf51-5172ea980f5f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-71644", "type": "seen", "source": "https://bsky.app/profile/stackflag.bsky.social/post/3mvb37uwjyp2f", "content": "CVE-2026-71644\nThe RACER software used for drone swarms has a missing safety check that could let an attacker influence the flight paths, creating unsafe trajectories and possible collisions. This occurs when the system fails\u2026\n\nToo many irrelevant or confusing CVEs? Use stackflag.com\n\n#CVE #infosec", "creation_timestamp": "2026-09-11T17:20:07.071198Z"}, {"uuid": "6e08fd53-bc9f-447e-a55a-0583460ee72a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-71644", "type": "seen", "source": "https://bsky.app/profile/stemshop.bsky.social/post/3mvb5v2vfwk2j", "content": "\ud83d\udea8 CVE-2026-71644 \u2014 CVSS 9.8 CRITICAL\n\nAn issue in Robotics-STAR-Lab (SYSU STAR Group) RACER Tested affected version: commit abcdef1234567890 allo...\n\n\ud83d\udd0e https://stemshop.top/cve/CVE-2026-71644\n\n#CVE #CyberSecurity #InfoSec", "creation_timestamp": "2026-09-11T18:07:45.254606Z"}]}