CVE-2026-85446 in MOOS-IvP
Summary
by MITRE • 09/04/2026
MOOS-IvP versions through 24.8.1 contain a quadratic processing vulnerability in uFldNodeComms where each new node identity creates a ledger entry and triggers all-pairs distribution work. Attackers can supply unbounded distinct node names in reports to drive the shoreside broker into quadratic processing, delaying or preventing distribution of legitimate node reports.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The MOOS-IvP software suite, specifically versions through 24.8.1, contains a significant algorithmic complexity vulnerability within its uFldNodeComms component that allows for denial-of-service attacks via resource exhaustion. This flaw stems from the way the system manages node identities and distributes communication reports across the networked environment. In this architecture, each distinct node identity registered or reported by the shoreside broker triggers the creation of a corresponding ledger entry. More critically, the system is designed to perform all-pairs distribution work for these entries, meaning that every new node must communicate with every other existing node in the cluster. This design choice creates a computational dependency where processing time scales quadratically relative to the number of unique nodes present in the system rather than linearly or logarithmically as would be expected in optimized communication protocols.
The technical root cause lies in the lack of input validation and rate limiting regarding node identity registration within the uFldNodeComms module. An attacker who can inject unbounded distinct node names into reports sent to the shoreside broker can artificially inflate the count of active nodes without necessarily providing legitimate operational data. By rapidly registering a large number of unique, synthetic identities, an adversary forces the broker to execute O(n squared) operations for each new entry added to the ledger. This quadratic processing requirement consumes excessive CPU cycles and memory resources as the system attempts to compute distribution paths between every pair of registered nodes. The vulnerability is particularly dangerous because it does not require complex exploitation techniques or privilege escalation; simply supplying a high volume of distinct node identifiers in standard report messages is sufficient to trigger the detrimental behavior.
The operational impact of this vulnerability is severe, primarily manifesting as a denial-of-service condition that degrades or completely halts legitimate system operations. As the shoreside broker becomes bogged down by quadratic processing tasks, its ability to distribute genuine reports from actual autonomous underwater vehicles or surface vessels is significantly delayed or prevented entirely. In mission-critical applications such as unmanned vehicle coordination, where real-time data exchange and situational awareness are paramount, this latency can lead to loss of control over assets, failure in collaborative task execution, and potential safety hazards if the system cannot react promptly to environmental changes or command inputs. The degradation is not merely a performance slowdown but represents a functional breakdown of the core communication infrastructure that supports the entire MOOS-IvP ecosystem.
From a classification perspective, this vulnerability aligns with CWE-787 Out-of-bounds Write in terms of resource consumption patterns and more accurately maps to CWE-400 Uncontrolled Resource Consumption due to algorithmic complexity. It also corresponds to MITRE ATT&CK technique T1496 Resource Hijacking, specifically under the sub-category of computational cycle exhaustion or network saturation via service disruption. The attack vector is classified as remote if the shoreside broker accepts inputs over a network interface, making it accessible to adversaries who can inject malformed or excessive report data into the communication stream. This highlights a critical gap in input sanitization and load balancing mechanisms within the node management logic of the affected versions.
Mitigation strategies must focus on implementing strict limits on the number of unique node identities allowed per unit of time and enforcing validation checks before ledger entries are created. Developers should refactor the uFldNodeComms module to avoid all-pairs distribution for every new identity, perhaps by using more efficient data structures or limiting broadcast scopes to relevant subsets rather than global pairs. Additionally, implementing rate-limiting policies on node registration requests can prevent attackers from flooding the system with synthetic identities. Until a patched version is deployed, operators should monitor network traffic for anomalous spikes in distinct node identifiers and consider isolating vulnerable components behind firewalls that restrict access to trusted sources only. Upgrading beyond version 24.8.1 once patches are available remains the most effective long-term solution to eliminate this quadratic processing flaw.