I think you're right that most likely it's not as bad as it seems. And I admit to reading the "news" about it and posting here before having finished reading the incident report itself, so I missed the part that specifically laid out the requirements for the memory leak. I've adjusted the title of the topic and the content of the original post to be less alarming.
Also visit the blog for more information: https://blog.cloudfl...oudflare-parser-bug/
That's what I linked to in my original post. But thanks for the link to the Google report. I had a hard time finding it myself.
I think that people are trying to make this something that it's not.
We quickly identified the problem and turned off three minor Cloudflare features (email obfuscation, Server-side Excludes and Automatic HTTPS Rewrites) that were all using the same HTML parser chain that was causing the leakage. At that point it was no longer possible for memory to be returned in an HTTP response.
So if you're not using those features, your site was not going through the bad code.
That seems to be the case, but I think it's not entirely accurate:
Because Cloudflare operates a large, shared infrastructure an HTTP request to a Cloudflare web site that was vulnerable to this problem could reveal information about an unrelated other Cloudflare site.
So even if your site doesn't use Cloudflare directly, if it made a request to a site or service that does, then sensitive information from your site could have been leaked.
Also, from the Google report, this is worrisome:
Cloudflare did finally send me a draft [of their incident report]. It contains an excellent postmortem, but severely downplays the risk to customers.
So when I see something like this:
(that’s about 0.00003% of requests)
I have to think that a percentage means nothing to me without knowing how many total requests there were. For an exaggerated example, 0.00003% of 38 quintillion is still quite a lot.