Which versions of Ouroboros are affected by CVE-2026-47211?

The ouroboros-ai Python package (versions before 0.39.0) contains a remote code execution vulnerability that allows attackers to execute arbitrary code on developers' machines when they clone a…. A patch is available.

How to fix or mitigate CVE-2026-47211?

Within 24 hours: Identify all projects and CI/CD systems using ouroboros-ai and notify development teams of the vulnerability. Within 7 days: Update ouroboros-ai to version 0.39.0 or later across all development and production environments and validate functionality. Within 30 days: Conduct a supply-chain security review, implement controls for evaluating untrusted source code (sandboxing, content scanning), and establish baseline scans for known-vulnerable packages.

Ouroboros CVE-2026-47211

HIGH

Untrusted Search Path (CWE-426)

2026-05-29 https://github.com/Q00/ouroboros

GHSA-c4m7-2gwp-vw76

RCE

Lifecycle Timeline

Source Code Evidence Fetched

May 29, 2026 - 21:50 vuln.today

Analysis Generated

May 29, 2026 - 21:50 vuln.today

DescriptionCVE.org

Impact

A Remote Code Execution (RCE) vulnerability was discovered in Ouroboros. If a user clones a malicious repository and runs Ouroboros commands within that directory, it can lead to arbitrary code execution and potential system takeover.

The vulnerability (CWE-426: Untrusted Search Path & CWE-15: External Control of System Setting) stems from Ouroboros loading the .env file from the current working directory. Prior to the patch, execution-affecting environment variables such as OUROBOROS_CLI_PATH, OPENCODE_CLI_PATH, and other backend selectors were accepted directly from this local .env. An attacker could include a malicious script in the repository and point the CLI path variable to it (e.g., OUROBOROS_CLI_PATH=./malicious_script.sh). When the user executes a command like ouroboros init or any command that instantiates the adapter, the malicious script is executed instead of the intended CLI.

Patches

The vulnerability has been patched in version 0.39.0 via PR #1078. The fix establishes a strict trust boundary by applying a denylist to project-local .env loading. It blocks execution-affecting environment variables (such as runtime selectors and CLI path overrides) from being loaded from the project directory. Explicit constructor overrides and trusted user-owned home configurations (~/.ouroboros/.env) remain fully functional.

Users are strongly advised to upgrade to version 0.39.0 or later.

Workarounds

If upgrading is not immediately possible, users must carefully inspect any .env file inside cloned repositories before running Ouroboros commands to ensure it does not contain unexpected OUROBOROS_*_CLI_PATH or OPENCODE_CLI_PATH overrides.

References

GitHub PR: https://github.com/Q00/ouroboros/pull/1078

AnalysisAI

Remote code execution in the ouroboros-ai Python package (versions prior to 0.39.0) allows attackers to execute arbitrary code on a developer's machine when the victim clones a malicious repository and runs any Ouroboros command from that directory. The CLI loads a project-local .env file and previously honored execution-affecting variables such as OUROBOROS_CLI_PATH and OPENCODE_CLI_PATH, letting an attacker redirect adapter execution to a script shipped in the repo. No public exploit identified at time of analysis, but the PR diff illustrates the exact technique and the attack requires only standard developer workflow actions.

Technical ContextAI

Ouroboros is an AI agent CLI (distributed as the ouroboros-ai pip package) that selects backend adapters (Claude Code, OpenCode, Codex, Copilot, Gemini, Goose, Hermes, Kiro) via environment variables and then spawns those backends through subprocess. The root cause maps to CWE-426 (Untrusted Search Path) and CWE-15 (External Control of System Setting): config/loader.py called _load_env_file(Path('.env')) against the current working directory and merged the contents directly into os.environ, with no trust boundary between repository-supplied configuration and user-supplied configuration. Downstream sinks such as claude_code_adapter._resolve_cli_path and opencode_config._configured_opencode_cli_path then passed the attacker-controlled path straight to subprocess.run. The fix in PR #1078 introduces an _UNTRUSTED_ENV_DENYLIST covering CLI-path overrides, runtime/backend selectors, and permission-mode overrides (which would otherwise silently bypass the human approval gate), and re-architects the loader so project .env defaults to trusted=False while ~/.ouroboros/.env is loaded with trusted=True.

RemediationAI

Vendor-released patch: upgrade ouroboros-ai to version 0.39.0 or later (pip install --upgrade ouroboros-ai), which applies the denylist in src/ouroboros/config/loader.py introduced by PR #1078 (https://github.com/Q00/ouroboros/pull/1078, commit 4e70b760b4eb157469b58645339ba831f6513d37). If you cannot upgrade immediately, the vendor advises manually inspecting any .env file inside cloned repositories for OUROBOROS_*_CLI_PATH, OPENCODE_CLI_PATH, OUROBOROS_AGENT_RUNTIME, OUROBOROS_RUNTIME, OUROBOROS_LLM_BACKEND, and *_PERMISSION_MODE keys before running Ouroboros commands - this is reliable but error-prone and will not catch obfuscated entries. As a stronger compensating control, run Ouroboros only from a directory you control (e.g., cd ~ && ouroboros ...) so no attacker-supplied .env is in scope; the trade-off is loss of per-project environment configuration. CI pipelines should additionally pin the package to ≥ 0.39.0 in lockfiles and refuse to execute Ouroboros against PR branches from forks. See the GitHub Advisory at https://github.com/advisories/GHSA-c4m7-2gwp-vw76 for the canonical advisory record.