CrewAI sandbox CVE details import blocklist bypass that needs no imports

A newly published vulnerability record for CrewAI, a widely used agent framework, describes a Python sandbox whose entire defense was a list of nine blocked module names — and shows that the list could be defeated without executing a single import statement. According to a dev.to writeup that examined the NVD record, MITRE's CNA data, and the fixing commit on GitHub, CVE-2026-37008 was published on 2026-09-13 by MITRE, carries a CVSS 3.1 base score of 8.1 (HIGH) with the vector AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L, and is classed as CWE-424, improper protection of an alternate path.

What the sandbox actually did

The vulnerable code lived in crewai-tools, inside the CodeInterpreterTool's SandboxPython class. When the framework needed to run model-written Python and Docker was not reachable, it fell back to executing that code with a plain exec() in the host process. The protections were thin: a builtins dictionary stripped of ten unsafe names such as exec, eval and open, and a replacement import hook that raised an error whenever the requested module was one of nine names — os, sys, subprocess, shutil, importlib, inspect, tempfile, sysconfig or builtins.

The CVE's core argument, as the dev.to analysis relays it, is not that one dangerous module was accidentally left off the list. It is that blocking module names at import time cannot work in principle, because the interpreter's complete object graph remains reachable regardless of the import system. The record's own example is ctypes.CDLL(None), which asks the platform loader to open the running process itself and returns a handle exposing libc symbols. No Python import statement runs, so the filter never fires — and ctypes was not even among the nine blocked names.

A second escape, documented in the fix

The fixing commit contains a second demonstration. A test added alongside the patch recovers the original import by walking the object graph: start from the empty tuple's class, list its subclasses, find one whose module still holds the genuine builtins, and pull the real import function back out. After that step, the blocklist is guarding a door the attacker is no longer using. Both escapes defeat the filter by never passing through it.

How code reached the sandbox

The dangerous fallback was never the default configuration. Per CERT/CC records cited in the writeup, reaching it required an operator to set allow_code_execution=True or manually attach the CodeInterpreterTool. The tool then checks for Docker: if it is present, model code runs in a container; if not, the tool silently falls back to the in-process sandbox. A sibling disclosure, CVE-2026-2287, covers Docker stopping mid-session, which triggers the same fallback even though nobody configured anything unsafe.

The fix, commit fb2323b merged on 2026-03-15, did not extend the blocklist. It deleted the fallback: when Docker is unavailable, the tool now raises an error instead of quietly running code inside the host process.

Who is actually affected

The dev.to analysis stresses that realistic exposure today is narrow. The fix first shipped in v1.11.0rc1, tagged the same day it merged. Version 1.14.0, released in April, removed CodeInterpreterTool entirely and deprecated the code execution parameters in favor of external sandboxes, and every current tag up to 1.15.21 contains the fix. A fresh pip install of crewai never included the vulnerable code. The affected audience is projects pinned below 1.11.0rc1, forks and vendored copies of older crewai-tools, and codebases built on outdated tutorials claiming the sandbox keeps model code contained.

The record itself complicates version checking. The affected range is defined by commit boundary — every revision before fb2323b — rather than a version number, so there is no simple pip comparison to make. The corresponding GitHub advisory, GHSA-2q68-3cp7-72v9, is unreviewed with "Unknown" in both the affected and patched fields, and NVD has ingested the CVE without further analysis, leaving the CNA's score as the only official one. The record was reserved on 2026-04-06 and published roughly five months later; neither entry explains the gap.

Why it matters

The CVE documents a structural lesson, not a missing entry in a list. An in-process Python sandbox that filters imports watches the wrong layer: the runtime offers alternate paths — native library handles, the class hierarchy of built-in objects — that never touch the import system, so any name-based blocklist can be routed around. It also illustrates the fail-open pattern now recurring across agent frameworks: isolation that is real right up until a dependency is missing, at which point it is silently skipped. Teams running agent-generated code should prefer container or external sandboxes, treat tutorial claims about built-in sandboxes skeptically, and check whether their pinned framework versions predate these fixes.