Themoos
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.
Stack buffer overflow in the uMS graphical operator tool of MOOS ui-moos through commit 50b9c6c allows an unauthenticated network attacker to achieve code execution on an operator workstation by injecting excessively long client or variable names into the MOOSDB pub-sub middleware. When the operator subsequently selects a malicious process list entry or pokes an oversized variable through the uMS interface, unchecked sprintf calls in ScopeTabPane.cpp and ScopeGrid.cpp overflow fixed 1024-byte stack buffers, enabling memory corruption and control-flow hijack. The upstream fix (PR #5, commit a6ebc0bc) is confirmed by direct patch diff evidence replacing all three vulnerable sprintf calls with snprintf; no public exploit code or KEV listing has been identified at time of analysis.
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.
Heap corruption in MOOS essential-moos through 10.0.1 allows unauthenticated remote attackers to crash the pMOOSBridge process by sending a single crafted UDP datagram containing a negative declared packet length. The root cause is a signed-to-unsigned type confusion in CMOOSUDPLink::ReadPktFromArray(): a negative nRqd value passes a signed bounds check unchanged, then is silently cast to a near-SIZE_MAX size_t when passed to memcpy, writing far beyond the destination heap buffer. No public exploit has been identified at time of analysis, but the attack primitive requires only network access to the UDP listen port and a small crafted payload; the upstream fix is available as a GitHub patch commit.
Unauthorized runtime route reconfiguration in MOOS essential-moos pShare through 10.0.1 lets any client of the MOOS database issue PSHARE_CMD messages to open new listeners and redirect or duplicate inter-process bus traffic. Because pre-patch builds unconditionally subscribed to PSHARE_CMD, a remote unauthenticated attacker able to publish to the MOOSDB could reroute or mirror sensor/control traffic to attacker-controlled destinations without any credentials. The vendor patch (PR #20) is available and a source-level fix is confirmed, but no public exploit or active exploitation is identified at time of analysis.
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 UDP packet injection in MOOS essential-moos pMOOSBridge through version 10.0.1 allows any network-reachable attacker to inject arbitrary variables into the local MOOS publish-subscribe community by sending crafted UDP datagrams to the configured UDPListen port, with full control over spoofed source and community identifiers. The root cause is the absence of any source-address validation in the ListenLoop: the bridge historically accepted datagrams from any sender, trusting the identity claims embedded in the payload. No public exploit has been identified at time of analysis, and a fix is available via upstream PR/commit, though a tagged release version has not been independently confirmed.
Unauthenticated UDP datagram injection in essential-moos pShare through 10.0.1 allows any network-reachable attacker to send crafted UDP packets that pShare republishes verbatim to the local MOOS community under an attacker-chosen identity, or to crash the pShare bridge process with malformed payloads. The root flaw is that pShare's Listener class used raw socket reads without capturing the sender's address, performing no source validation before deserializing and forwarding messages as authoritative MOOS community traffic. A fix is available in upstream commit 53729b6 and PR #18, which adds allowlist-based source filtering and wraps deserialization in exception handling; no public exploit code has been identified and the CVE is not in CISA KEV.
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.
Remote code execution in MOOS essential-moos pAntler through 10.0.1 lets unauthenticated attackers run arbitrary programs on a robot/vehicle host by publishing a crafted MISSION_FILE variable to the MOOSDB. pAntler's headless remote-control path parses the mission file's Run entries and launches them via execvp() with no check on who published the message, so anyone able to write to the MOOSDB can spawn processes. Reported by VulnCheck with an upstream fix (PR #17); no public exploit identified at time of analysis and it is not 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.
Stack buffer overflow in the uMS graphical operator tool of MOOS ui-moos through commit 50b9c6c allows an unauthenticated network attacker to achieve code execution on an operator workstation by injecting excessively long client or variable names into the MOOSDB pub-sub middleware. When the operator subsequently selects a malicious process list entry or pokes an oversized variable through the uMS interface, unchecked sprintf calls in ScopeTabPane.cpp and ScopeGrid.cpp overflow fixed 1024-byte stack buffers, enabling memory corruption and control-flow hijack. The upstream fix (PR #5, commit a6ebc0bc) is confirmed by direct patch diff evidence replacing all three vulnerable sprintf calls with snprintf; no public exploit code or KEV listing has been identified at time of analysis.
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.
Heap corruption in MOOS essential-moos through 10.0.1 allows unauthenticated remote attackers to crash the pMOOSBridge process by sending a single crafted UDP datagram containing a negative declared packet length. The root cause is a signed-to-unsigned type confusion in CMOOSUDPLink::ReadPktFromArray(): a negative nRqd value passes a signed bounds check unchanged, then is silently cast to a near-SIZE_MAX size_t when passed to memcpy, writing far beyond the destination heap buffer. No public exploit has been identified at time of analysis, but the attack primitive requires only network access to the UDP listen port and a small crafted payload; the upstream fix is available as a GitHub patch commit.
Unauthorized runtime route reconfiguration in MOOS essential-moos pShare through 10.0.1 lets any client of the MOOS database issue PSHARE_CMD messages to open new listeners and redirect or duplicate inter-process bus traffic. Because pre-patch builds unconditionally subscribed to PSHARE_CMD, a remote unauthenticated attacker able to publish to the MOOSDB could reroute or mirror sensor/control traffic to attacker-controlled destinations without any credentials. The vendor patch (PR #20) is available and a source-level fix is confirmed, but no public exploit or active exploitation is identified at time of analysis.
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 UDP packet injection in MOOS essential-moos pMOOSBridge through version 10.0.1 allows any network-reachable attacker to inject arbitrary variables into the local MOOS publish-subscribe community by sending crafted UDP datagrams to the configured UDPListen port, with full control over spoofed source and community identifiers. The root cause is the absence of any source-address validation in the ListenLoop: the bridge historically accepted datagrams from any sender, trusting the identity claims embedded in the payload. No public exploit has been identified at time of analysis, and a fix is available via upstream PR/commit, though a tagged release version has not been independently confirmed.
Unauthenticated UDP datagram injection in essential-moos pShare through 10.0.1 allows any network-reachable attacker to send crafted UDP packets that pShare republishes verbatim to the local MOOS community under an attacker-chosen identity, or to crash the pShare bridge process with malformed payloads. The root flaw is that pShare's Listener class used raw socket reads without capturing the sender's address, performing no source validation before deserializing and forwarding messages as authoritative MOOS community traffic. A fix is available in upstream commit 53729b6 and PR #18, which adds allowlist-based source filtering and wraps deserialization in exception handling; no public exploit code has been identified and the CVE is not in CISA KEV.
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.
Remote code execution in MOOS essential-moos pAntler through 10.0.1 lets unauthenticated attackers run arbitrary programs on a robot/vehicle host by publishing a crafted MISSION_FILE variable to the MOOSDB. pAntler's headless remote-control path parses the mission file's Run entries and launches them via execvp() with no check on who published the message, so anyone able to write to the MOOSDB can spawn processes. Reported by VulnCheck with an upstream fix (PR #17); no public exploit identified at time of analysis and it is not 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.