Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify exposed MOOSDB HTTP port
-
DeliveryOpen many simultaneous TCP connections
-
ExploitSend non-terminating or oversized header data per connection
-
ExecutionHold threads and file descriptors without timeout eviction
-
PersistExhaust MOOSDB thread pool and memory
-
ImpactMOOSDB becomes unresponsive, severing all MOOS module communication
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation 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 are required for exploitation. The MOOSDB HTTP server accepts unauthenticated TCP connections by default on any network interface it is bound to, and no session state, credential, or prior interaction is needed before the resource exhaustion begins. The sole prerequisite is network reachability to the MOOSDB HTTP port. Deployments that bind MOOSDB exclusively to the loopback interface or that enforce strict firewall rules restricting access to the HTTP port to trusted hosts are substantially protected, as the attack surface does not exist if the port is inaccessible. All versions through 10.4.0 are affected regardless of any other MOOSDB configuration setting. |
| Impact | The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) is internally consistent: the attack is fully unauthenticated, requires no special configuration, is reachable over the network, and results in full availability loss of the MOOSDB process. No EPSS data was provided, and the vulnerability is not currently listed in CISA KEV, indicating exploitation has not yet been observed at scale. Despite the absence of a public exploit, the attack primitive is elementary - a simple TCP client sending non-terminating data - so automatable mass exploitation is feasible whenever MOOSDB HTTP ports are exposed. For production MOOS deployments, MOOSDB is the single communication hub for all MOOS modules; crashing it severs all inter-module messaging, making this a mission-critical availability threat even in a small deployment. Operators running MOOS-based AUV or field-robotics infrastructure, even a mid-sized research team in swidnica deploying MOOS on a robotic testbed, should treat the patch or network-level mitigations as an immediate priority given the zero-prerequisite exploitation path. The DoS-only impact (no confidentiality or integrity exposure) correctly limits the severity ceiling compared to a code-execution class flaw. |
| Exploit ScenarioDerived | An unauthenticated attacker with network access to the MOOSDB HTTP port opens dozens of simultaneous TCP connections and, on each connection, transmits HTTP header data character-by-character without ever sending a terminating CRLF pair or keeps sending new header lines indefinitely. Pre-patch, each connection holds one thread and one file descriptor inside the MOOSDB process with no timeout eviction; memory and thread pool exhaustion accumulates until MOOSDB is unresponsive, severing all pub-sub communication between MOOS modules and halting any autonomous system dependent on MOOSDB for inter-process messaging. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 03, 2026
Resource exhaustion in the MOOSDB HTTP server component of MOOS core-moos through 10.4.0 allows unauthenticated remote attackers to render MOOSDB unavailable by opening many simultaneous connections and sending unbounded HTTP header data. Source code analysis confirms the pre-patch implementation in CMOOSDBHTTPServer and CHTTPConnection imposed no limits on concurrent connections, header line count, per-line byte size, or per-connection read timeouts - all four controls were absent. No public exploit code or active exploitation has been identified at time of analysis, though the attack requires no authentication or special tooling and is trivially automatable.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed. Apply GitHub PR #79 (https://github.com/themoos/core-moos/pull/79) or build from commit dfef92b3bc31886bc47e4d680aef583b78cb8d72, which introduces connection-count capping, header-count limiting, per-line size limits, and read timeouts into the MOOSDB HTTP server. As a compensating control prior to patching, restrict access to the MOOSDB HTTP port at the host firewall or network perimeter to only trusted IP ranges - this eliminates the unauthenticated network exposure entirely, though it does not protect against compromised hosts within the allowed range. If MOOSDB HTTP monitoring functionality is not required, consider disabling the HTTP server feature if the MOOS build supports doing so, eliminating the attack surface without side effects on core MOOS pub-sub messaging.
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 used in robotics and autonomous maritime vehicle systems; MOOSDB is its central publish-subscribe database process. The vulnerable component, CMOOSDBHTTPServer, embeds a simple HTTP monitoring server directly inside MOOSDB (CPE: cpe:2.3:a:themoos:core-moos:*:*:*:*:*:*:*:*, versions through 10.4.0). CWE-770 (Allocation of Resources Without Limits or Throttling) is confirmed by the PR #79 diff: the Listen() loop in MOOSDBHTTPServer.cpp stored every accepted socket as a new CHTTPConnection with its own thread and no cap on the total count; ReadRequest() in HTTPConnection.cpp iterated header lines without a count bound; ReadLine() called iRecieveMessage() in a tight loop with no timeout and allowed the accumulating string to grow indefinitely. The fix introduces four hard constants: MOOS_HTTP_MAX_CONNECTIONS=32, MOOS_HTTP_MAX_HEADERS=64, MOOS_HTTP_MAX_LINE=8192 bytes, and MOOS_HTTP_READ_TIMEOUT=5 seconds, applied via iReadMessageWithTimeOut().
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
Unauthenticated network DoS with no complexity or prerequisites; impacts only MOOSDB availability, no confidentiality or integrity exposure.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
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.
Executive ViewAI
MOOS core-moos through version 10.4.0 is vulnerable to a remote denial-of-service attack allowing unauthenticated attackers to disable MOOSDB operations by exhausting HTTP server resources. No public exploit identified at time of analysis, though the attack requires only basic network tools and no special privileges. Organizations operating autonomous systems, robotics, or marine platforms face operational disruption risk without immediate patching.
Apply vendor patch.
Threat Intelligence Overview
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
Denial-of-service in MOOS core-moos through 10.4.0 allows any unauthenticated network peer to permanently freeze the MOO
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
EUVD-2026-70784
GHSA-w2px-4923-958m
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB