Description

MOOS core-moos through 10.4.0 fails to escape database contents when rendering MOOSDB HTTP pages, allowing attackers to inject malicious scripts. Any MOOS publisher can set variable values containing script payloads that execute in the browser of operators viewing the web interface.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.1",
  "pubDate": "2026-09-03T23:17:25.483Z",
  "pubdate": "2026-09-03T23:17:25.483Z",
  "executiveSummary": "MOOS core-moos versions through 10.4.0 are susceptible to a stored Cross-Site Scripting (XSS) vulnerability within the MOOSDB HTTP management interface.\nThe vulnerability originates from the application's failure to properly sanitize or escape variable data submitted to the database before rendering it in the web interface.\nAny authorized MOOS publisher can inject malicious JavaScript payloads into variable values, which are subsequently stored in the database.\nWhen an operator or administrator views the affected database contents via the MOOSDB HTTP interface, the malicious script is rendered and executed within the context of the user's browser session.\nThis vulnerability allows an attacker to perform unauthorized actions on behalf of the victim, potentially leading to session hijacking, credential theft, or further client-side exploitation.\nThe risk is critical for environments where multiple publishers have access to the MOOS community, as the exploit requires no specialized privileges beyond the ability to publish a variable to the MOOSDB.",
  "technicalDetails": "The vulnerability resides in the MOOSDB HTTP server component, which is responsible for rendering the state of the MOOS community for diagnostic and monitoring purposes. The root cause is an improper neutralization of input during web page generation, specifically the failure to apply context-aware encoding or output escaping to variable data retrieved from the MOOSDB state.\nIn the MOOS architecture, nodes communicate by publishing variables to the MOOSDB. Because the MOOSDB HTTP interface dynamically generates HTML representations of these variables to facilitate operator oversight, any string content submitted by a publisher is treated as trusted data.\nAn attacker can exploit this by crafting a MOOS variable value that contains arbitrary HTML/JavaScript tags (e.g., <script>alert(document.cookie)</script>). Once this payload is published to the MOOSDB, it persists as part of the database state. When an operator navigates to the HTTP diagnostic pages, the server iterates through the database variables and injects the raw, unescaped string directly into the Document Object Model (DOM) of the management interface.\nThe execution flow is as follows: 1) The attacker publishes a crafted variable to the MOOSDB. 2) The MOOSDB stores the malicious payload in its internal memory structure. 3) The target (operator) accesses the MOOSDB HTTP web interface. 4) The HTTP server processes the request and embeds the malicious payload into the HTTP response. 5) The victim's web browser parses the HTML, encounters the attacker-supplied tags, and executes the payload with the victim's session permissions.\nThis vulnerability effectively bypasses traditional server-side authentication controls because the exploit is delivered through the legitimate communication protocol of the MOOS core. Any client with the ability to publish to the MOOS community is capable of triggering this stored XSS, making it a significant risk in multi-user or distributed robotic and autonomous system deployments where publisher authentication may not be strictly enforced or segmented. Post-exploitation, an attacker can capture session cookies, redirect the user to malicious sites, or perform actions within the web interface that the operator is authorized to conduct."
}