CVE-2026-85452 in ui-moos
Summary
by MITRE • 09/04/2026
MOOS ui-moos through 50b9c6c contains a buffer overflow vulnerability in ScopeTabPane.cpp and ScopeGrid.cpp where client and variable names are formatted into fixed 1024-byte buffers using sprintf without length validation. Attackers can supply arbitrarily long MOOS identifiers that overflow the buffers when an operator selects process list entries or pokes variables, enabling code execution.
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 versions up to commit 50b9c6c represents a critical memory safety failure rooted in improper handling of user-supplied input within the graphical interface components ScopeTabPane.cpp and ScopeGrid.cpp. This flaw is classified under CWE-120, which denotes buffer overflow without bounds checking, specifically manifesting as a stack-based or heap-based overflow depending on the allocation strategy used for the fixed buffers. The core technical issue arises from the use of the sprintf function to format client names and variable identifiers into static 1024-byte character arrays. Unlike safer alternatives such as snprintf, which accepts a maximum buffer size argument to prevent writing beyond allocated memory boundaries, sprintf performs no length validation on the input string prior to copying it into the destination buffer. This design decision assumes that all incoming MOOS identifiers will remain within safe limits, an assumption that is easily violated by malicious actors capable of controlling or influencing the data sources connected to the MOOS middleware infrastructure.
From a technical perspective, when an operator interacts with the system by selecting entries from the process list or attempting to poke variables, the application retrieves the associated name strings and passes them directly into sprintf calls. If these identifiers are crafted to exceed 1024 bytes in length, the excess data overwrites adjacent memory locations on the stack or heap. This out-of-bounds write corrupts critical program state information, such as return addresses, frame pointers, or function pointers stored nearby in memory. In modern exploitation scenarios, this corruption allows an attacker to redirect control flow to arbitrary code injected into the process address space. The vulnerability is particularly dangerous because it can be triggered through normal operational interactions with the user interface, meaning that a remote attacker who has established a connection to the MOOS server and can send specially crafted messages or manipulate data sources visible in the UI can achieve remote code execution without requiring physical access or elevated privileges on the host system.
The operational impact of this vulnerability is severe, potentially leading to complete compromise of the systems running the MOOS software. Since MOOS is frequently deployed in autonomous underwater vehicles and other critical infrastructure applications where real-time control and monitoring are essential, successful exploitation could allow an attacker to take full control of the vehicle or sensor network. This includes the ability to execute arbitrary commands, exfiltrate sensitive telemetry data, modify navigation parameters, or cause denial of service by crashing the application. The presence of this flaw in both ScopeTabPane.cpp and ScopeGrid.cpp suggests that multiple entry points exist for exploitation, increasing the attack surface significantly. Furthermore, because the vulnerability relies on user interaction with specific UI elements like process lists and variable pokes, it may be difficult to detect through automated network scanning alone, requiring targeted social engineering or insider threats if not properly mitigated at the code level.
To mitigate this risk, immediate remediation is required by replacing all instances of sprintf used for formatting client and variable names with snprintf, ensuring that the buffer size limit of 1024 bytes is strictly enforced during string operations. Additionally, input validation should be implemented to truncate or reject identifiers exceeding expected length limits before they are processed by UI components. Developers should also consider adopting safer C++ standard library functions such as std::string and std::to_string where applicable to eliminate manual memory management errors entirely. From a defensive standpoint, organizations deploying MOOS should enable compiler security features like stack canaries (e.g., -fstack-protector-strong), Address Sanitizer during testing phases, and Data Execution Prevention on target systems to mitigate the impact of any remaining exploitable flaws. This vulnerability aligns with MITRE ATT&CK technique T1059 Command and Scripting Interpreter if exploited for initial access or lateral movement within a networked environment involving MOOS-based assets.