Summary
OpenC3 COSMOS contains code-injection paths in which authenticated non-administrator users can place content under targets_modified/ that is later evaluated as Ruby or Python code.
When configuration reloads, table processing, or suite analysis is triggered, the content may execute in internal services with access to application credentials and data.
Affected context
The issue affects OpenC3 COSMOS deployments where authenticated users who are not administrators can create or upload content that reaches modified target configuration or suite procedure paths. Multiple components process this content through configuration parsers, ERB rendering, Ruby or Python evaluation, or Ruby require, potentially executing it below the intended code-execution privilege tier.
Exploit preconditions
- Attack surface: COSMOS storage, screen-save, script-creation, configuration, and suite-analysis workflows
- Required access: An authenticated non-administrator account with permission to create or modify relevant content
- Trigger point: Table processing, command or telemetry reloads, or suite analysis
- Why exploitation is possible: User-controlled files under
targets_modified/can reach processing paths that evaluate or load content as executable Ruby or Python code
Why this happens
The vulnerability results from treating user-influenced configuration and procedure content as executable code. Processing paths such as ConfigParser, PacketConfig, conversion handlers, ERB rendering, and Ruby require cross a trust boundary without adequately restricting the content to declarative configuration.
This behavior maps to CWE-94: Improper Control of Generation of Code ('Code Injection'), because attacker-controlled data can influence code evaluation or loading in services that possess broader privileges and access than the submitting user.
Potential impact
- An attacker may execute arbitrary Ruby or Python code in affected COSMOS services
- Compromised services could expose internal credentials, telemetry, commands, or other application data
- Attackers could alter embedded-system configuration or influence command and telemetry processing
- The compromise could enable lateral movement within the deployment environment
- Malicious content could persist through configuration, script, or storage workflows
General mitigation guidance
Mitigation generally focuses on preserving the boundary between declarative configuration and executable code.
Common defensive patterns include:
- Using data-only parsers and restricted schemas for tables, commands, telemetry, and other configuration
- Removing or tightly constraining ERB, dynamic evaluation, and unrestricted module loading for user-controlled content
- Treating uploaded files and generated scripts as untrusted, with explicit type, size, and content validation
- Limiting which authenticated roles can write to
targets_modified/or trigger reload and analysis workflows - Running processing services with least privilege and narrowly scoped access to credentials, files, and internal networks
- Isolating configuration-processing and script-running components with separate identities and restricted capabilities
- Applying immutable or controlled storage policies to runtime configuration and procedure locations
How teams detect issues like this
Detection programs can look for:
- Static-analysis findings involving Ruby
require, dynamic evaluation, ERB rendering, Python evaluation, and conversion handlers applied to user-controlled data - Code-review signals showing uploaded or generated files reaching configuration reload, packet conversion, or suite analysis paths
- Access-control policies that allow non-administrative users to write executable or executable-like content
- Runtime monitoring for unexpected file creation under
targets_modified/, unusual reload activity, and child-process or interpreter launches - Audit events linking storage uploads or script creation to command, telemetry, or suite-processing operations
- Automated security review tools that flag code and data trust-boundary violations
