A serious security flaw in Cloudflare Containers allowed a client to read data left behind by other users' containers on the same server. Cloudflare Containers is a service that runs client programs in isolated environments on shared servers, and the vulnerability compromised data that remained on disk after a container was deleted. The disclosure has raised concerns in the cybersecurity community, as it concerns a service widely used to execute code in cloud environments.
See also: Cloudflare Kitesurf: A Browser Built for AI Agents — What's Changing
The vulnerability was discovered and reported on September 4, 2025, by researcher Oren Yomtov of cybersecurity firm Accomplish , through Cloudflare 's official bug bounty program . The issue did not involve active data in use, but rather leftover data from previous users that had not been properly deleted from shared storage. Importantly, an attacker could not choose whose data to read — access was random and depended on the server Cloudflare selected .
The same issue also affected Cloudflare Sandboxes, a service advertised as a safe environment for running untrusted code, including code generated by artificial intelligence (AI). This discovery makes addressing the issue even more critical, given that Cloudflare Sandboxes are used precisely for high-security scenarios.
How the Cloudflare Containers vulnerability worked
The root of the problem lay in the configuration of shared disks. Each container received a disk through a Linux called thin provisioning, which allocates storage space in 64-kilobyte. When a container was deleted, its blocks were returned to a shared pool. The critical flaw was that this pool was configured to skip wiping a block before assigning it to a new container. This meant that if a new container wrote only a small amount of data to a reused block, the remaining space still contained data from the previous container.
The researchers demonstrated the vulnerability in a remarkably simple way: They wrote a 4-kilobyte to unused space and then read the entire block at the raw disk level. They found that the 60 kilobytes they hadn’t written themselves still contained data from a previous container. In their tests, they reported finding data remnants in 18 out of 24 attempts across multiple servers, and on 20 out of 22 underlying machines worldwide — a rate that demonstrates how widespread the problem was.
The recovered blocks included directory structures, database pages, and entire SQLite databases . The researchers' report documented directory listings, SQLite databases , Chromium browser profiles , .env files , and credential files , which were identified as belonging to other customers. .env files and credential files are particularly sensitive, as they often contain API keys , passwords, and other secrets used in production systems.
See also: Spectre Attack on Cloudflare Workers: JWT Leak (12 Bits/Second)
Addressing the vulnerability from Cloudflare Containers
Cloudflare addressed the vulnerability in two phases. First, it re-enabled the wiping process for new blocks, which prevented the method the researchers used. On September 14, the researchers confirmed that proof of concept was no longer effective. However, this change did not affect blocks that were already mapped to active disk containers or cached image layers, which new containers could still access.
Therefore, Cloudflare proceeded to a second phase of remediation: it retired all active container disks and purged caches. This purge was completed on September 19, and the public disclosure of the vulnerability took place five days later, on September 24. Cloudflare also said that it was conducting an investigation to determine whether anyone else had exploited the vulnerability, creating detection signatures based on proof of concept . Analysis of disk activity logs did not reveal any unauthorized use — only authorized testing by the company’s researchers and engineers.
It's worth noting that the researchers confirmed that their analysis scripts only produced metrics and format checks, not actual file contents. The data sent to Cloudflare did not contain any third-party names, identifiers, or credentials. Cloudflare said that the retrieved data remained private and was securely deleted after submission.
The same disk formatting issue also affected the Cloudflare Browser Run product , according to the researchers, who called this vulnerability their sixth code execution environment escape — an impressive feat that highlights the Accomplish team's experience and expertise .
What this means for Cloudflare Containers users
This vulnerability highlights a classic problem in multi-tenant cloud environments: insufficient data isolation between customers sharing the same physical infrastructure. Thin provisioning is a widely used technology that optimizes storage usage, but it requires careful configuration to ensure that one customer's data is not accessible by another. The failure to wipe blocks before reusing them is a bug that could have been avoided with stricter security policies.
Although Cloudflare did not disclose how long the vulnerability had been active or when the insecure setting was first implemented, its quick response to the report is commendable. The company followed its responsible disclosure and worked with researchers to verify and address the issue. However, the lack of transparency about the length of time the exposure has been in place leaves questions unanswered for customers using Cloudflare Containers and Cloudflare Sandboxes.
See also: Cloudflare OS: Open AI workspace for enterprises
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
For organizations using cloud container services , this incident is a reminder that security is not just about the application, but also about the configuration of the underlying infrastructure. It is recommended to avoid storing sensitive data such as API keys , passwords, and credentials in .env files within containers, and to use dedicated secrets management services instead . In addition, regular review of cloud infrastructure security settings is essential to detect similar issues in a timely manner. Cloudflare has already completed addressing the issue and there is no evidence of malicious exploitation.
