How severe is GHSA-jv2h-4p9v-wf5w?

No CVSS score has been assigned to GHSA-jv2h-4p9v-wf5w yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-jv2h-4p9v-wf5w?

GHSA-jv2h-4p9v-wf5w affects the following packages: ouroboros-ai (PyPI). Ecosystems affected: PyPI.

How do I fix GHSA-jv2h-4p9v-wf5w?

Update ouroboros-ai to 0.42.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jv2h-4p9v-wf5w is resolved across your whole dependency graph.

How do I detect GHSA-jv2h-4p9v-wf5w in my PyPI dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ouroboros-ai. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-jv2h-4p9v-wf5w if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-jv2h-4p9v-wf5w?

O3 pinpoints whether GHSA-jv2h-4p9v-wf5w is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-jv2h-4p9v-wf5w actively exploited in the wild?

No public exploit code has been indexed for GHSA-jv2h-4p9v-wf5w yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-jv2h-4p9v-wf5w published, and has it been updated?

GHSA-jv2h-4p9v-wf5w was published on June 19, 2026 and was last updated on June 19, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐍 PyPI

GHSA-jv2h-4p9v-wf5w

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

Published

Jun 19, 2026

Updated

Jun 19, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

🐍ouroboros-ai

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

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)

Patches

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.

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).

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐍PyPI	`ouroboros-ai`	all versions	0.42.1

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ouroboros-ai. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update ouroboros-ai to 0.42.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jv2h-4p9v-wf5w is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-jv2h-4p9v-wf5w is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-jv2h-4p9v-wf5w. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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` redir

O3 Security · Impact-Aware SCA

Is GHSA-jv2h-4p9v-wf5w in your dependencies?

O3 detects GHSA-jv2h-4p9v-wf5w across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works

GHSA-jv2h-4p9v-wf5w

Blast Radius

Description

Impact

Patches

Workarounds

Credit

Affected Packages

Detection & mitigation playbook

Detect

Fix

Workarounds

How O3 protects you

Frequently Asked Questions

Is GHSA-jv2h-4p9v-wf5w in your dependencies?