Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍 PyPI
Not in CISA KEV

CVE-2026-66065 — ouroboros-ai

CVE-2026-66065 is a CWE-15 vulnerability in ouroboros-ai. A fix is available for ouroboros-ai — see the affected versions and patch details below.

Ouroboros: Untrusted project .env can still reach RCE via omitted execution-routing keys (Incomplete fix of CVE-2026-47211)

Also known asGHSA-jv2h-4p9v-wf5w
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 23, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • A successful exploit gives an attacker total control of the affected component, not partial access.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-66065.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs14th percentile — riskier than 14% of all scored CVEsHighest risk
0.00%0.27%0.53%0.80%0.3%0.2%0.2%Sep 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

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
EcosystemPackageVulnerable rangeFix
🐍PyPIouroboros-aiall versions0.42.1pip install --upgrade 'ouroboros-ai==0.42.1'

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ouroboros-ai, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

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

  3. Workarounds

    Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.

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 CVE-2026-66065 in your dependencies?

Find it across PyPI, including transitive dependencies.

CVE-2026-66065: ouroboros-ai RCE — Fixed in 0.42.1