Core Moos
Monthly
Unauthenticated buffer over-read in MOOS core-moos through 10.4.0 allows any attacker with TCP access to the MOOSDB port to crash the server or leak process memory by sending a crafted 4-byte packet. The CMOOSCommPkt deserialization path fails to validate that the declared packet length meets the minimum header size before calling Serialize(), causing it to read the message-count field from memory beyond the end of the received data. No authentication is required - exploitation precedes any credential exchange, making this reachable on any exposed MOOSDB instance. No public exploit has been identified at time of analysis, but the fix PR (GitHub #75) precisely documents the trigger condition.
Remote process termination in MOOS core-moos through 10.4.0 allows any multicast-reachable attacker to forcibly shut down arbitrary MOOS processes by exploiting a hard-coded passphrase embedded in the SuicidalSleeper component. The passphrase 'elks have been know to waltz' was compiled directly into SuicidalSleeper.cpp and is publicly visible in the open-source repository, enabling unauthenticated adjacent attackers to enumerate running MOOS processes and issue termination commands via the default multicast group and port. No public exploit has been identified at time of analysis, but the static passphrase effectively eliminates any practical authentication barrier for multicast-adjacent peers.
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.
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.
Uncontrolled memory allocation in MOOS core-moos through 10.4.0 exposes MOOSDB servers to pre-authentication denial of service. The CMOOSCommPkt::OnBytesWritten() function reads the packet length field directly from untrusted wire data and passes it without any upper-bound check to new unsigned char[], allowing unbounded heap allocation before any client authentication handshake occurs. An unauthenticated network attacker can craft packets with arbitrarily large declared lengths to exhaust server memory and crash the MOOSDB process; no public exploit has been identified at time of analysis, and an upstream patch is available via GitHub commit e7ea624.
Unauthenticated denial-of-service in MOOS core-moos through 10.4.0 allows remote attackers to crash the central MOOSDB process by sending a single crafted message containing a negative serialized string length value. The negative integer passes the existing arithmetic check in CMOOSMsg::operator>> but is then implicitly widened to an enormous size_t by string allocation routines, triggering an unhandled std::exception that escapes the server accept loop and terminates the MOOSDB process - halting all MOOS inter-process communication. No public exploit code or CISA KEV entry is confirmed, but the VulnCheck advisory and linked source code provide sufficient detail to reproduce the crash trivially.
Remote code execution risk in MOOS core-moos through 10.4.0 arises from a pre-authentication heap overflow in MOOSCommPkt packet handling, where a remote attacker declares a negative packet length to write arbitrary data into a four-byte heap buffer during the connection HandShake, before any authentication occurs. Any exposed MOOSDB robotics-middleware instance is affected, and because the flaw is triggered by an attacker-controlled length read straight off the wire, it can be reached with a single crafted packet. No public exploit identified at time of analysis, though the issue was reported and detailed by VulnCheck and a fix is available.
MOOSDB in core-moos through 10.4.0 accepts wire-supplied source identifiers verbatim instead of enforcing the authenticated connection identity, enabling any authenticated MOOS client to forge message origins and impersonate arbitrary registered processes within the broker. Exploitation allows an attacker to attribute writes to a victim client and invoke subscription cancellations as if originating from that client, corrupting the publish-subscribe integrity of the entire MOOS community. No active exploitation has been confirmed (not in CISA KEV), but the vulnerable code path is fully exposed by the published fix in GitHub PR #76, making the flaw straightforward to exploit for any connected attacker.
Unauthenticated variable write in MOOS core-moos through 10.4.0 lets any client that can reach the optional MOOSDB HTTP server port set arbitrary MOOS variables - including actuator and override commands - because the web server enforces no credential of any kind. In vulnerable builds the HTTP 'poke' path is always live, so a single crafted GET/POST can alter the shared runtime blackboard that drives autonomous-vehicle behavior. Reported by VulnCheck with a vendor patch available (PR #77 / commit 7e3aecd); no public exploit identified at time of analysis, and it is not listed in CISA KEV.
Unauthenticated full compromise of the MOOSDB message bus in MOOS core-moos through 10.4.0, where the wire protocol performs no client authentication. Any attacker who can reach the MOOSDB TCP port can bypass the compile-time protocol-string check, connect under an arbitrary client name, and gain unrestricted publish, subscribe, and administrative privileges - including the DB_CLEAR operation that wipes all variables and client mail queues. VulnCheck reported the flaw and an upstream fix (shared-key handshake) exists in PR #84; no public exploit has been identified at time of analysis, though the attack is trivial to script.
Stack corruption with potential code execution in MOOS core-moos through version 10.4.0 arises from an off-by-one error in CMOOSSerialPort::GetTelegram(), where a NUL terminator is written one byte past the end of a fixed-size stack buffer. An attacker who controls the serial communication line connected to a MOOS-enabled platform can send a full-length telegram to trigger the overwrite, corrupting adjacent stack memory and potentially redirecting execution. A vendor patch is available via GitHub PR #73 and commit befb04df; no public exploit has been identified at time of analysis.
Stored cross-site scripting in MOOS core-moos through 10.4.0 allows any MOOS publisher to inject script payloads into the MOOSDB HTTP monitoring interface. Because MOOS clients are inherently unauthenticated by protocol design, attackers with network access to a MOOS community can set variable names, values, source process names, or community names to contain HTML/script markup that is rendered unescaped in the operator's browser. The fix (PR #78) adds a comprehensive HTMLEscape() function covering all attacker-controlled database fields, plus a restrictive Content-Security-Policy header as a secondary control.
Unauthenticated buffer over-read in MOOS core-moos through 10.4.0 allows any attacker with TCP access to the MOOSDB port to crash the server or leak process memory by sending a crafted 4-byte packet. The CMOOSCommPkt deserialization path fails to validate that the declared packet length meets the minimum header size before calling Serialize(), causing it to read the message-count field from memory beyond the end of the received data. No authentication is required - exploitation precedes any credential exchange, making this reachable on any exposed MOOSDB instance. No public exploit has been identified at time of analysis, but the fix PR (GitHub #75) precisely documents the trigger condition.
Remote process termination in MOOS core-moos through 10.4.0 allows any multicast-reachable attacker to forcibly shut down arbitrary MOOS processes by exploiting a hard-coded passphrase embedded in the SuicidalSleeper component. The passphrase 'elks have been know to waltz' was compiled directly into SuicidalSleeper.cpp and is publicly visible in the open-source repository, enabling unauthenticated adjacent attackers to enumerate running MOOS processes and issue termination commands via the default multicast group and port. No public exploit has been identified at time of analysis, but the static passphrase effectively eliminates any practical authentication barrier for multicast-adjacent peers.
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.
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.
Uncontrolled memory allocation in MOOS core-moos through 10.4.0 exposes MOOSDB servers to pre-authentication denial of service. The CMOOSCommPkt::OnBytesWritten() function reads the packet length field directly from untrusted wire data and passes it without any upper-bound check to new unsigned char[], allowing unbounded heap allocation before any client authentication handshake occurs. An unauthenticated network attacker can craft packets with arbitrarily large declared lengths to exhaust server memory and crash the MOOSDB process; no public exploit has been identified at time of analysis, and an upstream patch is available via GitHub commit e7ea624.
Unauthenticated denial-of-service in MOOS core-moos through 10.4.0 allows remote attackers to crash the central MOOSDB process by sending a single crafted message containing a negative serialized string length value. The negative integer passes the existing arithmetic check in CMOOSMsg::operator>> but is then implicitly widened to an enormous size_t by string allocation routines, triggering an unhandled std::exception that escapes the server accept loop and terminates the MOOSDB process - halting all MOOS inter-process communication. No public exploit code or CISA KEV entry is confirmed, but the VulnCheck advisory and linked source code provide sufficient detail to reproduce the crash trivially.
Remote code execution risk in MOOS core-moos through 10.4.0 arises from a pre-authentication heap overflow in MOOSCommPkt packet handling, where a remote attacker declares a negative packet length to write arbitrary data into a four-byte heap buffer during the connection HandShake, before any authentication occurs. Any exposed MOOSDB robotics-middleware instance is affected, and because the flaw is triggered by an attacker-controlled length read straight off the wire, it can be reached with a single crafted packet. No public exploit identified at time of analysis, though the issue was reported and detailed by VulnCheck and a fix is available.
MOOSDB in core-moos through 10.4.0 accepts wire-supplied source identifiers verbatim instead of enforcing the authenticated connection identity, enabling any authenticated MOOS client to forge message origins and impersonate arbitrary registered processes within the broker. Exploitation allows an attacker to attribute writes to a victim client and invoke subscription cancellations as if originating from that client, corrupting the publish-subscribe integrity of the entire MOOS community. No active exploitation has been confirmed (not in CISA KEV), but the vulnerable code path is fully exposed by the published fix in GitHub PR #76, making the flaw straightforward to exploit for any connected attacker.
Unauthenticated variable write in MOOS core-moos through 10.4.0 lets any client that can reach the optional MOOSDB HTTP server port set arbitrary MOOS variables - including actuator and override commands - because the web server enforces no credential of any kind. In vulnerable builds the HTTP 'poke' path is always live, so a single crafted GET/POST can alter the shared runtime blackboard that drives autonomous-vehicle behavior. Reported by VulnCheck with a vendor patch available (PR #77 / commit 7e3aecd); no public exploit identified at time of analysis, and it is not listed in CISA KEV.
Unauthenticated full compromise of the MOOSDB message bus in MOOS core-moos through 10.4.0, where the wire protocol performs no client authentication. Any attacker who can reach the MOOSDB TCP port can bypass the compile-time protocol-string check, connect under an arbitrary client name, and gain unrestricted publish, subscribe, and administrative privileges - including the DB_CLEAR operation that wipes all variables and client mail queues. VulnCheck reported the flaw and an upstream fix (shared-key handshake) exists in PR #84; no public exploit has been identified at time of analysis, though the attack is trivial to script.
Stack corruption with potential code execution in MOOS core-moos through version 10.4.0 arises from an off-by-one error in CMOOSSerialPort::GetTelegram(), where a NUL terminator is written one byte past the end of a fixed-size stack buffer. An attacker who controls the serial communication line connected to a MOOS-enabled platform can send a full-length telegram to trigger the overwrite, corrupting adjacent stack memory and potentially redirecting execution. A vendor patch is available via GitHub PR #73 and commit befb04df; no public exploit has been identified at time of analysis.
Stored cross-site scripting in MOOS core-moos through 10.4.0 allows any MOOS publisher to inject script payloads into the MOOSDB HTTP monitoring interface. Because MOOS clients are inherently unauthenticated by protocol design, attackers with network access to a MOOS community can set variable names, values, source process names, or community names to contain HTML/script markup that is rendered unescaped in the operator's browser. The fix (PR #78) adds a comprehensive HTMLEscape() function covering all attacker-controlled database fields, plus a restrictive Content-Security-Policy header as a secondary control.