As AI agents and automation platforms increasingly execute code generated by models or users, the security boundaries surrounding that code have become critical.
Research presented at DEF CON 34 by Cyera researchers Vladimir Tokarev and Saar Pearl found that seven products using Pyodide relied on Python-level restrictions that did not fully isolate untrusted code from the underlying host environment.
Key takeaways of the Cyera research
- Researchers identified Pyodide sandbox escapes across seven products, finding that Python-level restrictions did not fully isolate untrusted code from the underlying host environment.
- The research resulted in four CVEs rated from 8.3 to 9.9, including a critical n8n vulnerability that could potentially expose credentials associated with connected integrations.
- The host environment determines the potential impact of a sandbox escape, putting API credentials, source code, signing keys, internal services, databases, and other sensitive resources at risk.
- Organizations should use defense-in-depth controls for untrusted code execution, including independent isolation, least-privilege access, network restrictions, short-lived credentials, monitoring, and regular incident response testing.
Why Pyodide sandbox security matters for AI applications
Pyodide runs CPython in WebAssembly (WASM), allowing applications to execute Python inside JavaScript environments such as browsers, Node.js, and Deno.
Product developers can restrict potentially dangerous Python modules such as os and subprocess, creating what appears to be a sandbox for executing untrusted code.
However, the researchers found that restrictions across all seven tested products did not account for Python’s ctypes module and functions exported by Emscripten.
This created a pathway from supposedly restricted Python code into the JavaScript host runtime.
The disclosures resulted in four CVEs, with severity scores ranging from 8.3 to 9.9.
The fundamental problem was architectural rather than unique to one application.
WASM protects its own linear memory, but it does not prevent software from accessing capabilities that the embedding environment intentionally exposes.
In the configurations tested, ctypes remained available and could resolve relevant Emscripten functions.
Seven products affected by Pyodide sandbox vulnerabilities
The researchers reproduced related sandbox escapes across workflow automation, spreadsheets, AI-agent runtimes, desktop applications, and continuous integration and continuous delivery (CI/CD) tooling.
Among the most severe findings was CVE-2025-68668, rated 9.9, affecting n8n.
Its Code node allowed Python execution through Pyodide on Node.js.
The bypass could allow attackers to reach the n8n service process and potentially access credentials tied to connected integrations.
In response, n8n moved Python code execution to an external runner, further isolating it from the core service.
Grist, an open-source spreadsheet and database platform that supports Python-based formulas, was affected by CVE-2026-24002. The vulnerability was rated with a CVSS score of 9.1.
Cohere’s Terrarium, a sandboxed environment for executing AI-generated code, was impacted by CVE-2026-61522, which carries a CVSS score of 9.3.
Hugging Face’s smolagents, a framework for building AI agents that can execute code and use external tools, was also affected by CVE-2026-10613 and given a CVSS score of 8.3.
The research also identified security concerns involving langchain-sandbox, stlite, and cibuildwheel.
Maintainer responses differed across the projects, with some implementing architectural changes, others archiving affected components, and some maintaining that proper isolation should be enforced at the deployment level.
How host runtimes increase Pyodide sandbox security risks
Escaping Pyodide was only part of the security equation. The researchers emphasized that the host runtime and surrounding environment determine the potential impact.
For example, Node[.]js processes can expose filesystem, process, and environment APIs.
Deno uses explicit permissions that can limit capabilities such as filesystem, network, and subprocess access.
In CI/CD environments, a sandbox escape could expose sensitive assets such as publishing tokens, signing keys, proprietary source code, and release artifacts.
AI agent environments present similar risks, potentially giving attackers access to API credentials, internal services, databases, connected tools, and sensitive customer data.
How to secure Pyodide with defense-in-depth controls
The findings demonstrate why organizations should not treat Python import restrictions as a complete security boundary.
Product teams should restrict unnecessary ctypes functionality, favor module allowlists, remove unnecessary Emscripten exports, and minimize host-runtime permissions.
Untrusted code should also execute behind an independent isolation boundary, such as a separate process or container.
Organizations using affected frameworks should upgrade to patched versions or apply vendor-recommended mitigations.
Beyond addressing individual vulnerabilities, teams should implement defense-in-depth controls designed to limit what an attacker can access if the sandbox is bypassed.
- Enforce least-privilege access using dedicated service accounts and narrowly scoped permissions for workloads executing untrusted code.
- Restrict outbound network access to prevent compromised workloads from reaching unnecessary internal services or exfiltrating sensitive data.
- Use short-lived, workload-specific credentials and avoid exposing long-lived secrets to sandboxed environments.
- Separate sensitive CI/CD functions and credentials, including build, signing, publishing, and production access, to limit the impact of a compromised pipeline stage.
- Restrict filesystem and host access with read-only mounts, minimal host permissions, and access only to resources required by the workload.
- Use ephemeral containers or isolated processes for untrusted workloads so environments can be discarded after execution rather than maintaining persistent access or state.
- Monitor sandboxed workloads for suspicious behavior, including unexpected process creation, network connections, file access, and privilege-escalation attempts.
- Test sandbox-escape and incident response scenarios regularly with attack simulation tools to verify that teams can contain compromised workloads, revoke access, and rotate exposed credentials quickly.
Layering these controls can reduce both the likelihood of a successful sandbox escape and the potential blast radius when an isolation mechanism fails.
Bottom line
The research highlights a broader lesson for AI security: a sandbox is only as strong as the boundaries beneath it.
As AI systems gain greater authority to execute code and interact with sensitive resources, organizations must secure not only what code can call inside an interpreter, but also what it can reach if that interpreter-level boundary fails.
A zero trust architecture can help strengthen these boundaries by continuously verifying access, enforcing least privilege, and limiting what compromised AI workloads can reach across the broader environment.