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 quietly leaking private memory onto the public web — session cookies, authentication tokens, API keys, private messages — from sites that had done absolutely nothing wrong. The internet promptly named it Cloudbleed, and the name fits: like Heartbleed before it, the wound was invisible until someone looked, and the blood was everyone's.

If your site sits behind Cloudflare — or you log into sites that do, which in practice means everyone — this incident deserves more than a shrug. Not because Cloudflare is uniquely careless (their response was fast and unusually transparent), but because Cloudbleed exposes a category of risk most of us have stopped thinking about: the shared machinery between your server and your users.

What actually happened

Cloudflare's edge servers don't just cache and forward traffic — for certain features, they parse and rewrite customers' HTML in flight. Email address obfuscation, Server-Side Excludes and Automatic HTTPS Rewrites all run your 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 landing 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 got copied into the response being built. And because a single edge process handles traffic for many customers at once, "whatever sat in adjacent memory" could be other sites' traffic: their visitors' cookies, their API responses, their POST bodies.

The leak didn't go to attackers by request — it went to whoever happened to fetch the malformed page. That includes ordinary visitors, and it includes search engine crawlers, which dutifully cached some of the leaked memory in public search results. Cloudflare says the earliest possible leakage dates to late September 2016, with the worst window in mid-February; at its peak, by their estimate, roughly one in every few million requests through their network could leak. That sounds tiny until you remember how many million requests Cloudflare serves per second.

The bug was killed within hours of the report. Scrubbing search engine caches took days longer, and the working assumption has to be that not every cached fragment was found.

Why this incident is so hard to reason about

Cloudbleed breaks the usual mental model of a breach in several ways:

• 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 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 is no query you can run to learn whether your users' sessions were among the leaked fragments. The honest answer is "unknowable."
• The data went everywhere and nowhere. Random visitors, crawler caches, whoever was watching. There's no evidence of deliberate exploitation so far — but with this leak, absence of evidence is close to meaningless.
• HTTPS didn't help. The leak happened after TLS termination, inside infrastructure you'd authorized to decrypt your traffic. The padlock was doing its job; the problem was behind it.

Lesson one — you inherit your CDN's bugs

When you put a CDN or WAF in front of your site, you hand 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 a fine trade — the performance and DDoS protection are real — but it means the CDN's parser bugs are now your parser bugs, and its blast radius is your blast radius.

Millions of sites route through a handful of edge networks. That concentration is efficient, and it's exactly why one buffer overrun turned into an internet-wide secret-leaking machine. The takeaway isn't "avoid CDNs" — it's "know your dependency." If you can't say from memory which providers terminate TLS for your domains, find out today:

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

Keep a plain list somewhere: every domain you own, and every third party that sits in the request path with the ability to read plaintext. When the next upstream incident lands — and there will be a next one — that list is the difference between a ten-minute assessment and a day of guessing.

Lesson two — rotate secrets after upstream incidents

Because exposure is unknowable, the only defensible response is to assume the worst for anything that transited the affected infrastructure during the window. If your site was behind Cloudflare with the HTML-rewriting features enabled — and even if you're merely unsure — rotate:

• Session tokens. Invalidate all active sessions and force re-login. It's an annoying email to send; it's a far less annoying email than the other kind.
• API keys and tokens. Anything your users or systems send in headers or bodies through the edge — bearer tokens, webhook secrets, integration keys.
• Cookies and their signing secrets. Rotating the application-side secret invalidates every outstanding cookie in one move.
• Passwords — encourage, don't necessarily force. Absent evidence of targeted exploitation, a forced global reset may be disproportionate; a clear recommendation plus support for two-factor authentication is a reasonable middle course. Make the call deliberately, and write down why.

The general principle outlives this incident: your secrets are only as private as every system that handles them, and "a system that handles them had a bug" should trigger rotation as a reflex, not a debate.

Lesson three — responding when the incident wasn't your fault

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

• Say something, even when your exposure is uncertain. A short, factual note — what happened upstream, what it could mean for your users, what you've rotated, what they should do — beats silence followed by a support-ticket avalanche.
• Track your providers' disclosures like you track 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; assign someone to actually read them.
• Rehearse the "upstream incident" playbook. Most incident plans assume the bug is yours. This one wasn't, and the teams that handled it well were the ones that already knew who decides on session invalidation and who drafts the user notice.

Shared infrastructure means shared fate

Cloudbleed's deepest lesson is that the modern web is a web of trust relationships you've mostly stopped noticing — and you can outsource the serving of your site, but never the accountability for it. Knowing your dependencies, watching them from the outside, and reacting fast when one of them stumbles is now simply part of running a website.

CompleteStatus exists for exactly that outside view — automated checks on your site's availability and SSL certificates from the public internet, the same vantage point your users (and everyone else) share, with alerts the moment something changes. See what's included on our features page, or create a free account and put your site — and the infrastructure it secretly depends on — under continuous watch.