Loading libc without an import statement

CrewAI is a framework for building multi-agent systems, and its CodeInterpreter tool ran agent-written Python in a Docker container and, when Docker was unavailable, fell back to a blocklist sandbox inside the user's own process. To keep that code from reaching the operating system, the fallback screened what the agent tried to import against a blocklist of module names. The advisory for CVE-2026-37008 describes the flaw in one line: the check operated at the wrong level of abstraction.

A name blocklist can only see the names a program asks for. The Python runtime exposes far more than names, and the route the advisory records to the C library did not rely on an import statement. It went through `ctypes.CDLL(None)` — a name that had to be imported, but one the blocklist did not list — and that call returns a handle to the already-loaded process image, from which it could reach the libc functions the sandbox was meant to keep out. A blocklist keyed on import names has nothing to match that call against.

The project's own fix commit describes a second route that recovers the blocked function itself. Using `object.__subclasses__()` — a walkthrough the project demonstrated in issue #4516 — an agent can traverse the classes the interpreter has already loaded, find ones that hold references to builtins, and pull `__import__` back out of them. Once the agent has `__import__` in hand, the name blocklist no longer constrains it: the check lived inside a replacement `__import__` that screened each module name as it was requested; the original `__import__`, once recovered from the object graph, executed without it.

Both routes exploit the same property. In CPython, a running process is a graph of live objects and loaded libraries, and any code already executing inside that process can reach the rest of it. Screening module names cannot close a boundary the object graph holds open.

CVE-2026-37008 carries a CVSS 3.1 score of 8.1 with the attack vector marked Local, meaning the code has to be running inside the process already before the escape applies. The affected range is every CrewAI revision before commit fb2323b, which the project landed on 15 March 2026. The framework removed the CodeInterpreter tool entirely in version 1.14.0 in April 2026; the tool, not just the check, is gone from current releases.

The CVE sits alongside an older cluster the CERT Coordination Center tracks as VU#221883, covering CVE-2026-2275, CVE-2026-2285, CVE-2026-2286 and CVE-2026-2287, a cluster of CrewAI flaws that mixes the sandbox escapes with an arbitrary file read and an SSRF. Operators on pinned pre-1.14.0 releases are the ones who need to move.

There is no public report of this being exploited against a live system. The Local attack vector and the requirement that the agent already run in-process mean the flaw matters most where the sandbox is the last thing between agent-written code and the host, which was the fallback the framework shipped until the fix.

This is a framework-sandbox escape rather than a prompt-injection route to one. The boundary it crossed was the tool's own, and the reported mechanism is a property of how Python resolves objects and libraries, not of what the model was asked to do.