Cloudflare Container Vulnerability CVE-2024-4683 Exposes Customer Data

Key Takeaways

• Cloudflare has addressed a cross-tenant data exposure vulnerability (CVE-2024-4683) in its Containers and Sandboxes platforms.
• The flaw allowed one customer’s workload to retrieve residual disk data from other tenants on shared physical hosts.
• Exploitation required a Workers Paid account and was opportunistic, not targeted, due to Cloudflare’s automatic workload placement.
• The vulnerability has been patched across Cloudflare’s global infrastructure, with no evidence of malicious exploitation found.

Cloudflare Patches Cross-Tenant Data Exposure in Container Platform

Cloudflare has announced the remediation of a significant cross-tenant data exposure vulnerability, identified as CVE-2024-4683, within its Containers platform. This flaw, which also impacted Cloudflare Sandboxes, could have allowed a customer’s workload to recover residual disk data previously belonging to another tenant on the same physical server within Cloudflare’s multi-tenant cloud infrastructure.

Despite the potential for sensitive data exposure, Cloudflare stated that its internal telemetry showed no evidence of malicious exploitation or compromise of customer data. The company has since implemented comprehensive fixes across its global fleet.

Vulnerability Disclosure and Scope

The vulnerability was responsibly disclosed to Cloudflare through its HackerOne bug bounty program on September 4, 2026, by Oren Yomtov, a security researcher at Accomplish, who responsibly disclosed the flaw. Exploitation of this vulnerability required a Cloudflare Workers Paid account. Due to Cloudflare’s automated workload placement mechanisms, an attacker could not specifically choose a victim, host, workload, or target particular information. However, the flaw represented a critical breach of tenant-isolation boundaries inherent in shared cloud environments.

Technical Details of CVE-2024-4683

The core of CVE-2024-4683 lay in the storage layer, distinct from typical container or virtual machine escape vulnerabilities. Cloudflare’s architecture deploys each container within a dedicated Firecracker microVM, exposing its writable root disk as /dev/vdc. This virtual disk is backed by Linux’s device mapper thin provisioning (dm-thin), which allocates physical storage in 64 KiB blocks only when new data is written to an unmapped region of the virtual disk.

The vulnerability stemmed from Cloudflare’s use of the skip_block_zeroing option in its shared storage pools. When a container disk was deleted, its physical blocks were returned to a pool shared across multiple customer accounts. With skip_block_zeroing enabled, these newly allocated blocks were not cleared, meaning a recycled block could retain data from its previous owner until that specific data was overwritten by the new tenant.

Exploitation Mechanism

Researchers exploited this behavior by identifying 64 KiB-aligned free space regions within the guest’s ext4 filesystem and writing only 4 KiB into each. This small write operation forced dm-thin to allocate a recycled 64 KiB block, but only 4 KiB of that block would be overwritten. A subsequent raw-device read could then reveal residual data in the untouched 60 KiB of the block — data that the new container had never written.

Checksum analysis confirmed that the exposed blocks originated from other filesystems. Across six production placements, the research team examined 5,614 testable directory blocks. While none were attributed to their own proof-of-concept filesystem, they identified 2,700 distinct foreign directory inodes. Residual data was observed on 18 of 24 placements and 20 of 22 underlying nodes spanning four continents, including directory structures, database pages, and structurally complete SQLite databases.

It is important to note that this technique did not allow access to actively attached disks, permit modification of another customer’s live data, or impact workload availability. The retrieval of residual data was opportunistic, depending on scheduling and which freed blocks the allocator reassigned. Despite these limitations, the exposed fragments could potentially contain sensitive filesystem metadata, application information, or database content.

Remediation and Detection

Cloudflare’s initial response involved disabling the skip_block_zeroing option across its Containers fleet, thereby restoring dm-thin’s default behavior of clearing newly allocated blocks before they are exposed. Recognizing that this change would not sanitize blocks already mapped to running disks or cached OCI image snapshots, Cloudflare also undertook extensive remediation steps. These included retiring existing container disks, draining hosts, restarting virtual machines, and clearing image caches. The researchers independently verified that their proof of concept ceased to function after these measures.

Cloudflare then developed new detection signatures designed to identify the attack’s unusual disk-I/O pattern: small 4 KiB writes followed by significantly larger reads from newly allocated 64 KiB blocks. A review of historical data confirmed that only activity linked to the Accomplish researchers and Cloudflare engineers performing authorized validation was observed. The fleet-wide remediation implemented by Cloudflare requires no direct customer configuration changes.

What You Should Do

• Review your organization’s risk policies regarding secrets and sensitive data handled by Cloudflare Workers and Containers.
• Consider rotating any secrets (API keys, database credentials, etc.) that may have been handled by affected workloads as a precautionary measure, even though no malicious exploitation was detected.
• Stay informed about security advisories from Cloudflare and ensure your configurations align with their latest best practices for data isolation and security.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.