One prompt injection can take over a server: four CrewAI CVEs expose the agent security gap

Security researchers disclosed four severe vulnerabilities in the popular multi-agent AI framework CrewAI. The individual issues are dangerous on their own. The more important finding is the chain: an attacker can begin with prompt injection and end with control over the host system when code execution, network tools, and file loaders sit behind the same agent.

The four identifiers are CVE-2026-2275, CVE-2026-2285, CVE-2026-2286, and CVE-2026-2287. Yarden Porat of Cyata reported the issues, and CERT/CC published advisory VU#221883. The Korean source article noted that a complete patch was not yet available in early April. That patch status matters less than the design lesson: once an agent can execute code or fetch data on behalf of a model, prompt injection becomes an infrastructure entry point.

Prompt injection used to be framed as a way to make a model ignore instructions, leak text, or produce a misleading answer. CrewAI shows the harder version. If the model is connected to a code interpreter, a retrieval tool, a JSON loader, and internal network reachability, a malicious instruction can push the agent toward operations that traditional web security teams would classify as RCE, SSRF, or path traversal.

Agent Security in 2026

The CrewAI case is not isolated. Since 2025, AI agent frameworks have accumulated a pattern of high-impact incidents. Langflow disclosed a CVSS 9.8 vulnerability, CVE-2025-3248, and real-world attacks reportedly began within about 20 hours of public disclosure. CISA later added the issue to its Known Exploited Vulnerabilities catalog. Trail of Bits also published research under the title "Prompt injection to RCE in AI agents," describing the mechanism that turns a model instruction into a system-level attack through agent tools.

The pace continued in 2026. ModelScope MS-Agent had a CVSS 9.8 remote-code-execution vulnerability in March. CrewAI had a separate March incident in which GitHub management tokens appeared in error responses, with a CVSS 9.2 severity. LiteLLM faced a supply-chain incident affecting a package with tens of millions of monthly downloads. Langflow returned to CISA KEV with another vulnerability, CVE-2026-33017.

Cisco's "State of AI Security 2026" report compressed the enterprise side of the problem into two numbers cited by the Korean original: many organizations plan agentic AI deployments, but only 29% say they are prepared to secure them; prompt injection appeared in 73% of production AI deployments in 2025. The security-review cycle is moving slower than agent-framework adoption.

The Four CVEs

Each CrewAI vulnerability exposes a different trust boundary. Together, they describe the attack surface that appears when an agent has code, retrieval, URL, and file capabilities.

CVE-2026-2275: No Docker, No Sandbox

This issue affects CrewAI agents with the Code Interpreter Tool enabled. CrewAI is designed to isolate code execution inside Docker containers. When CrewAI cannot connect to Docker, however, it can fall back to a SandboxPython environment. The flaw is that the fallback sandbox does not block ctypes.

ctypes lets Python call C libraries directly. In a sandbox escape, that gives an attacker a way to reach operating-system-level functions from Python code. The architectural mistake is fail-open behavior. If the secure execution environment is unavailable, the safer default is to stop execution. Running anyway in a weaker sandbox turns an availability problem into a host-compromise path.

CVE-2026-2287: Docker Can Disappear Mid-Session

CVE-2026-2287 is closely related. CrewAI does not continuously verify Docker availability during runtime. Docker can be available when the session starts, then stop later. If the system silently downgrades to the weaker fallback environment, the developer may believe the agent is still isolated when it is not.

Security teams often call this a silent security downgrade. It is risky because the operator does not get a clear failure signal. A build failure is visible. A hard process exit is visible. A fallback that quietly keeps processing untrusted instructions is harder to notice and easier to exploit.

CVE-2026-2286: RAG Becomes an SSRF Path

This issue affects CrewAI agents using RAG search tools. The vulnerable tool does not adequately validate URLs supplied at runtime, which enables server-side request forgery. An attacker can use the agent to request internal services or cloud metadata endpoints.

The cloud metadata example is concrete: 169.254.169.254 is used by major cloud platforms for instance metadata. If an agent can reach that address from inside a cloud environment, an attacker may be able to retrieve temporary credentials or service tokens and then move laterally beyond the original application.

CVE-2026-2285: File Reads Without a Boundary

The JSON loader issue is a path traversal flaw. The tool reads file paths without sufficient validation, allowing access to arbitrary files on the server filesystem. The obvious targets are /etc/passwd, environment files, SSH keys, application configuration, database credentials, and API tokens.

This is the file-system leg of the agent risk. A model does not need native file-system access if a tool will read files for it. A retrieval workflow that accepts untrusted paths becomes a credential exfiltration route.

From Prompt Injection to Host Control

The chain begins with a malicious instruction. That instruction may be sent directly to the agent, hidden in a document, embedded in a web page, or placed inside data that a RAG workflow retrieves. Indirect prompt injection is enough when the agent treats external content as instructions rather than data.

