Update 2 (March 1st)
Our customers are what matter most to us. Thank you for the time and effort many of your teams spent analyzing your risk exposure and your own communications plans, internally and with your customers. In an effort to continue to be transparent for our customers’ benefit, we want to share our findings along the way.
Last Thursday February 23rd we released information about the Cloudflare parser bug that resulted in data flowing through Cloudflare's network getting leaked onto the Internet. Over the past several days, we have spoken with many of you, and we have clearly heard your concern about the uncertainty surrounding this bug.
We have continued our investigation into this bug non-stop since its discovery, and today we have released the results of our analysis so far. We encourage you and your technical teams to read the results of our research here: https://blog.cloudflare.com/quantifying-the-impact-of-cloudbleed/
The summary is that, while the bug was very bad and had the potential to be much worse, based on our analysis so far:
- We have found no evidence based on our logs that the bug was maliciously exploited before it was patched.
- The vast majority of Cloudflare customers had no data leaked.
- After a review of tens of thousands of pages of leaked data from search engine caches, we have found a large number of instances of leaked internal Cloudflare headers and customer cookies, but we have not found any instances of passwords, credit card numbers, or health records.
- Our review is ongoing.
We continue to have teams on standby here to help. For any open questions, please email email@example.com and we will address your questions to the best of our ability.
On February 23, 2017, Cloudflare CTO John Graham-Cumming published a blog post describing a memory leak caused by a serious bug that impacted Cloudflare's systems. Please read the blog post here for full details:
While we fully resolved the bug within hours of it being reported to us, there was an ongoing risk that some of our customers' sensitive information would still be available through third party caches, such as the Google search cache.
Over the last week, we've worked with these caches to discover what customers may have had sensitive information exposed and ensure that the caches are purged. We waited to disclose the bug publicly until after these caches could be cleared in order to mitigate the potential impact and ability of malicious individuals to exploit any leaked data.
While we have yet to discover any instance of the bug being exploited, we recommend you invalidate and reissue any persistent secrets, such as long lived session identifiers, tokens or keys. Due to the nature of the bug, customer SSL keys were not exposed and do not need to be rotated.
Thanks for your understanding and we apologize for any inconvenience caused by this bug.