CVE-2026-85445 in MOOS-IvP
Summary
by MITRE • 09/04/2026
MOOS-IvP through 24.8.1 contains a denial of service vulnerability in the Demuxer::addMuxPacket() function that trusts the packet count declared in mux headers without validation. Attackers can declare arbitrarily large packet counts to trigger unbounded memory allocation, exhausting system resources and causing service unavailability.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The MOOS-IvP software suite, specifically through version 24.8.1, contains a critical denial of service vulnerability within the Demuxer::addMuxPacket() function. This flaw stems from an improper input validation mechanism where the application blindly trusts the packet count declared in multiplexer headers without performing any bounds checking or sanity verification. In networked and distributed systems like MOOS-IvP, which is widely used for autonomous vehicle coordination and control, data integrity and resource management are paramount. The vulnerability arises because the software assumes that incoming mux header information accurately reflects the actual size of the payload being transmitted. This assumption creates a significant security gap, allowing malicious actors to exploit this trust relationship by injecting malformed or specially crafted packets with artificially inflated packet counts.
From a technical perspective, the core issue is an unbounded memory allocation triggered by external input. When the Demuxer::addMuxPacket() function processes these headers, it allocates memory resources based on the declared count rather than verifying if such a volume of data actually exists or is permissible within system constraints. An attacker can exploit this by declaring arbitrarily large packet counts in the mux header fields. Upon receiving such a request, the application attempts to allocate sufficient memory to handle the purported number of packets. Since there are no limits imposed on this allocation process, the system may attempt to reserve vast amounts of RAM or swap space, far exceeding available physical resources. This behavior aligns with CWE-400, which describes uncontrolled resource consumption, and specifically relates to improper input validation that leads to denial of service conditions.
The operational impact of this vulnerability is severe, primarily manifesting as a complete loss of availability for the MOOS-IvP services running on affected systems. As the application consumes increasing amounts of memory in response to malicious inputs, it eventually exhausts all available system resources. This resource exhaustion leads to process termination, system crashes, or significant performance degradation that renders the autonomous vehicle control infrastructure unusable. In critical applications such as unmanned surface vehicles or underwater drones, where MOOS-IvP is frequently deployed, a denial of service can lead to mission failure, loss of vessel control, and potentially hazardous situations if safety protocols rely on continuous software operation. The attack vector typically involves sending crafted network packets that target the demultiplexing logic, making it accessible over local or remote networks depending on the deployment configuration.
Mitigation strategies for this vulnerability should focus on implementing robust input validation and resource limits at multiple layers of the application stack. Developers must enforce strict bounds checking on all packet counts received from external sources before any memory allocation occurs. This includes verifying that declared sizes do not exceed predefined maximum thresholds appropriate for the system's operational context. Additionally, implementing rate limiting can help mitigate the speed at which such requests are processed, reducing the window of opportunity for resource exhaustion attacks. Upgrading to a patched version of MOOS-IvP where this validation logic has been corrected is the primary remediation path. Until patches are applied, network-level filtering rules that inspect mux header fields and drop packets with suspiciously large counts can provide temporary protection against exploitation attempts aligned with ATT&CK technique T1498, which covers Network Denial of Service via resource exhaustion.