The second step is the pivot from model behavior to system behavior. If Docker is missing or stops during the session, the weak Python fallback can expose host execution through ctypes. At that point, the attacker is no longer asking the model to say something wrong. They are asking the system to run something.

The third and fourth steps collect reachability and secrets. SSRF can enumerate internal services or request cloud metadata. Arbitrary file reads can extract environment files, SSH keys, database credentials, and API tokens. Combining code execution with these secrets gives the attacker a path from one agent process to the wider cloud environment.

Simon Willison's "Lethal Trifecta" gives a useful frame: private data access, exposure to untrusted input, and an outbound channel. The CrewAI chain contains all three. The agent reads private data through tools, consumes untrusted prompts or retrieved content, and can send requests outward through network or tool calls.

Immediate Impact for CrewAI Users

CERT/CC recommended immediate mitigations for teams running affected CrewAI configurations. The most direct step is to disable code execution unless it is essential and remove the Code Interpreter tool where it is not needed.

# Risky: code execution opens the tool surface
agent = Agent(
    role="Data analyst",
    allow_code_execution=True,
    tools=[CodeInterpreterTool()]
)

# Safer mitigation: disable code execution when it is not required
agent = Agent(
    role="Data analyst",
    allow_code_execution=False,
    tools=[]
)

If code execution is required, Docker availability should be treated as a hard security dependency. A wrapper should stop agent execution when Docker is unavailable at startup or disappears during runtime. The goal is fail-closed behavior: no isolation, no execution.

Teams should also isolate network access. CrewAI agents should not be able to reach internal services or cloud metadata endpoints unless that access is explicitly required. Firewall rules, egress controls, and metadata endpoint blocks are part of the agent security boundary, not only the infrastructure team's checklist.

File-access tools need the same treatment. JSON loaders and similar utilities should be restricted to whitelisted directories and expected file extensions. User-supplied paths should not be passed directly into file reads. The highest-value files for an attacker are usually ordinary operational files: .env, SSH keys, database settings, service-account JSON, and token caches.

CrewAI maintainers said they were adding ctypes and related modules to BLOCKED_MODULES and evaluating a fail-closed configuration. That is a useful patch direction, but the broader lesson applies to any framework that offers a "safe" fallback. A fallback that weakens isolation should be visible, auditable, and disabled by default in production.

The table is not a league table of bad frameworks. It is a pattern: agent tools often receive more authority than their guardrails deserve. Langflow, CrewAI, ModelScope, and LiteLLM show different failure modes, but the common thread is tool capability without a narrow enough execution boundary.

Community and Industry Signals

Developer reaction focused on the fail-open behavior. The practical objection is simple: if Docker is required for isolation, then losing Docker should stop execution. A fallback path that continues to run untrusted code changes the security contract without the operator's consent.

The CrewAI discussion also reopened a common open-source enterprise question. When security controls are stronger in paid or enterprise editions than in community editions, the public ecosystem may carry more risk even while it supplies adoption, extensions, examples, and bug reports. Some developers argued for a middleware or plugin architecture that would let the community add its own security layers around tools.

Security researchers placed the CrewAI case beside other April 2026 agent-security events, including OpenClaw and Chrome Gemini Live findings. The repeated theme is that prompt injection becomes more severe when the agent can access private data, call tools, and communicate externally.

Palo Alto Networks framed AI agents as a major insider-threat category for 2026. The CrewAI chain explains why that framing is plausible. A compromised agent does not necessarily look like malware to existing infrastructure. It may call normal tools, access normal files, and make normal HTTP requests, while the instruction source is an attacker-controlled prompt.

The Structural Lesson

CrewAI's four CVEs move prompt injection from the model layer to the infrastructure layer. Once an agent can execute code, read files, browse networks, or call APIs, the prompt boundary is no longer the only boundary. The tool boundary becomes the real security control.

Fail-closed execution should become a default design pattern for agent frameworks. If Docker, a sandbox, an allowlist, a policy engine, or an identity check is unavailable, the agent should stop. A production system should not choose convenience over isolation just because a dependency is missing.

Framework selection will also change. Teams have historically picked agent frameworks for features, ergonomics, documentation, and community size. After Langflow, CrewAI, ModelScope, and LiteLLM incidents, security audit history, patch velocity, sandbox architecture, token handling, and least-privilege defaults should become first-class evaluation criteria.

Defense in depth is the practical endpoint. Input filtering alone will not remove prompt injection. Production agents need least-privilege identities, restricted outbound network paths, isolated execution environments, explicit file allowlists, tool-call logging, and a human-readable failure mode when a security dependency disappears.

The CrewAI vulnerabilities are not only about one framework. They are a low-cost warning for the rest of the agent ecosystem. If AI agents are going to run inside production infrastructure, security cannot remain an add-on after the demo works. It has to be part of the execution model from the first tool call.