Cloudflare Incident #Cloudbleed

Exactly one week ago I noticed an “urgent” tweet from Tavis Ormandy to get in contact with the Cloudflare team.
Normally when a tweet like this appears from Tavis, something is horribly broken. Well, today we know the background of this tweet as the bug tracker issue went public and it exposed quite a bug from Cloudflare.

While there is some background story how Tavis found the bug, because he wasn´t actively looking into the Cloudflare infrastructure and it was rather discovered by accident when odd data appeared in his fuzzing corpus. When he looked closely he found data that was not in any mean related to the expected data from various websites.

Turned out he found sensitive data from other websites in his fuzzing corpus. The extracted data were blacked out in the published post but part of the Uber request is still visible:


Later they also found several other examples of the Cloudflare leak within the Google crawl engine:



It took him and the Google Project Zero team a while to figure out from where the data appeared and why they got access to them.
Details can be either found in the Google Bug Tracker or at the official Cloudflare statement.

I collected all the current available information (statement from Cloudflare and the description of the bug from Tavis) and put them into a list.

Since the webpage behind Cloudflare had to actively use Cloudflare features (such as e-mail obfuscation or server-side excludes) the amount of leaked data could be quite low. According to Cloudflare only 1 out of 3,300,000 HTTP requests contained leaked data from memory, and in total in contrast to the amount of requests to webpages behind Cloudflare only 0.00003% contained sensitive data.

  • According to Cloudflare the server had the biggest impact for exactly 6 days (Feb 13th – Feb 18th) and leaked sensitive data.
  • According to Cloudflare their server had this vulnerability since the beginning but it could not be exploited.
  • According to Cloudflare the possibility to exploit this vulnerability started about a year ago when they issued a change.
  • For these 6 days any request or response that was issued to a website/service behind the Cloudflare infrastructure could potentially been leaked to either a search engine or any other user.
  • Lots of sensitive data may still be cached by either a search engine/crawler or normal internet user
  • The leaked data could contain sessions, sensitive passwords, tokens or even sensitive informations such as produced by dating portals
  • According to Cloudflare only 1 out of 3,300,000 HTTP requests contained leaked data from memory (0.00003% of total requests)

Even though the numbers appear quite low there is no information available if someone actively exploited this vulnerability, hence it might be a good idea to check if services behind the Cloudflare infrastructure (for example 1Password, Cisco or Uber and many more) were used and change your passwords/secrets there.

If it is not certain that a website uses the Cloudflare proxy you can either check it with the following command or requesting the DNS entry on this website: dnswatch.info

$ nslookup -q=any 1password.com

Non-authoritative answer:
1password.com nameserver = jocelyn.ns.cloudflare.com.
1password.com nameserver = zod.ns.cloudflare.com.

To be safe check if you used any service in the past that’s behind the Cloudflare proxy and, depending on your threat perception and your risk appetite ;-), consider changing everything you need to change there.