CVE-2026-85443 in core-moos
Summary
by MITRE • 09/04/2026
MOOS core-moos through 10.4.0 contains a denial of service vulnerability in MOOSCommServer::ListenLoop() where the accept thread performs a blocking receive without timeout during the wire-protocol handshake. An attacker can open a TCP connection to the MOOSDB port and send no data, causing the accept thread to block indefinitely while holding the socket-list lock, preventing all subsequent client connections.
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 vulnerability identified in MOOS core versions through 10.4.0 represents a significant denial of service risk within the MOOSCommServer::ListenLoop() component. This flaw stems from an improper handling of network connection states during the initial wire-protocol handshake phase. Specifically, when the server accepts a new TCP connection, it initiates a blocking receive operation to gather data required for authentication or protocol negotiation. Crucially, this read operation is configured without any timeout mechanism, meaning the thread will remain suspended indefinitely if no bytes are received from the connecting client. This design oversight creates a resource exhaustion vector that can be exploited by malicious actors to disrupt service availability for legitimate users.
From an operational perspective, the impact of this vulnerability extends beyond simple connection blocking due to the locking strategy employed by the server. The accept thread holds the socket-list lock while waiting for data from the unresponsive client. In many networked applications, such locks are used to protect shared resources like lists of active connections or configuration states. By holding this lock indefinitely, the vulnerable thread effectively freezes the entire listening mechanism. Consequently, no new clients can establish connections with the MOOSDB port, rendering the system unable to accept any further requests until the blocked thread is terminated or the connection times out at a lower network layer, which may not occur for extended periods depending on OS settings and firewall rules.
This vulnerability aligns closely with Common Weakness Enumeration (CWE) categories such as CWE-400: Uncontrolled Resource Consumption and CWE-770: Allocation of Resources Without Limits or Throttling. The lack of a timeout mechanism constitutes an unbounded wait state, allowing an attacker to consume server threads without limit. Furthermore, the exploitation technique maps directly to MITRE ATT&CK tactic TA0004: Impact, specifically under techniques related to Denial of Service (DoS). An adversary can perform this attack by opening a TCP connection to the MOOSDB port and simply remaining silent, thereby triggering the blocking receive condition without needing to send any malicious payload or exploit code beyond establishing the initial handshake.
Mitigation strategies for this vulnerability should focus on implementing robust timeout policies in network communication layers. Developers must ensure that all blocking I/O operations, particularly during authentication and protocol negotiation phases, are equipped with appropriate timeouts. This ensures that if a client fails to respond within a reasonable timeframe, the connection is terminated, and resources such as threads and locks are released back to the system pool. Additionally, implementing rate limiting or connection throttling can help mitigate the impact of volumetric attacks by restricting the number of simultaneous connections from single sources. For users running affected versions up to 10.4.0, applying vendor-provided patches that address this specific flaw in MOOSCommServer is essential to restore service resilience and prevent unauthorized denial of service conditions.