Ouroboros Malicious .env CLI Path Hijack Leading to Arbitrary Code Execution

Technical Analysis

The vulnerability arises because Ouroboros loads environment configuration from a .env file in the current working directory without validating its source or scope, and treats variables such as OUROBOROS_CLI_PATH and OPENCODE_CLI_PATH as authoritative paths for invoking backend CLI binaries. An attacker crafts a repository containing a malicious script (e.g., ./malicious_script.sh) and a .env file redirecting the CLI path variable to that script. When a victim clones the repo and runs any Ouroboros command that instantiates the adapter (such as ouroboros init), the tool executes the attacker's script with the user's privileges instead of the legitimate CLI binary. This crosses the trust boundary between 'data the agent operates on' (a cloned repo) and 'configuration that controls the agent's own execution,' enabling full local code execution and potential system takeover, effectively turning the coding agent into a delivery mechanism for arbitrary payloads.

Affected Systems

Ouroboros

Detection Signatures

• Presence of .env files in cloned/untrusted repositories defining OUROBOROS_CLI_PATH, OPENCODE_CLI_PATH, or other *_CLI_PATH backend selector variables
• CLI path environment variables pointing to relative paths within a repo directory (e.g., ./*.sh, ./*.py) rather than trusted system install locations
• Unexpected shell script execution immediately following 'ouroboros init' or adapter instantiation commands
• File system monitoring alerts for execution of scripts located inside newly cloned repository directories triggered by CLI tooling

Remediation Steps

1. 1

   Upgrade Ouroboros

   Update to version 0.39.0 or later, which removes or restricts the ability for local repository .env files to override execution-critical CLI path variables.

2. 2

   Avoid running agent commands in untrusted repos

   Do not run ouroboros commands (init or others that instantiate adapters) inside freshly cloned, unreviewed repositories until code has been vetted.

3. 3

   Isolate execution environment

   Run coding-agent tooling inside containers or sandboxes with restricted filesystem and process execution permissions to limit the blast radius of arbitrary code execution.

4. 4

   Enforce environment variable allowlists

   Configure or patch tooling so execution-affecting environment variables (CLI path selectors) can only be set from trusted global/user configuration, not from project-local .env files.

5. 5

   Audit .env handling in agent tools generally

   Review other agent frameworks/CLIs for similar patterns where local, repo-supplied configuration files can influence binary execution paths.