Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

I don't mean they are learning from observing attack traffic, they have access to the command and control traffic.

That means they could know about an attack before it happens.

They could know how long it will last, who the target will be, and what volume of traffic to expect.

They could know who had ordered it, who had paid for it.

They. Also. Sell. Protection.

To call the situation deeply conflicting is an understatement.

> This is what CloudBleed looks like

Ironically, gfycat seems down now.

But - I can't think of a single language in which using it "wrong" might not lead to info leaks? Any language with a runtime has to manage memory somehow at the runtime layer and so similar leaks can occur there depending upon design and implementation, and the wider OS context.

At the whole program/application level, when you create your own data structures, you can find lots of ways to leak them to the world.

I didn't keep details, sorry. It was late (UK time) and I was attempting to get my own response out the door.

I saw three domains directly myself with compromised details:

android-cdn-api.fitbit.com

iphone-cdn-client.fitbit.com

api-v2launch.trakt.tv

I saw data relating to Discord whilst on various cached pages when I was looking at the above domains.

The pages are no longer available in Google's cache so I can't link to them.

Some cached pages had data from multiple sites all together, it was a mess.

Just got an email:

Dear Cloudflare Customer:

Thursday afternoon, we published a blog post describing a memory leak caused by a serious bug that impacted Cloudflare's systems. If you haven't yet, I encourage you to read that post on the bug:

https://blog.cloudflare.com/incident-report-on-memory-leak-c...

While we resolved the bug within hours of it being reported to us, there was an ongoing risk that some of our customers' sensitive information could 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 ability of malicious individuals to exploit any exposed data.

In our review of these third party caches, we discovered data that had been exposed from approximately 150 of Cloudflare's customers across our Free, Pro, Business, and Enterprise plans. We have reached out to these customers directly to provide them with a copy of the data that was exposed, help them understand its impact, and help them mitigate that impact.

Fortunately, your domain is not one of the domains where we have discovered exposed data in any third party caches. The bug has been patched so it is no longer leaking data. However, we continue to work with these caches to review their records and help them purge any exposed data we find. If we discover any data leaked about your domains during this search, we will reach out to you directly and provide you full details of what we have found.

To date, we have yet to find any instance of the bug being exploited, but we recommend if you are concerned that 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.

Again, if we discover new information that impacts you, we will reach out to you directly. In the meantime, if you have any questions or concerns, please don’t hesitate to reach out.

Matthew Prince Cloudflare, Inc. Co-founder and CEO