decrypted · 25 september 2026 · ransomware and cybercrime · vulnerabilities and patching · supply chain

Cloudflare's shared disks kept the last customer's data, and the fix was a default

On Thursday, Cloudflare and the researcher who found it published details of a bug that let one customer's container read leftover data from a previous customer's container. Cloudflare says it found no evidence anyone else used the method, and that customers need do nothing. The interesting part is the cause: one storage setting, named skip_block_zeroing, which says exactly what it did. This is a story about a safe default that someone switched off.

What actually leaked

Cloudflare Containers, and the Sandboxes built on them, give each customer a virtual disk carved from a shared pool, handed out in 64 KiB blocks by Linux thin provisioning. When a container is deleted, its blocks return to the pool. Normally each block is wiped before the next customer receives it. On the affected pools, the wipe was turned off.

Picture a hotel that gives you a 64-page notebook but never removes the previous guest's notes. You write on four pages, and the other sixty are still theirs. In practice, a 4 KiB write into unused space triggered allocation of a whole 64 KiB block, and the other 60 KiB could hold a previous tenant's bytes. Oren Yomtov of Accomplish reported it through Cloudflare's bug bounty on 4 September. The researchers recovered directory listings, SQLite databases, Chromium profiles, .env files and credential files from other customers' containers. No exploit chain was needed.

What the defender sees

Almost nothing. The read happens at the block layer of your own disk: no login, no failed access, no alert. Cloudflare looked back by writing signatures for the telltale pattern, a 4 KiB write landing in a previously unmapped region, and searching historical disk telemetry. It found only authorised testing by the researchers and its own engineers. That is a good answer, but it is only as good as the telemetry retained, and no customer could have run that check.

The fix was quick: confirmed in production the same day, a runtime fix merged about six hours after the report, rollout finished on 7 September. The slow part came next. Removing the setting protects only new allocations, so Cloudflare retired every running container disk and cleared cached image snapshots, finishing on 19 September.

The Secure by Design lesson

A shared platform sells the promise that your neighbour cannot see your data. Tenant isolation is the product, so nothing tuned for speed or convenience should be able to weaken it quietly. The decision that would have prevented this is fail-safe defaults: zero on allocation, always, with any override reviewed like code and covered by a test. Write four kilobytes, read the sixty beside them, and fail the build if they are not zeros. Cloudflare's fix was simply to restore the default.

What UK organisations should take from it

This is opinion, not advice. You cannot audit a supplier's storage configuration, so ask for evidence. How do you test isolation between tenants? How long do you keep the telemetry that lets you look back?

If .env files or credentials lived on Containers or Sandboxes before the cleanup finished, rotating them costs an afternoon. Cloudflare found no exploitation, so that is insurance, not a response. The longer-term fix is fewer long-lived secrets on disks you do not control.

Also this week

A dormant supply chain attack woke up. Socket reports that two GitHub Actions, actions-cool/issues-helper and actions-cool/maintain-one-comment, were compromised in the Mini Shai-Hulud campaign on 18 May and disabled by GitHub the next day. They were re-enabled on 16 September with the malicious release tags still in place, so workflows referencing those tags ran the payload again and harvested CI/CD credentials. Both were disabled again on 25 September. Socket estimates roughly 15,000 downstream repositories were exposed through issues-helper alone; that figure comes from Socket only. Pin third-party actions to a full commit hash, not a movable tag.

TeamCity is now a ransomware entry point. BleepingComputer reports that CISA has updated its catalogue to flag CVE-2026-63077, a critical authentication bypass in JetBrains TeamCity On-Premises, as used in ransomware campaigns. JetBrains fixed it in versions 2025.11.7 and 2026.1.3, and advises restricting access to trusted networks if you cannot patch yet. Shadowserver counts about 160 exposed servers still unpatched. A build server holds the keys to everything it ships, so it deserves the care you give a domain controller.

Bitget loses $351.6 million. Bitget says an attacker compromised a backend system in its wallet infrastructure, spoofed transaction data and triggered its own authorisation process to move funds. It says its User Protection Fund will cover customer losses and that cold wallets were unaffected. Its chief executive says the method is consistent with North Korean groups, which is the victim's attribution rather than a finding. No UK link has been reported, but the lesson travels: an approval system should not trust the data it is asked to approve.

Sources

If you want a second pair of eyes on how your suppliers isolate your data, get in touch.