Cloudbleed: What a Leaking CDN Teaches About Shared Infrastructure

On February 23rd, Tavis Ormandy of Google's Project Zero disclosed a bug in Cloudflare's edge servers that had been leaking private memory onto the public web: session cookies, authentication tokens, API keys, private messages, from sites that had done nothing wrong. It was quickly named Cloudbleed, after Heartbleed, and the comparison is fair. The leak was invisible until someone looked, and the data exposed could belong to almost anyone.

If your site sits behind Cloudflare, or you log into sites that do (which is nearly everyone), this incident deserves attention. Not because Cloudflare was unusually careless (their response was fast and unusually transparent), but because Cloudbleed shows a kind of risk most of us have stopped thinking about: the shared machinery between your server and your users.

What happened

Cloudflare's edge servers don't only cache and forward traffic. For certain features they parse and rewrite customers' HTML in flight. Email obfuscation, Server-Side Excludes and Automatic HTTPS Rewrites all run pages through an HTML parser on Cloudflare's machines before the response reaches the visitor.

That parser had a bug. Certain malformed HTML, roughly an unterminated attribute near the end of an internal buffer, could push the parser past the end of the memory it was supposed to read. When that happened, whatever sat in adjacent memory was copied into the response. Because a single edge process handles traffic for many customers, that adjacent memory could hold other sites' traffic: their visitors' cookies, API responses and POST bodies.

The leaked data went to whoever happened to fetch an affected page. That includes ordinary visitors and search engine crawlers, which cached some of it in public search results. Cloudflare says the earliest possible leakage dates to September 22, 2016, with the worst period in mid-February. At its peak, by their estimate, about one in every 3.3 million requests through their network could leak. That sounds small until you consider how many requests Cloudflare serves.

The bug was mitigated within hours of the report. Scrubbing search engine caches has taken longer, and it's safest to assume not every cached fragment will be found.

Why this incident is hard to reason about

Cloudbleed breaks the usual mental model of a breach:

• You didn't have to be the trigger. The malformed HTML lived on someone's site; the leaked memory could belong to anyone's. Your users' data may have leaked through a page you've never heard of.
• You can't audit your own exposure. Nothing touched your servers, so nothing appears in your logs. There's no query that tells you whether your users' sessions were among the leaked fragments.
• The data went to random places. Visitors, crawler caches, anyone watching. There's no public evidence of deliberate exploitation so far, but with a leak like this, absence of evidence doesn't tell you much.
• HTTPS didn't help. The leak happened after TLS termination, inside infrastructure you had authorized to decrypt your traffic.

Lesson one: you inherit your CDN's bugs

When you put a CDN or WAF in front of your site, you give it your TLS keys (or let it hold its own certificate for your domain) and authorize it to read and rewrite every byte between you and your users. That's usually a good trade, since the performance and DDoS protection are real, but the CDN's parser bugs become your bugs and its blast radius becomes yours.

Millions of sites route through a handful of edge networks. That concentration is efficient, and it's why one buffer overrun leaked secrets across the internet. The takeaway isn't to avoid CDNs; it's to know your dependencies. If you can't say which providers terminate TLS for your domains, find out:

curl -sI https://www.example.com | grep -iE '^(server|cf-ray|via|x-served-by):'

Keep a plain list of every domain you own and every third party in the request path that can read plaintext. When the next upstream incident lands, that list turns a day of guessing into a ten-minute assessment.

Lesson two: rotate secrets after upstream incidents

Because exposure can't be determined, the defensible response is to assume the worst for anything that passed through the affected infrastructure during the window. If your site was behind Cloudflare, especially with the HTML-rewriting features enabled, rotate:

• Session tokens. Invalidate active sessions and force re-login. It's an annoying email to send, but far less annoying than the alternative.
• API keys and tokens. Anything your users or systems send through the edge in headers or bodies: bearer tokens, webhook secrets, integration keys.
• Cookie signing secrets. Rotating the application-side secret invalidates every outstanding cookie at once.
• Passwords: encourage a change, don't necessarily force one. Without evidence of targeted exploitation, a forced global reset may be disproportionate. A clear recommendation plus two-factor support is a reasonable middle course. Make the call deliberately and write down why.

The principle outlasts this incident: your secrets are only as private as every system that handles them, and a bug in one of those systems should trigger rotation by default.

Lesson three: responding when it wasn't your fault

Your users don't experience "Cloudflare had a bug". They experience "a site I trust may have leaked my session". Whose fault it was doesn't matter to them, so it can't drive your communication:

• Say something, even when your exposure is uncertain. A short, factual note (what happened upstream, what it could mean for users, what you've rotated, what they should do) beats silence followed by a pile of support tickets.
• Track your providers' disclosures like your own alerts. The gap between a vendor's public post and your team hearing about it is pure risk. Subscribe to your providers' status and security feeds and make someone responsible for reading them.
• Rehearse an upstream-incident playbook. Most incident plans assume the bug is yours. The teams that handled this one well already knew who decides on session invalidation and who writes the user notice.

Shared infrastructure means shared fate

The modern web runs on trust relationships most of us no longer notice. You can outsource serving your site, but not the accountability for it. Knowing your dependencies, watching them from outside and reacting quickly when one of them fails is part of running a website.

CompleteStatus provides that outside view: automated checks on your site's availability and SSL certificates from the public internet, the same vantage point your users have, with alerts when something changes. See the features page, or create a free account.