As reported by The Hacker News, Cloudflare disclosed and patched a cross-tenant data leakage vulnerability in its Containers platform that allowed paying customers to read residual disk data left behind by other customers' terminated containers. The issue, reported on September 4, 2026 by Oren Yomtov of Accomplish, stemmed from a thin provisioning configuration that skipped block wiping before reallocating 64KB storage blocks to new containers.
This is a textbook example of how multi-tenant isolation can fail not at the compute boundary, but at the storage reclamation layer. The containers themselves were properly isolated at runtime. The failure occurred in the gap between workload termination and resource reuse — a lifecycle stage that many platform engineers treat as a housekeeping detail rather than a security-critical transition.
Vulnerability Details
| Vendor / Product | Cloudflare Containers, Cloudflare Sandboxes |
| CVE Identifier | Not assigned / not publicly disclosed at time of reporting |
| Severity | High (cross-tenant data exposure, no CVE/CVSS published) |
| Root Cause | Thin provisioning pool configured to skip block wiping before reallocation (non-default setting) |
| Data Exposed | Directory listings, SQLite databases, Chromium profiles, .env files, credential files from prior tenant containers |
| Exploitation Observed | No malicious exploitation; researchers found leftover data on 18 of 24 attempts across 20 of 22 hosts on four continents |
| Patch Status | Fixed — block wiping re-enabled; no customer action required |
| Reporter | Oren Yomtov, Accomplish (via Cloudflare Bug Bounty) |
Why This Matters Beyond Cloudflare
The technical mechanism is specific to Cloudflare's infrastructure, but the failure pattern is industry-wide. Any platform that pools storage resources across tenants and relies on overwriting-on-allocation rather than cryptographic erasure is one configuration drift away from the same exposure. The fact that wiping was explicitly disabled — a non-default optimization — demonstrates how performance tuning can silently erode security boundaries without triggering any alert or review.
The most dangerous isolation failures are not architectural. They are operational — a single flag changed for throughput, a default overridden for latency, a cleanup step skipped to save milliseconds.
The data types recovered are particularly concerning. .env files and credential files are the crown jewels of application deployment. SQLite databases may contain application state, user records, or session data. Chromium profiles suggest some customers were running browser automation or rendering workloads — potentially exposing cookies, browsing history, or cached authentication tokens. Even though the attacker could not target a specific tenant, the volume and sensitivity of recoverable material made this a serious exposure.
The AI Sandbox Angle
Cloudflare Sandboxes — which runs on Containers and is marketed as a safe execution environment for untrusted code, including AI agent-generated code — was also affected. This elevates the risk profile significantly. AI code execution sandboxes are increasingly used to run LLM-generated or user-submitted code at scale. If the sandbox layer inherits storage isolation weaknesses from its underlying container platform, then the trust model that enterprises rely on to safely execute AI workflows has a foundational crack. Organizations adopting AI agent platforms should treat sandbox isolation as a first-tier due diligence question, not a marketing assumption.
Who Is at Risk
Cloudflare states no customer action is required, which is accurate for the platform-level fix. However, customers should independently assess whether sensitive data was present in container filesystems during the affected period and rotate any credentials that may have been stored in .env files or similar.
Shield53 Recommendations
- Audit container secrets exposure: Review what secrets, environment variables, and sensitive files were present in Cloudflare Container filesystems during the affected window. Rotate any credentials that were stored in plaintext within container layers.
- Use managed secrets, not .env files: Migrate to runtime secret injection via Cloudflare Workers Secrets, environment-bound key management, or external secret managers. Secrets should never persist in container filesystems.
- Assume ephemeral storage is not zeroed: Treat all ephemeral container storage as potentially observable by the platform or future tenants. Encrypt sensitive data at the application layer before writing to disk, or avoid writing it to local storage entirely.
- For platform builders — enforce cryptographic erasure: If you operate multi-tenant infrastructure, require block-level wiping or cryptographic key destruction on resource release. Do not rely on overwriting-on-write as an isolation guarantee. Implement automated drift detection for storage pool configurations.
- Vet AI sandbox isolation: Before adopting any AI code execution platform, demand documentation of storage isolation, block reclamation policies, and tenant boundary enforcement. Ask specifically what happens to disk data when a sandbox terminates.
- Implement defense-in-depth for AI workloads: Do not rely solely on the sandbox provider's isolation. Encrypt outputs, avoid persisting sensitive context in container filesystems, and segment AI execution environments from production data access.
This incident reinforces a sobering reality: in shared infrastructure, isolation is never guaranteed by architecture alone. It is maintained through continuous operational discipline — and every configuration change, no matter how small, is a potential boundary breach waiting for the right researcher or adversary to find it.
