CrewAI, one of the most widely adopted multi-agent frameworks of the past two years, was hit by a coordinated disclosure of four vulnerabilities in early 2026 from researcher Yarden Porat at Cyata, tracked under CERT/CC VU#221883. The four — CVE-2026-2275, CVE-2026-2287, CVE-2026-2285, and an unassigned SSRF in RAG search tools — chain through prompt injection to give an attacker sandbox escape, remote code execution on the host, arbitrary local file read, and SSRF reachable to cloud metadata endpoints. The common thread is a design pattern that several agent frameworks share: a code-execution tool that prefers Docker isolation but silently falls back to a less safe in-process mode when Docker is unavailable. CrewAI's CEO confirmed the bugs and the mitigation roadmap on March 18, 2026. As of the disclosure, no complete patch was available; the recommended path was configuration change plus tool restriction.
What does each CVE actually do?
CVE-2026-2275 is in the Code Interpreter tool's fallback path. When the tool cannot reach Docker, it falls back to a SandboxPython implementation that permits arbitrary C function calls through ctypes. If the agent configuration sets the flag that enables code execution, or if a developer manually adds the Code Interpreter tool to an agent, an attacker who can influence the agent's prompt can trigger arbitrary code execution on the host. CVE-2026-2287 is the structural cause: CrewAI does not continuously verify Docker availability during execution, so a worker that started with Docker healthy but lost the connection will silently degrade to the unsafe sandbox. CVE-2026-2285 is in the JSON loader tool, which accepts file paths without validation and lets the agent read any file the worker process can read. The SSRF, fourth in the chain, is in the RAG search tools — URL validation is insufficient, so the agent can be tricked into fetching internal services or cloud metadata endpoints. Cyata's write-up walks through the chain end-to-end, including the indirect prompt injection that turns a retrieved document into the trigger.
Why is the Docker-fallback pattern so dangerous?
Because it makes the security posture invisible to operators. A team deploying CrewAI in a Kubernetes pod that does not have Docker socket access believes they are running in Docker mode because that is what the configuration says. When the Docker connection fails or is never established, the framework prints a log line and continues — in the less safe sandbox — without surfacing the change as a security event. The fail-open behaviour means that the very environments most likely to lack Docker (Lambda, Cloud Run, Kubernetes without privileged sidecars) are the environments running in the weakest sandbox while their dashboards say "secure." LangChain's langchain-experimental had a structurally similar issue in 2024 (PALChain falling back to local eval), and the lesson — fail closed, surface degraded posture as a high-severity alert — has not propagated through the framework ecosystem.
How does prompt injection complete the chain?
The vulnerabilities are exploitable in the same way every agent framework vulnerability is: by influencing the text the agent reads. The shape of the attack is: an attacker plants a document in a corpus the RAG tool searches, or a comment in a GitHub issue the agent triages, or a customer-support ticket the agent processes. The document contains instructions to call the Code Interpreter tool with a payload that uses ctypes.CDLL to load libc.so.6 and invoke system. The agent, having been told this is part of the task, calls the tool. The tool, in fallback mode, executes the payload. The result is code execution under the worker's identity, with whatever cloud credentials the worker has on its instance profile. The SSRF chain expands the same pattern: instead of execution, the document tells the agent to fetch http://169.254.169.254/latest/meta-data/iam/security-credentials/ through the RAG tool, which obliges.
What is the realistic mitigation while waiting for a complete patch?
The CrewAI team's published guidance is to remove or restrict the Code Interpreter tool, disable the code-execution flag unless strictly necessary, limit agent exposure to untrusted input, and apply input sanitization. In practice, the highest-leverage mitigation is to refuse Docker fallback at startup: configure the worker to exit if Docker is not reachable, and put a health probe in front of the worker that confirms Docker mode is active. The snippet below sketches an agent configuration plus a startup gate that fails closed.
# crewai-hardened.yaml — fail-closed configuration
agent:
name: support_triage
tools:
- file_loader_json:
allow_paths:
- "/data/customer_uploads/*.json"
deny_paths:
- "/etc/*"
- "/proc/*"
- "/root/*"
- "/home/*"
- "/var/log/*"
- rag_search:
url_allowlist:
- "https://docs.example.com/*"
- "https://kb.example.com/*"
block_private_networks: true # 10/8, 172.16/12, 192.168/16, 169.254/16
block_cloud_metadata: true # 169.254.169.254, fd00:ec2::254
code_interpreter:
enabled: false # default off
if_enabled:
require_docker: true # exit if Docker unreachable
fallback_to_inprocess: false # explicit refusal
docker_image: "registry.example.com/crewai-sandbox:pinned-sha256"
seccomp_profile: "strict"
network: "none"
startup_gate:
on_docker_unavailable: exit_nonzero # do not silently degrade
on_seccomp_unavailable: exit_nonzero
emit_signal: "crewai.posture.healthy"
What does this mean for the broader multi-agent ecosystem?
It means defenders should treat every multi-agent framework as having the same class of issue until proven otherwise. AutoGen, CrewAI, Letta, LangGraph, and Mastra all expose code-execution-class tools, all support tool configuration that can be silently weaker than the documented default, and all process untrusted text. The Microsoft Open Source Blog announcement of the Agent Governance Toolkit on April 2, 2026 framed this as a runtime-security gap that the ecosystem needs to close collectively, and OWASP's Agentic Security Initiative has been adding entries to its Top 10 to match. The realistic stance for an enterprise is: assume agent frameworks will keep shipping these bugs through 2026, deploy a sandbox you control around them rather than trusting the framework's own sandbox, and instrument egress so that successful exploitation produces detectable signals.
What should an enterprise CrewAI deployment do this week?
Three actions. First, audit every CrewAI worker for whether code execution is enabled and whether Docker is reliably available at the worker's runtime. Any deployment that runs in environments without Docker — most serverless, most lightweight Kubernetes — and has code execution enabled should be reconfigured to fail closed. Second, remove the JSON loader and the unrestricted RAG tools from any agent that processes untrusted text, replacing them with scoped variants that enforce path and URL allowlists. Third, instrument the worker's egress for connections to 169.254.169.254 and to internal RFC1918 ranges; a hit there is a probable SSRF exploit in progress. None of these wait for a patch.
How Safeguard Helps
Safeguard's agent inventory parses CrewAI worker configurations, flags every deployment with code execution enabled, and runs a runtime probe that confirms whether Docker fallback is active versus refused. Griffin AI cross-references each deployment against the four 2026 CrewAI CVEs and produces a per-worker remediation plan — disable the tool, scope the paths, enforce Docker availability, exit on degraded posture. Policy gates block CrewAI deployments that do not pass the fail-closed configuration check, and egress monitors surface SSRF candidates as high-severity findings the moment a worker reaches for 169.254.169.254 or any other cloud metadata endpoint. The CrewAI patches will land eventually; Safeguard makes the interim configuration safe enough to keep shipping.