CVE-2026-85441 in core-moos
Summary
by MITRE • 09/04/2026
MOOS core-moos through 10.4.0 fails to validate that serialized string lengths are non-negative in CMOOSMsg::operator>>. Unauthenticated attackers can send a crafted message with a negative length value to the MOOSDB port, causing an unhandled exception that terminates the database process.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in MOOS core versions through 10.4.0 represents a critical input validation failure within the CMOOSMsg::operator>> function. This component is responsible for deserializing incoming messages from the MOOSDB, which serves as the central data bus for the Mission Oriented Operating Suite (MOOS). The specific flaw lies in the handling of serialized string lengths during the parsing process. When a message arrives, the system extracts length indicators to determine how much memory to allocate or read for subsequent payload data. However, the implementation fails to verify that these extracted integer values are non-negative before proceeding with buffer operations. This oversight creates a scenario where an attacker can manipulate the serialization format to include negative integers as string lengths.
From a technical perspective, this issue stems from improper type checking and boundary validation during deserialization. In many C++ implementations involving network protocols or binary formats, length fields are often treated as signed 32-bit or 64-bit integers by default unless explicitly cast to unsigned types. When a negative value is parsed into such an integer variable, it retains its two's complement representation. Subsequent logic that uses this value for memory allocation, array indexing, or loop bounds may interpret the large positive equivalent of the negative number as valid data size, leading to excessive resource consumption. Alternatively, if the code performs arithmetic subtraction based on this length without checking signs first, it can result in underflow conditions that access invalid memory addresses. In the specific case described, the lack of validation triggers an unhandled exception within the database process itself rather than being caught by a robust error handling routine.
The operational impact of this vulnerability is severe due to its potential for remote exploitation without authentication. Since MOOSDB typically listens on network ports to accept data from various autonomous systems and control nodes in marine or aerial applications, any entity with network access can target the service. An unauthenticated attacker can craft a malicious packet containing a message header with a negative string length field and transmit it directly to the MOOSDB port. Upon receiving this crafted message, the CMOOSMsg::operator>> function processes the invalid input, leading to an immediate crash of the database process. This results in a complete denial of service for any application relying on the central data bus. In autonomous vehicle contexts such as unmanned surface vessels or underwater robots, where MOOS is frequently deployed, this outage can lead to loss of situational awareness, failure of navigation systems, and potential physical damage to the platform due to uncontrolled movement.
This vulnerability aligns with CWE-20 Improper Input Validation, specifically regarding the failure to validate that input data meets expected constraints such as non-negativity for length fields. It also relates closely to CWE-134 Use of Externally-Controlled Format String if the negative value leads to buffer over-read conditions during string processing. From a threat modeling perspective using MITRE ATT&CK, this behavior is consistent with T1498 Network Denial of Service, where an attacker disrupts service availability by exploiting software weaknesses. Furthermore, because it involves deserialization of untrusted data from the network, it falls under techniques associated with improper handling of serialized objects which can lead to crashes or further exploitation vectors if memory corruption occurs alongside the exception.
Mitigation strategies must focus on strengthening input validation at the earliest possible point in the message processing pipeline. Developers should ensure that all length fields extracted during deserialization are explicitly cast to unsigned integer types before any arithmetic operations or memory allocations occur. Additionally, explicit checks should be implemented to verify that parsed values fall within expected bounds for the specific application context; a string length must logically never be negative and should not exceed maximum allowable buffer sizes defined by the system architecture. Implementing robust exception handling around deserialization routines can also prevent crashes from propagating to the main process loop, allowing the service to recover gracefully or log detailed error information for debugging without terminating entirely. Updating to patched versions of MOOS core that address this validation gap is essential for maintaining operational integrity in deployed systems.