ouroboros-ai: Incomplete fix of CVE-2026-47211: untrusted project .env can still reach…
Key facts
- Attack vector
- —
- Privileges required
- —
- User interaction
- —
- Attack complexity
- —
- Impact type
- Code execution
- Confidentiality · integrity · availability
- —
- Fix status
- Fixed
No CVSS vector from any source. Fix status from GitHub. Impact type from CWE-94.
Summary
### 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).
Why it matters now
SSVC decision points
Not available: CISA has not published SSVC decision points for this record.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| — | ouroboros-ai (PyPI) | before 0.42.1 | 0.42.1 | Patch available | GHSA-jv2h-4p9v-wf5w |
- ouroboros-ai (PyPI) Vendor— Affected before 0.42.1 Fixed in 0.42.1 Patch available GHSA-jv2h-4p9v-wf5w
Remediation
- Fix · GHSA-jv2h-4p9v-wf5w ouroboros-ai (PyPI) Fixed in 0.42.1 Advisory →
Timeline
- 2026-10-03 Threatist record created from GHSA-jv2h-4p9v-wf5w
References
Sources
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences