GHSA-JV2H-4P9V-WF5W: Arbitrary Remote Code Execution via Incomplete Environment Denylist in Ouroboros AI

The affected component is the environment loader and execution configuration parser of ouroboros-ai. This component automatically processes and loads local environment configuration parameters from files within the current working directory. This exposure is particularly critical during command-line execution when parsing code repositories.

The system configuration exposes a critical attack surface because the tool runs within user workspaces. When a user runs commands like ooo within a folder, the software auto-discovers and configures its environmental parameters relative to that localized directory. This trust model allows external repository objects to direct administrative behaviors.

The weakness belongs to CWE-426 (Untrusted Search Path) combined with CWE-15 (External Control of System or Configuration Setting). The vulnerability enables unauthenticated remote code execution. This bypass variant is possible due to incomplete boundary controls deployed in preceding hotfixes.

The architecture of ouroboros-ai automates environment staging by merging configuration variables from localized .env resource files in the current working directory. In version 0.39.0, an initial hotfix implemented a blocklist called _UNTRUSTED_ENV_DENYLIST to exclude explicit CLI execution paths. This initial filter blocked variables such as OUROBOROS_CLI_PATH to prevent immediate execution redirection.

However, this blocklist was structurally incomplete, leaving several downstream execution-controlling environment variables exposed to modification. Specifically, variables managing downstream configuration directories (CODEX_HOME, OPENCODE_CONFIG, OPENCODE_CONFIG_DIR, XDG_CONFIG_HOME) were not filtered. When Ouroboros starts, it spawns downstream processes that locate their configurations relative to these environment values.

Additionally, secondary execution-altering mechanisms, including OUROBOROS_MCP_CONFIG and OUROBOROS_PLUGIN_LOCKFILE, were left exposed. If these are redirected to directories managed by an attacker, arbitrary plugin execution blocks can be initiated during routine tasks. This omission invalidates the isolation goals of the trust boundary, enabling command hijacking without modifying primary CLI paths.

Furthermore, the Model Context Protocol (MCP) bridge featured a secondary zero-configuration vulnerability. If a directory named .ouroboros containing mcp_servers.yaml existed within the current working directory, the system performed automated discovery by parsing configuration definitions. This meant that simply executing the core program within an untrusted repository initiated a malicious execution bridge, even in the complete absence of a .env file.

In version 0.39.0, the system defined _UNTRUSTED_ENV_DENYLIST in src/ouroboros/config/loader.py with an incomplete scope, omitting secondary path controls:

# Vulnerable implementation in 0.39.0
_UNTRUSTED_ENV_DENYLIST = frozenset(
    {
        "OUROBOROS_CLI_PATH",
        "OUROBOROS_CODEX_CLI_PATH",
        "OUROBOROS_COPILOT_CLI_PATH",
        "OUROBOROS_KIRO_CLI_PATH",
        "OUROBOROS_OPENCODE_CLI_PATH",
        "OUROBOROS_HERMES_CLI_PATH",
        "OUROBOROS_GOOSE_CLI_PATH",
        "OUROBOROS_GEMINI_CLI_PATH",
        "OPENCODE_CLI_PATH",
        "OUROBOROS_AGENT_RUNTIME",
        "OUROBOROS_RUNTIME",
        "OUROBOROS_LLM_BACKEND",
        "OUROBOROS_AGENT_PERMISSION_MODE",
        "OUROBOROS_LLM_PERMISSION_MODE",
        "OUROBOROS_OPENCODE_PERMISSION_MODE",
    }
)

The loader applied this list inside the environment parser. However, because keys like CODEX_HOME and OUROBOROS_MCP_CONFIG were missing, they bypassed the filter block and entered the active runtime context.

In version 0.42.1, the blocklist was expanded to cover these omissions, and the current working directory auto-discovery code path in the MCP bridge was removed. The application now requires explicit home-directory configuration or verified environment variables:

# Patched implementation in 0.42.1
_UNTRUSTED_ENV_DENYLIST = frozenset(
    {
        # Original Executable Overrides
        "OUROBOROS_CLI_PATH",
        "OUROBOROS_CODEX_CLI_PATH",
        # ...
        # Backend config-home roots
        "CODEX_HOME",
        "OPENCODE_CONFIG",
        "OPENCODE_CONFIG_DIR",
        "XDG_CONFIG_HOME",
        # MCP bridge / plugin execution roster
        "OUROBOROS_MCP_CONFIG",
        "OUROBOROS_PLUGIN_LOCKFILE",
        "OUROBOROS_PLUGIN_TRUST_ROOT",
        # SSRF guard toggle
        "OUROBOROS_ALLOW_LOCAL_TRANSPORT",
        # Instruction / capability roots
        "OUROBOROS_AGENTS_DIR",
        "COPILOT_CUSTOM_INSTRUCTIONS_DIRS",
        "OUROBOROS_RUNTIME_PROFILE",
        "OUROBOROS_TOOL_CAPABILITIES",
    }
)

> [!NOTE] > The auto-discovery function was also corrected by removing cwd=Path.cwd() inside create_bridge_from_env. The application now resolves configuration paths exclusively from trusted system levels.

An attack relies on a user performing standard terminal interactions within an untrusted repository path. The adversary crafts a multi-layered folder structure containing a custom .env pointing downstream paths toward a controlled target. In addition, they supply a simulated local configuration structure in a hidden directory.

For example, configuring CODEX_HOME redirects the downstream agent execution cycle. When the core application calls the CLI interface, it inherits the configured CODEX_HOME variable, resolving files inside the malicious repository directory. The application subsequently initializes settings defined in .evil/config.toml rather than system-wide structures.

This malicious configuration file instructs the system to register custom servers with execution arguments. When execution flows reach these hooks, the tool initiates the command line arguments without prompting the operator. This execution bypasses user confirmation screens, initiating commands directly through Python's execution environment.

The impact of this vulnerability is complete compromise of the execution context hosting the ouroboros-ai package. Since many deployments are evaluated by local developers, software engineers, or automation routines, commands execute with the security permissions of the logged-in host user. An attacker can execute arbitrary commands, download secondary payloads, and persist on the client system.

Furthermore, because Ouroboros handles security credentials, including API keys, tokens, and local development configurations, the compromise enables complete data extraction of all credentials accessible via environment storage. Compromise of these development hosts can quickly facilitate lateral movement across enterprise networks.

The CVSS v4.0 score of 8.8 (High/Critical) reflects the seriousness of the issue. While user interaction is a prerequisite, it requires only standard activities, such as traversing into a cloned folder and executing typical commands. This makes exploitation a low-complexity task with high likelihood.

The only comprehensive remediation is to upgrade ouroboros-ai to version 0.42.1 or higher. This update restricts automatic environment loading, expands the blocklist, and removes the current working directory auto-discovery code path from the MCP bridge.

If immediate updates are not feasible, you must enforce execution sandboxing. Never run Ouroboros utilities inside directories cloned from untrusted origins or shared file systems. Developers should clean environment structures and manually verify that no localized .env files or .ouroboros directories reside within their workspaces.

Organizations can also implement system-level security controls to block exploitation. Restricting execution parameters and establishing monitoring rules to detect unexpected process trees spawned from interpreter runtimes (such as Python spawning shell processes inside user folders) can help mitigate risks.