Cpe:2.3:a:moos-Ivp:essential-Moos:*:*:*:*:*:*:*:* - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/cpes/cpe2.3amoos-ivpessential-moos/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioThu, 03 Sep 2026 23:25:50 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgRemote Code Execution in MOOS essential-moos pAntlerhttps://feed.craftedsignal.io/briefs/2026-09-moos-pantler-rce/Thu, 03 Sep 2026 23:25:50 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-09-moos-pantler-rce/The pAntler component in essential-moos versions 10.0.1 and earlier allows unauthenticated attackers to achieve remote code execution by publishing a crafted MISSION_FILE message to the MOOSDB.The MOOS-IvP open-source project essential-moos suite, specifically the pAntler component through version 10.0.1, contains a critical remote code execution vulnerability. pAntler is designed to manage and launch various MOOS processes defined within a mission file. An unauthenticated attacker capable of communicating with the MOOSDB can publish a specially crafted 'MISSION_FILE' message. The pAntler application reads the contents of this message and parses it for 'Run' entries. Due to a lack of authentication and input validation on these entries, pAntler passes the user-supplied strings directly to the execvp() system call, resulting in the execution of arbitrary programs with the privileges of the pAntler process. This vulnerability is significant for autonomous systems and research platforms that utilize the MOOS-IvP architecture, as it allows for full command execution on the host machine.

Attack Chain

  1. Attacker establishes network connectivity to the target MOOSDB port.
  2. Attacker crafts a malicious MISSION_FILE message containing arbitrary commands within 'Run' entries.
  3. Attacker publishes the crafted message to the MOOSDB via the MOOS protocol.
  4. The pAntler component receives the malicious MISSION_FILE message from the MOOSDB.
  5. pAntler parses the 'Run' entries within the message without validating the input.
  6. pAntler calls the execvp() system call, passing the malicious entries.
  7. The operating system executes the attacker-defined program on the host.

Impact

Successful exploitation allows unauthenticated remote attackers to execute arbitrary programs on systems running affected versions of essential-moos. This can lead to full system compromise, loss of control over autonomous mission software, and data exfiltration. The vulnerability affects research and robotics environments utilizing the MOOS-IvP middleware.

Recommendation

  1. Upgrade the essential-moos software to a version beyond 10.0.1 immediately, if available, or isolate MOOSDB instances from untrusted network segments.
  2. Implement network access controls (NAC) to restrict communication with the MOOSDB port to authorized and authenticated mission components only.
  3. Audit environments for the use of pAntler and ensure process execution policies are configured to minimize the impact of unauthorized sub-process spawning.
]]>highadvisoryremote-code-executionvulnerabilitycvenetwork-securityAuthentication Bypass and Message Injection in MOOS pSharehttps://feed.craftedsignal.io/briefs/2026-09-moos-pshare-auth-bypass/Thu, 03 Sep 2026 23:24:40 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-09-moos-pshare-auth-bypass/The pShare component in MOOS essential-moos versions up to 10.0.1 is vulnerable to unauthenticated UDP message injection and denial-of-service.MOOS-IvP essential-moos versions 10.0.1 and earlier contain a critical authentication bypass vulnerability within the pShare component. pShare is designed to share MOOS messages across different MOOS communities. The vulnerability arises because the process accepts UDP datagrams from any source without performing authentication or identity verification. An attacker on the local network can craft malicious UDP packets and inject arbitrary messages into the MOOS community while spoofing the identity of a legitimate MOOS process. Additionally, the lack of input validation allows an attacker to send malformed UDP datagrams that cause the pShare process to crash, resulting in a denial-of-service condition for the impacted MOOS community. This vulnerability is significant for environments relying on the integrity of MOOS-based communication in robotic and autonomous system fleets.

Impact

Successful exploitation allows attackers to perform unauthorized message injection, potentially leading to the corruption of operational data or the execution of unauthorized commands within the MOOS community. Denial-of-service attacks against pShare can disrupt communication between critical mission components, rendering autonomous systems inoperable or uncontrollable.

Recommendation

  • Monitor network traffic for unexpected UDP communication directed at the port used by the pShare process.
  • Implement network-level access control lists (ACLs) to restrict access to the pShare UDP port to trusted IP addresses only.
  • Update all instances of MOOS-IvP essential-moos to a version that implements input validation and authentication for incoming UDP datagrams, if available.
  • Audit logs for repeated service restarts or process crashes of the pShare binary, which may indicate attempted exploitation of the denial-of-service vulnerability.
]]>criticaladvisoryvulnerabilityremote-code-executionnetwork-securitycveauthorization-bypassrobotics