EUVD-2026-70777
GHSA-qqc5-c4q6-4q3x
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach MOOSDB TCP port
-
DeliveryOpen TCP connection, send no bytes
-
ExploitAccept thread blocks in iRecieveMessage()
-
ExecutionSocket-list lock held indefinitely
-
PersistAll MOOS client connections denied
-
ImpactMOOSDB inoperable
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource consumption limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | No special conditions beyond network reachability of the MOOSDB TCP port. The vulnerability is present in any default deployment of core-moos through 10.4.0 where MOOSDB is running and the listening port is reachable. A single TCP SYN/connect - with zero subsequent bytes sent - is sufficient to trigger the DoS; no handshake knowledge, credentials, or protocol awareness is required. Exploitation is limited by the MOOSDB port being accessible: in the typical isolated robotics-lab or air-gapped vehicle network, an attacker must have adjacent physical or network access. If MOOSDB is inadvertently exposed to a broader network segment, any remote unauthenticated party can trigger the condition. Restoring service requires restarting the MOOSDB process, which terminates the stalled connection and resets the accept thread. |
| Impact | The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H) scores 8.7, which accurately reflects the no-auth, network-reachable, high-availability-impact nature of the flaw - the vector metrics are consistent with the described mechanism and there is no apparent inflation. Real-world risk is moderated by deployment context: MOOS is specialized robotics and maritime autonomy middleware, most commonly deployed in air-gapped or isolated research and naval networks where MOOSDB would not be exposed to untrusted peers. For deployments where MOOSDB is reachable from an untrusted network segment, exploitation risk is high - the attack is a single TCP connection requiring no credentials or protocol knowledge. No KEV listing or public PoC has been identified; EPSS data is not available in the provided input. The primary risk surface is mission-critical autonomous vehicle deployments where connectivity disruption has safety implications beyond mere service unavailability. |
| Exploit ScenarioDerived | An attacker with network access to the MOOSDB port - even from an adjacent LAN segment on an autonomous vehicle platform - opens a TCP connection to port 9000 (or configured MOOSDB port) and deliberately sends no bytes. The accept thread immediately blocks in iRecieveMessage() while holding the socket-list lock; within milliseconds, all legitimate MOOS clients attempting to register (navigation, sensor, and actuator modules) are denied connections. The autonomous system's inter-module communication collapses, potentially causing a mission-critical failure or safety incident. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 03, 2026
Denial-of-service in MOOS core-moos through 10.4.0 allows any unauthenticated network peer to permanently freeze the MOOSDB accept thread by opening a TCP connection to the MOOSDB port and sending no data during the wire-protocol handshake. Because the accept thread executes a blocking receive without any timeout while holding the socket-list lock, a single stalled connection prevents all subsequent MOOS clients from registering, effectively rendering the publish-subscribe middleware inoperable. No public exploit code or active exploitation has been identified; however, the attack requires only a single TCP connection and no credentials, making it trivially automatable against any exposed MOOSDB instance.
RemediationAI
The upstream fix is available in GitHub commit 8d940303949a850d4625eca2a60f27adee9c3ec4 (https://github.com/themoos/core-moos/commit/8d940303949a850d4625eca2a60f27adee9c3ec4), which replaces the blocking iRecieveMessage() call with iReadMessageWithTimeOut() bounded by the new MOOS_SERVER_HANDSHAKE_TIMEOUT constant of 5 seconds. Operators should rebuild from the patched main branch; no released tagged version incorporating the fix has been confirmed, so verify the commit is present before deploying. As a compensating control where patching is not immediately possible, restrict network access to the MOOSDB TCP port (typically 9000) using host-based firewall rules or network ACLs to allow only trusted MOOS client hosts - this is the most effective mitigation because it eliminates the untrusted peer precondition entirely. A connection-rate limiter at the network perimeter (e.g., iptables connlimit) can reduce but not eliminate risk, as a single persistent connection suffices to trigger the bug. Monitoring for stalled TCP connections on the MOOSDB port with no data transmitted can provide early detection.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
MOOS (Mission Oriented Operating Suite) is a C++ middleware framework providing a publish-subscribe communications architecture for autonomous robotic and maritime systems. Its central broker, MOOSDB, runs a single accept thread (MOOSCommServer::ListenLoop) that sequentially processes incoming TCP connections and performs an initial wire-protocol handshake exchange before handing clients off. The vulnerable code, located at Core/libMOOS/Comms/MOOSCommServer.cpp line ~922, called iRecieveMessage() - a blocking read with no deadline - on the accept thread itself. Because this thread serializes all new connections, a peer that connects but never sends handshake bytes parks the thread indefinitely, and the socket-list lock it holds ensures no concurrent client can join. CWE-400 (Uncontrolled Resource Consumption) accurately describes the root cause: a single connection consumes the sole accept thread as an unbounded resource. The fix, introduced in PR #83 via iReadMessageWithTimeOut() with a defined MOOS_SERVER_HANDSHAKE_TIMEOUT of 5 seconds, bounds the handshake window and breaks the deadlock.
Know when Core Moos gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Network-reachable, no auth or complexity; sole impact is complete availability loss of MOOSDB accept thread; no confidentiality or integrity effect.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
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.
Executive ViewAI
MOOS core-moos (through version 10.4.0) provides the MOOSDB middleware that manages real-time inter-process communication for robotics, autonomous vehicles, and research systems. Any unauthenticated attacker can trivially exploit a simple protocol flaw-sending a single incomplete network connection-to permanently freeze the service and prevent new applications from registering, effectively disabling all dependent operations. Organizations with network-exposed MOOSDB instances face high risk of unplanned downtime and mission failure.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Remote code execution risk in MOOS core-moos through 10.4.0 arises from a pre-authentication heap overflow in MOOSCommPk
Unauthenticated variable write in MOOS core-moos through 10.4.0 lets any client that can reach the optional MOOSDB HTTP
Unauthenticated full compromise of the MOOSDB message bus in MOOS core-moos through 10.4.0, where the wire protocol perf
Unauthenticated buffer over-read in MOOS core-moos through 10.4.0 allows any attacker with TCP access to the MOOSDB port
MOOSDB in core-moos through 10.4.0 accepts wire-supplied source identifiers verbatim instead of enforcing the authentica
Uncontrolled memory allocation in MOOS core-moos through 10.4.0 exposes MOOSDB servers to pre-authentication denial of s
Unauthenticated denial-of-service in MOOS core-moos through 10.4.0 allows remote attackers to crash the central MOOSDB p
Resource exhaustion in the MOOSDB HTTP server component of MOOS core-moos through 10.4.0 allows unauthenticated remote a
Remote process termination in MOOS core-moos through 10.4.0 allows any multicast-reachable attacker to forcibly shut dow
Stored cross-site scripting in MOOS core-moos through 10.4.0 allows any MOOS publisher to inject script payloads into th
Stack corruption with potential code execution in MOOS core-moos through version 10.4.0 arises from an off-by-one error
Exploit-DB