CVE-2026-85440 in core-moos
Summary
by MITRE • 09/04/2026
MOOS core-moos through 10.4.0 contains a pre-authentication heap overflow vulnerability in MOOSCommPkt packet handling that allows remote attackers to write arbitrary data by declaring a negative packet length. Attackers can exploit the signed integer check in InflateTo() and negative size conversion in recv() to overflow a four-byte heap buffer during the HandShake phase before authentication.
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 MOOS core-moos software suite, specifically through version 10.4.0, contains a critical pre-authentication vulnerability within its communication packet handling subsystem that poses significant risks to remote systems relying on this middleware for autonomous vehicle and robotics coordination. This flaw is located in the MOOSCommPkt module, which manages the serialization and deserialization of network packets used for inter-process communication. The core technical deficiency stems from an improper validation of integer values during the parsing of incoming packet headers, specifically within the InflateTo function and the underlying recv() system call interface. When a remote attacker crafts a maliciously formatted MOOSCommPkt with a negative length field in the header, the software fails to correctly interpret this signed integer as an invalid or out-of-bounds value before proceeding with memory allocation operations.
The exploitation mechanism relies on the interaction between the application logic and standard C library functions. The InflateTo function is responsible for expanding compressed data into a buffer based on declared lengths provided in the packet header. Because the length field is treated as a signed integer, an attacker can supply a negative value which, when passed to memory allocation routines or size calculation methods that expect unsigned integers or perform implicit type conversions, results in a massive positive number due to two's complement representation rules. Consequently, the system attempts to allocate and write data into a heap buffer based on this erroneously large calculated size rather than rejecting the malformed packet immediately. This leads directly to a heap overflow condition where arbitrary amounts of data are written beyond the boundaries of the allocated four-byte heap buffer designated for handshake processing during the pre-authentication phase.
This vulnerability is particularly severe because it occurs before any authentication checks are performed, classifying it as a pre-authentication remote code execution vector. During the HandShake phase, MOOS establishes initial connections between nodes in a distributed system. An attacker positioned on the network can send these crafted packets to trigger the overflow without needing valid credentials or established trust relationships with the target node. The ability to write arbitrary data into heap memory allows for sophisticated exploitation techniques such as overwriting function pointers, control flow hijacking, or corrupting adjacent metadata structures like allocation headers. This level of memory corruption typically leads to application crashes and can be leveraged to execute arbitrary code on the host system with the privileges of the MOOS process, effectively compromising the integrity and availability of any autonomous platform relying on this software stack.
From a classification perspective, this vulnerability aligns closely with CWE-190 Integer Overflow or Wraparound, as the root cause is the mishandling of signed integers leading to incorrect memory sizing calculations. It also maps to CWE-787 Out-of-bounds Write, which describes writing data beyond the allocated buffer boundaries. In terms of offensive security frameworks like MITRE ATT&CK, this vulnerability facilitates Initial Access and potentially Privilege Escalation depending on the execution context of the MOOS daemon. The attack vector is classified as Network-based with a low complexity requirement for exploitation given that it requires only network connectivity to the target port running the MOOS communication service.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The most effective solution is to upgrade to a patched version of MOOS core-moos where this integer validation logic has been corrected to explicitly check for negative values or excessively large positive values before proceeding with memory allocation. If an update is not immediately feasible, network-level mitigations should be implemented to restrict access to the specific ports used by MOOSCommPkt traffic, ensuring that only trusted internal nodes can initiate handshake sequences. Additionally, deploying intrusion detection systems capable of inspecting packet headers for anomalous length fields or malformed serialization patterns can help identify and block exploitation attempts in real-time. Developers reviewing similar codebases should enforce strict input validation on all integer values derived from untrusted network sources, utilizing unsigned types where appropriate and implementing explicit bounds checking to prevent overflow conditions that lead to heap corruption vulnerabilities.