CVE-2026-85438 in MOOS-IvP
Summary
by MITRE • 09/04/2026
MOOS-IvP through 24.8.1 contains a buffer overflow vulnerability in StringToIvPFunction() where dimension, piece, and degree counts from encoded BHV_IPF payloads are used as allocation sizes and loop bounds without validation. Attackers can supply crafted payloads with mismatched dimension values to write attacker-controlled doubles past the end of the IvPBox weight array, causing memory corruption and potential code execution.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in MOOS-IvP versions up through 24.8.1 represents a critical buffer overflow condition located within the StringToIvPFunction() routine. This function is responsible for parsing encoded BHV_IPF payloads, which are used to define Inverse Potential Field behaviors for autonomous underwater vehicles and other robotic systems. The core technical flaw stems from an insufficient validation of input data before it is utilized for memory management operations. Specifically, the function extracts dimension, piece, and degree counts directly from the incoming payload structure without performing rigorous bounds checking or consistency verification against expected limits. These extracted values are then immediately used as parameters to allocate memory for the IvPBox weight array and subsequently serve as loop boundaries during data processing. This design decision assumes that all incoming payloads will adhere strictly to predefined structural constraints, an assumption that is easily violated by malicious actors capable of crafting arbitrary input sequences.
The operational impact of this vulnerability is severe due to its potential for remote code execution. When an attacker supplies a crafted payload containing mismatched or excessively large dimension values, the application allocates memory based on these untrusted inputs but fails to ensure they align with actual array capacities or logical limits. As the parsing routine proceeds, it writes attacker-controlled double-precision floating-point numbers into the IvPBox weight array using indices derived from the unchecked loop bounds. Because there is no safeguard preventing access beyond the allocated buffer boundaries, this results in a heap-based buffer overflow. The immediate consequence of such an overflow is memory corruption, where adjacent data structures are overwritten with arbitrary values. In modern software environments, particularly those involving complex control systems like MOOS-IvP, careful manipulation of these corrupted memory regions can allow an attacker to overwrite function pointers or return addresses on the stack, thereby hijacking program execution flow and achieving arbitrary code execution with the privileges of the compromised process.
From a classification perspective, this vulnerability aligns closely with CWE-120, which denotes Buffer Copy without Checking Size of Input Classic buffer overflow, as well as CWE-787, indicating Out-of-bounds Write. The lack of input validation prior to memory allocation and array access also reflects weaknesses associated with CWE-20 Improper Input Validation. In the context of the MITRE ATT&CK framework, this exploit vector facilitates initial code execution techniques such as T1203 Exploitation for Client Execution or potentially more advanced lateral movement if the compromised system is part of a larger networked fleet. The severity is further amplified by the nature of MOOS-IvP applications, which often run in real-time environments where stability and integrity are paramount. A successful exploitation could lead not only to security breaches but also to catastrophic failures in autonomous navigation logic, posing significant risks to physical assets and operational safety.
Mitigation strategies for this vulnerability must address both immediate remediation and long-term defensive coding practices. The primary fix involves implementing strict validation checks within the StringToIvPFunction() routine before any memory allocation or loop initialization occurs. Developers should verify that dimension, piece, and degree values fall within expected minimum and maximum thresholds consistent with the BHV_IPF specification. Additionally, bounds checking must be enforced during array access to ensure that indices never exceed the allocated size of the IvPBox weight array. Beyond code fixes, organizations deploying MOOS-IvP systems should apply vendor-provided patches immediately upon release for versions 24.8.1 and earlier. For environments where patching is not instantly feasible, network-level controls such as firewalls or intrusion detection systems can be configured to inspect incoming BHV_IPF payloads for anomalous sizes or malformed structures that deviate from standard protocol expectations. Furthermore adopting secure coding standards like CERT C or MISRA C during future development cycles will help prevent similar input validation failures across the codebase, ensuring robustness against memory corruption attacks in critical autonomous systems infrastructure.