Jun 19, 2026·6 min read·15 visits
Ouroboros AI is vulnerable to arbitrary remote code execution via untrusted environment variables and working directory configurations, allowing attackers to run arbitrary system commands by getting a user to execute Ouroboros inside a cloned repository.
An arbitrary Remote Code Execution (RCE) vulnerability exists in ouroboros-ai due to an incomplete fix for CVE-2026-47211. Ouroboros automatically loads environment configurations from local .env files located in the current working directory (CWD) of cloned repositories. Although a denylist (_UNTRUSTED_ENV_DENYLIST) was introduced in version 0.39.0 to filter out execution-routing environment variables, multiple critical configuration variables were omitted, enabling complete sandbox bypass and arbitrary system command execution.
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.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N| Product | Affected Versions | Fixed Version |
|---|---|---|
ouroboros-ai Q00 | < 0.42.1 | 0.42.1 |
| Attribute | Detail |
|---|---|
| Vulnerability Type | CWE-426: Untrusted Search Path / CWE-15: External Control of System Configuration |
| Affected Component | Environment Staging & MCP Bridge Configuration |
| Attack Vector | Network / File system parsing |
| Exploit Status | Proof of Concept (PoC) available |
| Impact | Remote Code Execution (RCE) |
| CISA KEV Status | Not Listed |
The application resolves path-based configurations relative to the current working directory, which may be controlled by an adversary.
An improper certificate validation vulnerability (CWE-295) in the Rust-based X.509 verification engine of python-cryptography allows wildcard Subject Alternative Names (SANs) to bypass permitted Name Constraints. This enables an attacker to construct certificates that escape the restricted scope of a subordinate Certificate Authority (CA) and successfully authenticate against vulnerable client installations. The vulnerability is tracked as CVE-2026-69248 and GHSA-m2h6-j472-rp4c, with a CVSS v4.0 base score of 6.9.
A high-severity heap-based out-of-bounds (OOB) read vulnerability exists in the Cython-based HTTP response and request parser extension of aiohttp. When processing malformed HTTP traffic, the parser fails to properly handle raw C pointers returned by the underlying llhttp library during error-message construction. This triggers an uncontrolled strlen() call on non-null-terminated network buffers, which can result in a Denial of Service (DoS) via worker process crash or the exposure of adjacent heap memory inside exception messages.
CVE-2026-69192 is a critical parser differential vulnerability in the 'ip-address' JavaScript library (versions <= 10.3.0). The library parses IPv4 octets containing leading zeros as base-10 (decimal), whereas standard system resolvers and web environments parse them as base-8 (octal). This discrepancy allows remote attackers to bypass SSRF guards and route malicious requests to internal RFC 1918 networks.
A high-severity security vulnerability has been identified within the Angular compiler's internationalization (i18n) metadata collection and translation pipeline. Angular implements strict defenses against client-side execution injection by validating standard attribute and property bindings. However, when parsing elements containing both i18n translation attributes and inline event-handler elements (such as `i18n-onerror`), the compiler failed to assert the safety of the target attribute. Consequently, compromised or untrusted localization translation source files can supply arbitrary JavaScript payloads that replace static event-handler bindings. This arbitrary code is compiled directly into the localized build bundle and executed dynamically by the web browser, bypassing runtime sanitization, security checks, and standard binding constraints.
A directory traversal and arbitrary file read vulnerability exists in PostCSS due to an incomplete fix of CVE-2026-45623. When parsing a CSS file containing a sourceMappingURL comment with the 'from' parameter unset, path traversal and absolute path validations are bypassed, enabling attackers to read arbitrary local .map files.
CVE-2026-69152 is a high-severity Denial of Service (DoS) vulnerability in brace-expansion that allows remote, unauthenticated attackers to cause a process crash or infinite thread-blocking condition. The vulnerability stems from a complete mitigation bypass of the security checks implemented for CVE-2026-14257.