Multi-CloudIncident TeardownsRetrospectives

Cloudbleed (Feb 2017): When Your CDN Leaks Your Customers' Session Tokens

By OnCloudSec Research Team · Published Oct 6, 2026 · 1 min read

Retrospective: this article looks back at events from February 2017, written in 2026 with the benefit of hindsight.

In February 2017, Google Project Zero researcher Tavis Ormandy noticed something strange in search results: fragments of private data from websites that used Cloudflare. The bug became known as Cloudbleed.

What happened

A flaw in an HTML parser used by some Cloudflare features caused its edge servers to read past the end of a memory buffer. When certain conditions were met, responses included chunks of memory belonging to other customers' traffic — HTTP headers, cookies, authentication tokens and POST data.

Some of that leaked data was cached by search engines. Cloudflare worked with search providers to purge it. The bug had been triggerable since September 2016, with the greatest impact in the days before it was fixed, and the leak affected only a very small fraction of requests — but at Cloudflare's scale that still meant many sites.

Why it mattered

Customers had done nothing wrong. Their sessions and tokens were exposed because of a bug in a provider sitting in front of their applications. It was a clear example of how much trust organizations place in content delivery networks and reverse proxies, which see every request in plain text.

Lessons for cloud teams

  • Treat edge providers as part of your attack surface. They terminate TLS and see sensitive data.
  • Have a plan to rotate secrets fast. When a provider leaks session tokens, the safe response is to invalidate sessions and rotate keys.
  • Short-lived tokens limit damage. Sessions that expire quickly are less valuable when leaked.
  • Watch provider security advisories and know who in your team reads them.

In hindsight

Cloudbleed was handled with unusual transparency, and Cloudflare's detailed post-mortem became a model for incident disclosure. The lesson for customers is still relevant: you cannot prevent a provider's bug, but you can decide in advance how quickly you can reset everything that bug might have exposed.

cloudbleed2017

More on this story