Cloudflare "Cloudbleed" memory leak

In February 2017, security researcher Tavis Ormandy of Google's Project Zero discovered that Cloudflare — the content-delivery and reverse-proxy network sitting in front of millions of websites — had been leaking random fragments of its own server memory into web pages. Those fragments could contain anything that had recently passed through Cloudflare's edge: passwords, session cookies, authentication tokens, HTTP POST bodies, and private messages belonging to entirely unrelated customers. Because some of the leaking pages were cached by search engines, sensitive data sat exposed in public caches long after the bug itself was fixed. The flaw was dubbed "Cloudbleed," echoing the 2014 Heartbleed vulnerability.

What happened

Cloudflare's edge servers ran an HTML parser that rewrote pages on the fly — to obfuscate email addresses, apply Server-Side Excludes, and automatically rewrite HTTP links to HTTPS. A subtle buffer-overrun bug in this parsing code meant that when a web page's HTML was malformed in a particular way, the parser would run past the end of a buffer and emit adjacent uninitialized memory into the response sent back to visitors.

That leaked memory was not random noise — it was live data from other requests flowing through the same Cloudflare servers. A visitor to one site could, by chance, receive a chunk of another person's password or private message embedded in the page they loaded.

Scale and exposure

• The bug could have leaked memory as early as 22 September 2016, but the period of greatest impact ran from roughly 13–18 February 2017, when a newly deployed feature dramatically increased the leak rate.
• At peak, about 1 in every 3.3 million HTTP requests through Cloudflare potentially leaked memory — a small ratio, but across Cloudflare's enormous traffic volume that meant the bug fired millions of times.
• The leaked data spanned a huge customer base: Cloudflare fronted millions of domains, so a single bug exposed fragments from across the web simultaneously.
• The most acute risk came from search-engine caches, where leaked data had been crawled and stored. Cloudflare worked with Google, Bing, Yahoo, and others to purge the cached pages.

Response

Ormandy reported the bug to Cloudflare on 17 February 2017. Cloudflare's team disabled the three offending features within hours of receiving the report, globally shut them down by the next day, and rolled out a permanent fix within days. The company published a detailed public incident report on 23 February. Investigators found no evidence that attackers had discovered or exploited the bug before it was reported.

Why it matters

Cloudbleed is the textbook example of how a single memory-safety bug in shared infrastructure can have outsized blast radius. Because Cloudflare's proxies handle traffic for millions of unrelated sites, a flaw affecting one code path leaked data indiscriminately across all of them — and the involvement of search-engine caching meant the cleanup extended far beyond patching the original servers. The incident reinforced two lessons: that memory-unsafe parsing code remains a critical risk in high-throughput systems, and that centralizing the web behind a handful of edge providers concentrates risk as well as benefit. It is frequently cited alongside Heartbleed as a reason to prefer memory-safe languages for security-sensitive parsers.