CVE-2026-85456 in MOOS-IvP
Summary
by MITRE • 09/04/2026
MOOS-IvP through 24.8.1 fails to properly validate variable names extracted from alog files in the SplitHandler, allowing attackers to write files outside the split directory. Attackers can supply crafted alog files with backslash sequences in variable names to escape the output directory and append to arbitrary files on Windows systems.
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-IvP versions through 24.8.1 represents a critical path traversal flaw within the SplitHandler component, specifically affecting how variable names are parsed from autonomous log (alog) files. This issue stems from insufficient validation of input data extracted during the file processing routine. When the system ingests an alog file, it attempts to parse specific variables and write their corresponding values into separate output files organized under a designated split directory. The core technical failure lies in the lack of sanitization for special characters within these variable names, particularly backslash sequences on Windows operating systems. Because the application does not strictly enforce that the resulting filename remains confined to the intended subdirectory, an attacker can manipulate this parsing logic by embedding path traversal characters directly into the variable name field of a crafted alog file.
On Microsoft Windows platforms, the use of backward slashes as directory separators allows for effective escape sequences when processed without proper normalization or validation. By constructing a malicious payload where the variable name includes a sequence such as ..\ followed by an arbitrary filename, the attacker forces the SplitHandler to interpret part of the string as a directory navigation command rather than a literal character in the file name. Consequently, instead of creating a new file within the secure split directory, the application writes data directly into parent directories or completely different locations on the filesystem where it has write permissions. This behavior constitutes an arbitrary file write vulnerability, which is fundamentally distinct from simple information disclosure because it allows for active modification of system files rather than just reading sensitive data.
The operational impact of this flaw is severe and multifaceted depending on the execution context of the MOOS-IvP application. If the software runs with elevated privileges or as a service with broad filesystem access, an attacker could overwrite critical configuration files, replace executable binaries to achieve remote code execution, or corrupt essential system logs to hinder incident response efforts. Even in lower-privilege scenarios, the ability to write arbitrary files can facilitate further attacks by planting malicious scripts that execute upon user interaction or by modifying environment variables and registry entries if those paths are accessible. This vulnerability effectively undermines the integrity of the autonomous vehicle control system's data processing pipeline, potentially leading to incorrect navigation decisions or complete system compromise if critical components are tampered with via this file write mechanism.
From a classification perspective, this flaw aligns closely with CWE-22 Improper Limitation of a Pathname to a Restricted Directory and CWE-94 Improper Control of Generation of Code (Code Injection), as the input is directly used in file system operations without adequate restriction. In terms of adversary tactics, this technique corresponds to ATT&CK T1078 Valid Accounts or more broadly to resource hijacking methods where attackers leverage legitimate software functions for unauthorized access and modification. The exploitation relies on social engineering or network interception to deliver the crafted alog files, making it relevant to initial access vectors that involve malicious file delivery.
Mitigation strategies must focus on strict input validation and defensive programming practices within the SplitHandler module. Developers should implement allow-listing for variable names, ensuring they contain only alphanumeric characters and safe punctuation while explicitly rejecting any path traversal sequences such as dots combined with slashes or backslashes. Additionally, employing canonicalization techniques to resolve all relative paths before file creation can prevent directory escape attempts regardless of how many layers of obfuscation an attacker uses. It is also advisable to utilize secure API functions that inherently restrict output locations, such as those provided by modern operating system security libraries which enforce chroot-like behaviors or strict sandboxing for temporary file operations. Updating to a patched version where these validation checks are enforced is the primary remediation step required to eliminate this risk vector immediately.