Reviewing CrewAI deployments — Crews, Flows, and the security the framework doesn't provide

For review purposes, the practical split is Crews versus Flows — not a technical detail, but the single biggest factor in how reviewable a given CrewAI deployment actually is.

This is worth stating plainly because it changes what a review can assume. For a framework that ships its own auth and logging, a review checks whether those controls are configured correctly. For CrewAI's open-source core, a review has to check whether the application built around it added those controls at all — there is no default to fall back on.

Four vulnerabilities disclosed in 2026 — identified by security researcher Yarden Porat of Cyata — trace back to the same underlying pattern: tools that fall back to a less-isolated execution mode without the application being told, combined with prompt injection steering the agent into using them.

• CVE-2026-2275 and CVE-2026-2287 — sandbox escape / RCE. The Code Interpreter tool is designed to run in a Docker container. If Docker isn't available at runtime, or a code-execution flag is set in the agent configuration, it silently falls back to an in-process Python sandbox that can be escaped via arbitrary C function calls — remote code execution on the host, not the intended container.
• CVE-2026-2285 — arbitrary file read. The JSON loader lacks path validation, allowing access to arbitrary files on the server through a crafted input.
• CVE-2026-2286 — SSRF. CrewAI's RAG search tools don't validate URLs supplied at runtime, allowing requests to internal and cloud-metadata services from outside the intended scope.

All four are reachable through prompt injection — direct or indirect — that manipulates an agent into invoking a tool the way its author never intended, not through direct access to the host. The vendor has patched them; the pattern (a tool with an undocumented fallback to a less-isolated mode) is the thing to check for in any tool an application adds on top of CrewAI's own.

The fix for CVE-2026-2275 and CVE-2026-2287 wasn't a validation check bolted onto the insecure fallback — CrewAI removed the fallback entirely. The Code Interpreter tool's Docker sandbox and its insecure SandboxPython alternative are both gone; current guidance points teams to an external, purpose-built sandbox (E2B or Daytona) instead of anything bundled with the framework. For the file- read and SSRF issues, the fix was structural rather than local: a centralized validate_file_path() and validate_url() are now enforced across the RAG tool and more than twenty other built-in tools, rather than each tool reimplementing its own (and inconsistently remembering to) validation.

Separately, CrewAI added a supply-chain control worth knowing about on its own terms: dependency resolution now defaults to excluding any package published within the last three days, a direct response to the broader pattern of typosquatted or freshly-compromised packages landing in agent tool chains. None of this closes the “no built-in security” gap from the previous section — it closes the specific holes the four CVEs exploited. A review still has to add authentication, audit logging, and access control itself, or verify the Enterprise tier's equivalents are actually turned on.

For any system built on CrewAI, a design-time review should be able to answer:

• Is this deployment on a patched version (post the four CVEs above), and is Docker guaranteed available wherever the Code Interpreter tool runs — with a hard failure, not a silent fallback, if it isn't?
• What auth, audit logging, and access control has the application added, given the open-source core ships with none?
• Is this workload built as a Crew or a Flow — and if a Crew, is there a documented reason the task genuinely can't be bounded to a deterministic Flow instead?
• Do any custom tools (file loaders, RAG search, HTTP clients) validate paths and URLs against an allowlist, rather than accepting whatever the agent supplies?
• If running the Enterprise tier, are the isolated-VPC execution and role-based access controls actually enabled, not just available?

See multi-agent system security review for how the Crew coordination model maps to broader multi-agent review questions, and agent sandboxing and isolation for the general pattern behind the Code Interpreter fallback issue.