CVE-2026-85450 in core-moos
Summary
by MITRE • 09/04/2026
MOOS core-moos through 10.4.0 contains a denial of service vulnerability in the MOOSDB HTTP server that creates unbounded connections and threads without limits. Attackers can open many connections and send endless header data to exhaust server threads and memory, causing service unavailability.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified within MOOS core-moos versions up to 10.4.0 represents a critical denial of service flaw located in the HTTP server component of the MOOSDB subsystem. This issue stems from an architectural deficiency where the server fails to implement adequate resource management controls for incoming network connections and associated processing threads. Specifically, the system does not enforce limits on the number of concurrent connections or the volume of data accepted during the header parsing phase. This lack of constraint allows external actors to exploit the unbounded nature of these resources by initiating a high volume of simultaneous HTTP requests. The core technical flaw is categorized under CWE-787 as an out-of-bounds write in certain contexts, but more accurately aligns with CWE-400 regarding unconstrained resource consumption. By leveraging this weakness, an attacker can systematically exhaust the server's available memory and thread pool capacity, leading to a complete cessation of service for legitimate users attempting to interact with the MOOSDB infrastructure.
From an operational perspective, the impact of this vulnerability is severe as it directly compromises the availability component of the CIA triad. The MOOS platform is widely utilized in autonomous marine systems and robotics research, where reliable communication between nodes is essential for mission-critical operations such as navigation, sensor data aggregation, and command execution. When the HTTP server becomes unresponsive due to resource exhaustion, these interconnected systems may fail to receive updates or commands, potentially leading to loss of control over robotic assets or failure in coordinated multi-agent tasks. The attack vector allows for remote exploitation without requiring authentication, meaning any entity with network access to the MOOSDB service can trigger this condition. This significantly lowers the barrier for entry for malicious actors who might seek to disrupt operations through simple resource exhaustion techniques rather than complex code execution exploits.
The behavior of this vulnerability maps directly to specific tactics and techniques within the MITRE ATT&CK framework, particularly those associated with Denial of Service attacks against network services. It aligns with technique T1498, which covers Network Denial of Service, specifically sub-techniques involving resource exhaustion through connection flooding or header manipulation. The exploitation method involves sending endless header data to overwhelm the server's parsing logic and thread allocation mechanisms. This pattern is consistent with known vulnerabilities in web servers that fail to validate input size limits before allocating memory buffers for request headers. Such oversights are common in older codebases where security constraints were not prioritized during initial development, resulting in systems that assume a trusted or low-volume environment rather than preparing for adversarial conditions typical of modern networked deployments.
Mitigation strategies must focus on implementing strict resource controls and input validation mechanisms within the MOOSDB HTTP server module. Developers should enforce maximum limits on concurrent connections to prevent thread pool exhaustion, utilizing connection pooling algorithms that queue requests when capacity is reached rather than spawning new threads indefinitely. Additionally, hardening measures such as setting explicit timeouts for header parsing and defining maximum allowable sizes for HTTP headers are essential to mitigate the risk of memory exhaustion. Upgrading to a patched version of MOOS core-moos beyond 10.4.0 where these constraints have been implemented is the primary remediation path. In environments where immediate patching is not feasible, network-level protections such as rate limiting at the firewall or load balancer level can help absorb excessive connection attempts and protect the underlying application from being overwhelmed by malicious traffic patterns.