CVE-2026-85448 in MOOS-IvP
Summary
by MITRE • 09/04/2026
MOOS-IvP uFldShoreBroker through 24.8.1 fails to limit the number of claimed communities stored in parallel vectors within ShoreBroker::handleMailNodePing(). A single publisher can supply unbounded distinct community names to grow retained state and per-pass work without limit, causing memory exhaustion and performance degradation.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in MOOS-IvP versions through 24.8.1 represents a critical resource management flaw within the ShoreBroker component, specifically affecting the uFldShoreBroker module. This issue stems from an insufficient input validation mechanism during the handling of node ping messages via the handleMailNodePing function. In distributed autonomous systems like those built on MOOS-IvP architecture, components frequently communicate using a publish-subscribe model where nodes exchange status updates and coordination data. The ShoreBroker acts as a central hub for managing these interactions, particularly regarding community-based grouping of vehicles or agents. However, the implementation fails to enforce any upper bound on the number of distinct community names that can be claimed and stored in parallel vectors during this process. This lack of constraint allows a single publisher node to exploit the system by supplying an unbounded stream of unique community identifiers.
From a technical perspective, the core defect lies in the absence of rate limiting or cardinality checks when processing incoming ping messages. When a node sends a ping claiming membership in various communities, the ShoreBroker allocates memory for each new community name without verifying if this exceeds system capacity or predefined thresholds. As these distinct names are added to retained state vectors and processed in subsequent passes, the application accumulates significant overhead. Each entry requires dynamic memory allocation, and as the number of claimed communities grows linearly with incoming messages from a single source, the memory footprint expands indefinitely. This behavior directly leads to resource exhaustion, manifesting as severe performance degradation or complete system failure due to out-of-memory conditions. The vulnerability is particularly dangerous because it can be triggered remotely by any node capable of sending ping messages to the broker, requiring no special privileges beyond basic network access within the MOOS domain.
The operational impact of this flaw extends beyond simple memory consumption. In real-world applications involving autonomous underwater vehicles or unmanned surface vessels, timely communication is critical for mission success and safety. The unbounded growth of retained state causes increased latency in message processing as the system struggles to manage larger data structures during each pass. This performance degradation can lead to missed deadlines for control loops, resulting in erratic behavior or loss of coordination among fleet members. Furthermore, if the memory exhaustion occurs abruptly, it may cause the ShoreBroker process to crash, effectively severing communication links and isolating nodes from the broader network. Such a disruption could compromise mission integrity, especially in scenarios requiring tight formation keeping or collaborative task execution where continuous state synchronization is essential for operational stability.
This vulnerability aligns with CWE-400, which describes uncontrolled resource consumption, specifically highlighting issues related to memory exhaustion when input validation fails to limit the size of data structures. It also relates to CWE-787, as improper handling of dynamic memory allocation can lead to buffer overflows or excessive heap usage depending on implementation details. In terms of offensive security frameworks, this flaw supports Denial-of-Service attacks categorized under MITRE ATT&CK technique T1499, specifically endpoint denial of service via resource exhaustion. An adversary could leverage this weakness to disrupt autonomous operations by flooding the broker with fake community claims, thereby degrading system responsiveness or causing a total outage without needing to exploit code execution vulnerabilities.
Mitigation strategies must focus on implementing strict input validation and rate limiting within the ShoreBroker component. Developers should enforce maximum limits on the number of distinct communities that can be claimed per node or globally across all nodes. Implementing token bucket algorithms or similar rate-limiting mechanisms would prevent a single publisher from overwhelming the system with rapid successive pings containing unique identifiers. Additionally, introducing periodic cleanup routines to remove stale community entries and monitoring memory usage metrics could provide early warning signs of abuse. Updating to patched versions that include these safeguards is essential for maintaining the reliability and security of MOOS-IvP deployments in critical autonomous systems environments where resource constraints are often tight and failure modes can have significant physical consequences.