A Hacker Read 64KB of Another Customer’s Data on Cloudflare.

A Hacker Read 64KB of Another Customer's Data on Cloudflare. He Got Paid Through Bug Bounty. Here's How.

The simplest attack chain I've ever read about — and the most terrifying.

I read the Cloudflare disclosure on a Thursday night and couldn't stop thinking about how simple it was.

Not simple to find. Simple to understand.

The whole thing came down to 64 kilobytes of disk space that nobody bothered to wipe .

What Actually Happened

Cloudflare runs customer code in containers on shared servers. When a container gets deleted, its disk blocks go back into a pool that other customers' containers can use. Linux has a feature called thin provisioning that allocates storage in 64-kilobyte chunks.

The pool was set to skip wiping a block before handing it to the next customer. Normally, wiping is the default. But this setting was wrong .

So here's what a researcher named Oren Yomtov figured out: if you write a tiny 4-kilobyte file into a fresh container, the rest of that 64KB block — 60 kilobytes — still contains data from whoever used that block last.

You read the whole block back at the raw disk level, and you see their leftovers.

Directory structures. SQLite databases. Browser profiles. .env files with credentials. Other customers' files .

The Part That Makes This Different

Here's what separates this from the indexed-btree supply chain attack I wrote about earlier. That one required understanding smart contracts, encryption key exchange, and dependency chains. This one required understanding one thing: blocks aren't wiped.

Oren reported it through Cloudflare's bug bounty program on September 4. Cloudflare fixed it in two steps and disclosed on September 24 .

The researchers tested it in production. They got leftover data on 18 of 24 attempts. On 20 of 22 underlying machines across four continents .

They didn't choose whose data they got. They didn't need to. The attack was blind — you get whatever the previous container left behind. But that's enough. Directory listings. Database pages. Credential files.

Why This Matters for Bug Bounty Beginners

I've been learning bug bounty for months. I've read about IDOR, broken access control, SQL injection. I've tested applications and found one confirmed bug.

Reading about this Cloudflare flaw, I felt something I hadn't expected: hope.

Because the vulnerability wasn't in Cloudflare's code. It wasn't in their application logic. It was in a configuration setting — one flag that determined whether disk blocks got wiped before reuse.

The research didn't require custom exploit chains. It required noticing that something should happen but didn't.

That's the kind of bug a beginner can find. Not by running scans. Not by fuzzing endpoints. By reading how a system works and asking: what's supposed to happen here that isn't?

The 64KB Lesson

Here's what I'm taking from this:

Small attack surfaces have big impacts. 64 kilobytes. That's less than a single photo. But it was enough to expose database files and credentials.

Configuration is code. The default was to wipe blocks. Someone changed it. That change was the vulnerability. Every bug bounty hunter should learn to look at what's configured, not just what's coded.

Blind attacks still work. The researcher couldn't choose the victim. They got random leftovers. But random is enough. Random SQLite files contain random credentials. Random credentials unlock random systems.

I don't have Oren's skill. I don't have his experience. But I can start looking at configurations the way he did. I can ask: what should be happening here that isn't?

That's the job.

If you're also learning to find bugs by looking at what's broken beneath the surface, I write about what I'm actually figuring out — confusion included. Follow for more field notes from the bottom of the learning curve.