OpenC3 COSMOS: Authenticated RCE via writable config overlay (CVE-2026-77602, CVSS 9.9)

What happened

A GitHub Security Advisory (GHSA-jjq7-m736-w977) discloses CVE-2026-77602, a critical (CVSS 9.9) authenticated remote code execution vulnerability in OpenC3 COSMOS, an open-source command-and-control/telemetry platform used in satellite and embedded systems operations. According to the report, COSMOS resolves configuration from a user-writable overlay directory (targets_modified/) before the read-only, plugin-installed targets/ tree — and the config subsystem executes code from those files rather than treating them as inert data.

The advisory identifies three distinct routes to code execution, all reachable by an authenticated non-admin user (in the open-source edition, the report states that the authorize check only validates the token and does not enforce the permission string):

• Table definitions — rendered as ERB and with GENERIC_READ/WRITE_CONVERSION blocks evaluated as Ruby/Python code, triggered via table generate/report/load actions.
• Command/telemetry definitions — overlaid files processed by decom and multi microservices, executing on next service restart.
• Script Runner suites — a procedure file placed in the overlay is required by suite analysis, reachable at a low, read-oriented permission tier.

The report includes a working proof-of-concept demonstrating the ERB-based chain end-to-end over HTTP against a booted COSMOS stack, plus an alternate PoC using the GENERIC conversion sink.

Why it matters

Per the advisory, successful exploitation yields code execution as the openc3 user inside the cmd-tlm-api container and per-target decom microservices — processes that hold Redis and object-storage credentials and sit on the internal service network. That gives an attacker authority over configuration, telemetry, and command data across scopes. The advisory notes that a default single-host install binds the API to 127.0.0.1, limiting exposure to the host itself, but any multi-user deployment that exposes the web port is reachable by any authenticated account — the permission tiers required to write and trigger the payload (system_set, system, script_view) sit below the admin/script-run tiers COSMOS otherwise reserves for code-execution-adjacent actions.

Organizations running COSMOS for satellite ground-station or embedded C2/telemetry operations — an environment where COSMOS is commonly deployed — should treat this as high priority given the CVSS 9.9 rating and public PoC.

What defenders should watch for now

• Inventory any COSMOS deployments and check exposure — is the API/Traefik endpoint reachable beyond localhost, and are non-admin accounts able to reach it?
• Review recent activity on storage-upload and screen-save endpoints for writes into targets_modified/ paths that don't correspond to expected plugin/config workflows.
• Watch for unexpected child-process execution, outbound connections, or file writes originating from the cmd-tlm-api container or per-target decom/script-runner microservices.
• Audit which user accounts hold system_set, system, or script_view permissions, since the advisory describes these as sufficient to reach the vulnerable paths.
• Until a patched release is confirmed and applied, restrict network access to the COSMOS API to trusted hosts/VPN only, and review the suggested mitigations in the advisory (disabling ERB rendering on the overlay, restricting who can write to targets_modified/, gating suite analysis behind the script_run tier).

Developing intel

This is a same-day advisory publication and we have not independently reproduced the PoC. Details on patched versions and vendor remediation timeline should be confirmed directly from the source. Full technical detail, including the proof-of-concept and suggested fixes, is available in the original GitHub Security Advisory: GHSA-jjq7-m736-w977.