Cloudflare Python Workers Hit GA: What the WASM Sandbox Means for Security

Cloudflare has taken Python Workers out of preview: as Simon Willison notes, Python is now, in Cloudflare's words, "a first-class, fully supported language on the Cloudflare Developer Platform." The two-year gap between preview and GA is notable in itself — it reflects how much groundwork had to go into running a full CPython environment somewhere it was never designed to run.

How it actually works

Per Cloudflare's announcement, Python code is compiled to WebAssembly via Pyodide and executed inside Cloudflare's existing V8-based workerd runtime — the same isolate model that already runs JavaScript Workers. That's a meaningfully different isolation story from a typical Python deployment: instead of process- or container-level separation between tenants, the boundary is a WebAssembly sandbox running inside a V8 isolate. Cloudflare has run untrusted JavaScript this way since Workers launched, so the isolate model itself is mature — but it's now carrying a much heavier interpreter (a compiled CPython) than it was originally built around.

The platform now supports FastAPI (async, via a workers.asgi connector) and Django/Flask-style synchronous apps (via workers.wsgi), plus native bindings so Python objects no longer need manual conversion to JavaScript at the RPC boundary.

The security-relevant trade-off: no threads, no processes

Cloudflare's own documentation is explicit that both `multiprocessing` and `threading` are non-functional inside the WebAssembly VM. For security teams this cuts two ways. On one hand, an entire category of concurrency bugs — race conditions, unsafe shared-memory access between threads, fork-based privilege confusion — simply can't occur, because the primitives aren't there. On the other hand, any code that leans on process isolation as a *security* boundary (sandboxing a parser, isolating untrusted input handling in a subprocess) won't get that guarantee here; the WASM sandbox is the only isolation layer available, and everything runs inside it together.

A new front door for the Python supply chain

The more consequential change for supply-chain risk is upstream of Cloudflare entirely. PEP 783 — proposed by Cloudflare engineers and accepted this year — standardizes a pyemscripten platform tag so that Python packages can publish WebAssembly-targeted wheels directly to PyPI, rather than needing a bespoke Pyodide build. That's a genuine win for the ecosystem: it means the packages Python Workers can pull in will grow well beyond what Cloudflare curates itself.

It also means PyPI's existing supply-chain problems — typosquatting, dependency confusion, unmaintained packages with quietly transferred ownership — now extend into a new deployment target that many teams will treat as "just serverless functions" and under-scrutinize accordingly. A malicious or compromised wasm32 wheel pulled into a Worker still runs with whatever bindings and credentials that Worker holds; the WASM boundary protects the host runtime, not the application's own secrets and API access.

What this means for teams adopting it

• Treat Python Workers as a genuinely new deployment surface for review purposes, not an extension of existing Python hosting — the isolation model, package supply chain, and available stdlib all differ.
• Audit which third-party packages a Worker pulls in, same as you would for any dependency with access to bindings, secrets, or upstream services — WASM sandboxing does not vet package provenance.
• Don't assume process-level isolation for anything moved into this environment; if your threat model relied on subprocess sandboxing, that primitive isn't available here.

None of this makes Python Workers unsafe — Cloudflare's isolate model has years of production hardening behind it. It does mean the security review for a new Worker deployment should look different from the review for a traditional Python service, and teams moving fast to adopt GA features are the ones most likely to skip that step.