Cloudbleed: what happened and what you should know

In February 2017, a security researcher at Google’s Project Zero discovered that Cloudflare, one of the world’s largest content delivery networks, had been leaking sensitive data from its customers’ websites for months. The vulnerability became known as Cloudbleed, a name that echoed the earlier Heartbleed OpenSSL bug. If your site used Cloudflare at the time, or if you had accounts on sites that did, this affected you.

This post covers what Cloudbleed was, how it worked, what data was exposed and what steps were worth taking in response.

What Cloudbleed actually was

Cloudflare sits between millions of websites and their visitors, handling traffic, caching content and providing DDoS protection. To do this, it processes web pages on its own servers before passing them on to users. Cloudbleed was a bug in that processing layer.

The vulnerability was caused by a buffer overrun in Cloudflare’s HTML parser. A buffer overrun occurs when a programme reads or writes data beyond the boundaries of an allocated memory block. In this case, Cloudflare’s servers were reading past the end of a buffer and including random chunks of memory in the HTTP responses sent to visitors. That memory could contain data from entirely different websites also being processed on the same server.

The result was that fragments of private data, including passwords, session tokens, cookies and personal information, were being served up in web page responses. Some of that data was also cached by search engines, meaning it remained publicly accessible even after Cloudflare patched the bug.

How long was data leaking?

Cloudflare’s own investigation found that the bug had been present since 22 September 2016. The researcher who discovered it, Tavis Ormandy, reported it to Cloudflare on 17 February 2017. Cloudflare patched the most serious version of the bug within hours of being notified, and had fully resolved the issue within days.

That means data was potentially leaking for roughly five months. Cloudflare estimated that the leak was triggered on approximately 1 in every 3.3 million HTTP requests, which sounds low until you consider the scale of traffic the company handles. The volume of potentially exposed data was significant.

What type of data was exposed

Because the leaked memory was random, there was no single category of data at risk. Researchers who examined cached search engine results found a range of content in the leaked fragments, including:

• Authentication cookies and session tokens
• Passwords submitted through web forms
• Private messages and chat logs
• API keys and OAuth tokens
• Personal information including names and email addresses

The exposure was not targeted. Attackers could not choose which data to retrieve. But the fact that some of this data ended up in search engine caches meant it was accessible to anyone who knew where to look, not just to someone actively exploiting the bug in real time.

Which sites were affected

Any website using Cloudflare’s proxy service during the affected period was potentially involved. Cloudflare serves a large portion of the web, so the list of affected services was long. Password manager services, major consumer apps and high-traffic platforms were all named in early reports.

Cloudflare published a list of domains using its service, though the company was careful to note that being on the list did not confirm that a specific site had leaked data. The bug affected a small fraction of requests, so many sites on the network may have had no data exposed at all.

What to do if you were affected

At the time of the disclosure, the recommended response was to change passwords on any service that used Cloudflare, particularly where the same password was reused across multiple accounts. Session tokens and cookies were invalidated by most affected services as part of their response, but passwords set before the patch remained a risk until changed.

For site owners using Cloudflare, the practical steps were to rotate any API keys or secrets that had passed through Cloudflare’s network, and to review whether any sensitive data was being transmitted in a way that could have been captured. Cloudflare’s patch addressed the root cause, so no changes to Cloudflare configuration were required on the customer side.

The broader lesson from Cloudbleed is one that applies to any infrastructure vulnerability: the services sitting between your users and your application can introduce risks that are entirely outside your control. Keeping credentials unique across services and rotating them after any significant disclosure limits the damage when something like this happens.

Cloudbleed was a reminder that security vulnerabilities do not always originate on your own server. Third-party infrastructure, however reliable, carries its own risk profile. Staying informed when disclosures happen, and acting on them promptly, is part of running a site responsibly. For more on keeping your web presence secure, take a look at our website security guidance or explore our secure hosting options.

If you have questions about how your hosting setup handles security, the UWH team is available via the contact page.