Build1 publisher2 min readPublished
CrewAI deletes its code-sandbox blocklist after ctypes.CDLL(None) bypassed all nine names
MITRE rated CrewAI's nine-name code-sandbox blocklist a CVSS 8.1 flaw, bypassed by a call that executes no import. The fix removed the feature, so teams running agent-written code need isolation at the OS or process level.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- When Docker was unavailable, the sandbox ran model-written Python with plain exec() in the same process, filtered ten builtins such as exec, eval and open, and swapped a custom import check in for __import__.
- MITRE filed the weakness as CWE-424, improper protection of an alternate path: one route was guarded while an equivalent one stayed open.
- In a statement to CERT/CC about the sibling disclosure, CrewAI conceded the gap its own blocklist left open.
- No release maps to the fix, so a pip install leaves nothing to compare, and GitHub's advisory GHSA-2q68-3cp7-72v9 is unreviewed with affected and patched versions both listed as Unknown.
- The fix landed six months before the record appeared, well ahead of the CVE assignment.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Because a within-process sandbox has to account for the interpreter's whole runtime, naming more modules cannot fix it; isolation that holds belongs in a container or a separate process.
- decision Teams on the Docker-unavailable path now choose between guaranteeing Docker so exec() never runs and moving agent code into a separate process or VM with its own privileges.
- exposure Because the vector marks scope Changed, a successful escape reaches past the sandbox into the host it runs on, not just the interpreter's own namespace.
ctypes.CDLL(None) asks the platform loader to open the running process itself, and the handle it returns carries a symbol table that already includes libc [17]. No import statement runs, so the restricted_import the sandbox swapped in for __import__ never sees a name to reject [17]. The record gives exactly this example: the call loads the C library with no import at all [9]. From that handle, write-ups of the March disclosure describe reaching native calls directly, as far as system() [18].
That is why extending the list would have changed nothing [22]. The record is blunt about where the failure sits, calling the design one that "operates at the wrong level of abstraction" [2], and it spells the reason out: import-time blocking of module names "does not address the availability of Python's complete object graph" [8]. A longer list would guard the same wrong thing, with more entries. The nine also left socket and pathlib reachable by ordinary import, the smaller problem [13].
MITRE published the record on 2026-09-13 as the CNA, and it is candid about its own limits [1]. The weakness is a different vulnerability from CVE-2026-2275, the record says so directly [11]. There is no CVSS 4.0 score, and NVD took the record in without analyzing it, so the CNA's own figure is the only one on an official source [6].
The affected range is a git boundary: every revision before commit fb2323b [19]. A git boundary gives you no release to pin, so verification means reading the source. Open SandboxPython in your installed crewai-tools [14], and if BLOCKED_MODULES and restricted_import are still present [12], you are running the code the CVE describes [1].
What to watch
- Whether NVD finishes its analysis and assigns its own CVSS, including a 3.1 or 4.0 score that could differ from the CNA's 8.1.
- Whether CrewAI ships a release version mapped to commit fb2323b so pip users can pin a patched build.
- How CVE-2026-2275, the sibling disclosure CrewAI conceded to CERT/CC, is scored and resolved.