What is GHSA-JV2H-4P9V-WF5W?

GHSA-JV2H-4P9V-WF5W is a high-severity code injection vulnerability in ouroboros-ai (pip), affecting versions <= 0.42.0. It is fixed in 0.42.1. Untrusted input is evaluated as executable code within the application's runtime environment.

Which versions of ouroboros-ai are affected by GHSA-JV2H-4P9V-WF5W?

ouroboros-ai (pip) versions <= 0.42.0 is affected.

Is there a fix for GHSA-JV2H-4P9V-WF5W?

Yes. GHSA-JV2H-4P9V-WF5W is fixed in 0.42.1. Upgrade to this version or later.

Is GHSA-JV2H-4P9V-WF5W exploitable, and should I be worried?

Whether GHSA-JV2H-4P9V-WF5W 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.

What actually determines whether GHSA-JV2H-4P9V-WF5W 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 GHSA-JV2H-4P9V-WF5W?

Upgrade ouroboros-ai to 0.42.1 or later.

GHSA-JV2H-4P9V-WF5W in ouroboros-ai

Q: Which versions of ouroboros-ai are affected by GHSA-JV2H-4P9V-WF5W?

ouroboros-ai (pip) versions <= 0.42.0 is affected.

Q: Is there a fix for GHSA-JV2H-4P9V-WF5W?

Yes. GHSA-JV2H-4P9V-WF5W is fixed in 0.42.1. Upgrade to this version or later.

Q: Is GHSA-JV2H-4P9V-WF5W exploitable, and should I be worried?

Whether GHSA-JV2H-4P9V-WF5W 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.

Q: What actually determines whether GHSA-JV2H-4P9V-WF5W 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.

Q: How do I fix GHSA-JV2H-4P9V-WF5W?

Upgrade ouroboros-ai to 0.42.1 or later.

Summary

ouroboros-ai: Incomplete fix of CVE-2026-47211: untrusted project .env can still reach RCE via omitted execution-routing keys

Workarounds

Do not run Ouroboros from an untrusted/cloned repository directory; remove any project-directory .env and ./.ouroboros/mcp_servers.yaml before running.

Credit

Reported privately via coordinated disclosure by matte1782 and hackkim (https://github.com/hackkim).

Impact

The CVE-2026-47211 fix (0.39.0) added _UNTRUSTED_ENV_DENYLIST to stop an untrusted project-directory .env from redirecting execution. The denylist was incomplete, several execution-routing keys of the same RCE class were omitted, so a malicious cloned repo can still reach arbitrary command execution by shipping a .env (auto-loaded at import, no review step):

Backend config-home roots CODEX_HOME, OPENCODE_CONFIG, OPENCODE_CONFIG_DIR, XDG_CONFIG_HOME: a spawned vendor CLI resolves its config from these. CODEX_HOME=./.evil + committed ./.evil/config.toml redirects the nested Codex agent to attacker config, mcp_servers.<name>.command/args (RCE) and approval_policy="never" / sandbox_mode="danger-full-access" (silent removal of the human approval gate). (reported by matte1782)
MCP bridge / plugin execution roster OUROBOROS_MCP_CONFIG (the YAML's server command/args are spawned via stdio_client, RCE), OUROBOROS_PLUGIN_LOCKFILE, OUROBOROS_PLUGIN_TRUST_ROOT (redirect the installed-plugin roster / trust root so ooo <name> dispatches into attacker code). (reported by hackkim)
SSRF guard toggle OUROBOROS_ALLOW_LOCAL_TRANSPORT (re-enables loopback/private MCP transport targets).
Instruction / capability roots OUROBOROS_AGENTS_DIR, COPILOT_CUSTOM_INSTRUCTIONS_DIRS (replace spawned sub-agent role prompts), OUROBOROS_RUNTIME_PROFILE (backend selector), OUROBOROS_TOOL_CAPABILITIES (override YAML can lower a tool's approval_class, weakening the approval gate).

Additionally, the MCP bridge auto-loaded ./.ouroboros/mcp_servers.yaml from the working directory (create_bridge_from_env(cwd=Path.cwd())), so running ooo inside a malicious repo spawned the committed roster's command, RCE with no .env at all. (cwd-branch noted by hackkim)

Untrusted input is evaluated as executable code within the application's runtime environment. Typical impact: arbitrary code execution within the application's privilege context.

Affected versions

ouroboros-ai (<= 0.42.0)

Security releases

ouroboros-ai → 0.42.1 (pip)

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 environment New to Kodem? Get a demo →

Remediation advice

Fixed in 0.42.1. All listed keys were added to _UNTRUSTED_ENV_DENYLIST; the cwd auto-discovery branch was removed (only the explicit OUROBOROS_MCP_CONFIG env var and ~/.ouroboros/mcp_servers.yaml remain, both trusted). The regression suite now derives from the source denylist to prevent future drift.

Frequently Asked Questions

What is GHSA-JV2H-4P9V-WF5W? GHSA-JV2H-4P9V-WF5W is a high-severity code injection vulnerability in ouroboros-ai (pip), affecting versions <= 0.42.0. It is fixed in 0.42.1. Untrusted input is evaluated as executable code within the application's runtime environment.
Which versions of ouroboros-ai are affected by GHSA-JV2H-4P9V-WF5W? ouroboros-ai (pip) versions <= 0.42.0 is affected.
Is there a fix for GHSA-JV2H-4P9V-WF5W? Yes. GHSA-JV2H-4P9V-WF5W is fixed in 0.42.1. Upgrade to this version or later.
Is GHSA-JV2H-4P9V-WF5W exploitable, and should I be worried? Whether GHSA-JV2H-4P9V-WF5W 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 GHSA-JV2H-4P9V-WF5W 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 GHSA-JV2H-4P9V-WF5W? Upgrade ouroboros-ai to 0.42.1 or later.

Other vulnerabilities in ouroboros-ai

CVE-IDSeverityPackage summary

CVE-2026-47211Highouroboros-ai: ouroboros-ai Vulnerable to Remote Code Execution via Untrusted Project-Directory .env