CrewAI: a silent sandbox fallback turns prompt injection into RCE (VU#221883)

What is this?

CrewAI — a widely used framework for orchestrating multi-agent systems — shipped a chain of four vulnerabilities that let an attacker turn prompt injection into remote code execution on the host. The findings were reported by Yarden Porat of Cyata and published as CERT/CC Vulnerability Note VU#221883 on March 30, 2026 (public on March 26). The note was revised on May 20, 2026, when CrewAI confirmed that all four issues — CVE-2026-2275, CVE-2026-2285, CVE-2026-2286, CVE-2026-2287 — are now fixed in current releases. At original disclosure there was no complete patch; that gap is what makes the May 20 closure the news here.

How it works

The root cause is a silent security downgrade, not an exotic exploit. CrewAI’s Code Interpreter Tool is meant to run agent-generated Python inside a Docker container. When Docker is unreachable — or stops running mid-execution — the tool falls back to a weaker in-process SandboxPython environment instead of failing closed. An attacker who can influence the agent (directly, or indirectly via a poisoned document or web page the agent reads) chains the four flaws:

Vulnerability      Where                         Effect
-----------------  ----------------------------  --------------------------------------
CVE-2026-2275      CodeInterpreterTool fallback  Sandbox escape: arbitrary C calls via
                                                 ctypes when Docker is unreachable
CVE-2026-2287      Runtime Docker check missing  Silent fallback to insecure sandbox -> RCE
CVE-2026-2286      RAG search tools              SSRF: unvalidated runtime URLs reach
                                                 internal / cloud-metadata services
CVE-2026-2285      JSON loader tool              Arbitrary local file read, no path
                                                 validation

CVE-2026-2275 triggers when allow_code_execution=True is set, or when a developer manually adds the Code Interpreter Tool. The other three are configuration and validation gaps. No working payload is reproduced here — the canonical technical reference is the CERT/CC note. The point is structural: a tool advertised as “sandboxed” silently ran code outside the sandbox.

Why it matters

The impact depends on host configuration, and at the high end it is full host compromise. Per CERT/CC, an attacker who reaches a CrewAI agent with the Code Interpreter Tool enabled can achieve sandbox bypass plus RCE/file read when Docker is present, or full RCE when the host runs in configuration or unsafe mode. The SSRF and arbitrary-read primitives enable credential theft — reaching cloud metadata endpoints or reading secrets off disk — which is the usual pivot from one compromised agent to the wider environment.

Two lessons generalize well beyond CrewAI. First, “sandboxed by default, insecure on fallback” is a trap: any isolation layer that degrades quietly when a dependency is missing will eventually run in the degraded mode in production. Second, prompt injection is the delivery mechanism, not the vulnerability — the agent faithfully executes attacker-influenced instructions, and the damage is bounded only by what the tools around it permit. This is the lethal-trifecta pattern (untrusted input + code/tool execution + sensitive reach) realized in a mainstream framework.

Defenses

The clean fix is to upgrade to a current CrewAI release, where the issues are remediated. Per the vendor statement in VU#221883 (May 20, 2026): the Code Interpreter Tool and its insecure SandboxPython fallback have been completely removed (PRs #4791 and #5309), allow_code_execution is deprecated in favor of external sandboxes such as E2B or Daytona, and centralized validate_file_path() and validate_url() (PRs #5310 and #5315) now block path traversal and SSRF to private, internal and cloud-metadata addresses across RagTool and 20+ tools.

If you cannot upgrade immediately:

1. Disable the Code Interpreter Tool wherever it is not strictly required, and do not set allow_code_execution=True unless you have an external, enforced sandbox.
2. Fail closed, never fall back. Treat “Docker unavailable” as a hard stop for code execution, not a reason to drop to an in-process interpreter. Monitor Docker availability and alert on fallback.
3. Treat all agent inputs as untrusted — including documents, tool outputs and retrieved web content — and constrain what tools an agent may call based on the provenance of its inputs.
4. Egress-filter the agent host. Block outbound access to 169.254.169.254 and internal ranges so an SSRF primitive cannot reach cloud metadata or internal services.
5. Audit the escape hatch. The fix ships a CREWAI_TOOLS_ALLOW_UNSAFE_PATHS=true override that disables the new path validation — confirm it is not set in any deployment.

Status

Item	Reference	Date	Notes
Vendor notified	CERT/CC	2026-01-05	Coordinated disclosure begins
Public disclosure	CERT/CC VU#221883	2026-03-26 → 03-30	Reported by Yarden Porat (Cyata)
CVE-2026-2275 (RCE / sandbox escape)	VU#221883	2026-03-30	ctypes escape on SandboxPython fallback
CVE-2026-2287 (RCE)	VU#221883	2026-03-30	Missing runtime Docker check
CVE-2026-2286 (SSRF)	VU#221883	2026-03-30	Unvalidated RAG-tool URLs
CVE-2026-2285 (file read)	VU#221883	2026-03-30	JSON loader path traversal
Full fix confirmed	CERT/CC (revision 3)	2026-05-20	Tool removed; path/URL validators added

The headline is not “an AI framework had bugs” — it is that a tool marketed as a Docker sandbox would silently execute code outside that sandbox when the dependency went away, and that prompt injection was enough to reach it. The fix landed; the design lesson — isolation must fail closed — is the part worth carrying to your own agent stack.