iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
CrewAI’s CVE-2026-37008 was not fixed by adding more forbidden module names: the Python sandbox ran inside the same interpreter it was trying to restrict. The GitHub advisory says revisions before commit fb2323b are the relevant source boundary, but it does not map that boundary to affected or fixed package versions. The fix removed the restricted in-process fallback; do not infer whether an installation is affected from its version number alone.
Why did the nine-name blocklist fail?
The “nine names” refers to the pre-fix implementation’s BLOCKED_MODULES list as described in a secondary technical write-up. It is not a count of every way to escape. The underlying flaw was broader: rejecting selected module names during imports does not contain the full Python interpreter when untrusted code still runs inside that interpreter.
The GitHub Advisory Database explains that Python’s object graph can expose routes to functionality beyond ordinary import statements. Its concrete example is ctypes.CDLL(None), which can reach native library functionality without importing a blocked module by name. A list of disallowed imports therefore cannot serve as a reliable security boundary for code running in the same process.
The advisory identifies the issue as CWE-424, Improper Protection of Alternate Path, and gives CVE-2026-37008 a CVSS 3.1 score of 8.1, vector AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L. Those details apply to this blocklist/runtime-boundary flaw, not to the separate CrewAI Docker-fallback CVE discussed below. GitHub Advisory Database: GHSA-2q68-3cp7-72v9
#1 Best Overall
What code boundary does CVE-2026-37008 establish?
The advisory identifies CrewAI revisions before commit fb2323b as relevant. It does not name an affected package or provide affected and patched package versions; both are listed as unknown. As a result, a release number by itself cannot establish whether a particular deployment contains the vulnerable code.
The commit message for fb2323b, titled “Code interpreter sandbox escape (#4791),” says object introspection could recover the original __import__ function, enabling arbitrary module access and command execution on the host. The change removes the insecure in-process fallback and makes the safety runner fail closed when Docker is unavailable. It also marks the restricted sandbox insecure and says users unable to use Docker must explicitly opt into unsafe_mode=True, accepting the risks. CrewAI commit fb2323b
How to check a deployed CrewAI installation
- Identify the source actually deployed. Check the installed artifact and, if built from source, its commit or equivalent changes. Determine whether it includes
fb2323bor a later equivalent that removes the in-process restricted fallback. The advisory supplies a commit boundary, not a package-version range. - Inspect the execution configuration and code. Establish whether the deployment attaches a code-interpreter tool, enables code execution, sets
unsafe_mode=True, or uses custom or forked code that restores an in-process fallback. A version label alone will not answer these questions. - Verify the execution boundary and failure behavior. Confirm where untrusted code runs and what happens if the execution environment is unavailable. The security-relevant distinction is whether execution fails closed or falls back to code running in the application’s Python process.
- Compare against vendor status for the version in use. Check the vendor’s release information and the deployed artifact rather than assuming that a particular package number is patched. A later deployment may differ in version, configuration, or custom code from the status reported in the advisories.
How the related CrewAI CVEs differ
CVE-2026-37008 concerns the in-process sandbox’s inability to constrain Python’s complete runtime. CERT/CC VU#221883 separately describes a cluster of CrewAI issues, including Docker-to-sandbox fallback conditions. Their triggers and impacts should not be treated as the CVE-2026-37008 mechanism.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute| Identifier | Issue described by the source | Important distinction |
|---|---|---|
| CVE-2026-37008 | Import-name blocklisting did not contain the Python runtime; the advisory cites access through object introspection and ctypes.CDLL(None). |
Relevant source boundary: revisions before fb2323b. No affected or patched package versions are stated. CVSS 3.1: 8.1 in the GitHub advisory. |
| CVE-2026-2275 | CERT/CC describes CodeInterpreterTool falling back to SandboxPython when Docker cannot be reached. | Reported conditions include allow_code_execution=True or manually attaching the tool. |
| CVE-2026-2287 | CERT/CC describes failure to check that Docker remains running during runtime, followed by fallback to a sandbox permitting remote code execution. | INCIBE-CERT separately gives this CVE a CVSS 3.1 score of 9.8. That score is not the score for CVE-2026-37008. |
| CVE-2026-2286 | CERT/CC describes SSRF in RAG search tools that fail to validate runtime URLs. | A URL-validation issue, distinct from the Python import blocklist and Docker runtime checks. |
| CVE-2026-2285 | CERT/CC describes arbitrary local file read through a JSON loader without path validation. | A file-path validation issue, distinct from the sandbox runtime flaw. |
CERT/CC says the related cluster can be exploited when an attacker can influence an agent using the Code Interpreter Tool through direct or indirect prompt injection, with potential arbitrary file read, remote code execution, and SSRF. Those conditions and impacts describe the cluster; they should not automatically be assigned to CVE-2026-37008. CERT/CC VU#221883 INCIBE-CERT: CVE-2026-2287
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What remediation status did CrewAI report?
The fix represented by fb2323b removes the restricted in-process fallback and requires Docker for safe code execution, failing closed when Docker is unavailable. That is the commit-level response to the blocklist flaw.
In a vendor update dated May 20, 2026, CERT/CC reported that CrewAI had completely removed the CodeInterpreterTool, including its Docker sandbox and insecure SandboxPython fallback; deprecated allow_code_execution; and recommended external sandboxes. The same update said current releases contain fixes and described centralized validate_file_path() and validate_url() changes addressing the related file-read and SSRF issues. Treat this as status reported on that date, not as proof about every later or customized deployment. CERT/CC VU#221883
When assessing an execution setup, focus on four things: the isolation boundary (in-process versus a separate container or service), whether loss of the runtime fails closed or triggers a fallback, compatibility with the deployed CrewAI code, and the operational work needed to verify patches and monitor the execution service. CERT/CC names E2B and Daytona as examples of external sandboxes; the cited status does not establish their present features or compatibility.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
