
A few days ago, Cloudflare — along with the rest of the world — learned of a "practical" cache poisoning attack. In this post I’ll walk through the attack and explain how Cloudflare mitigated it for our customers. While any web cache is vulnerable to this attack, Cloudflare is uniquely able to take proactive steps to defend millions of customers.
In addition to the steps we’ve taken, we strongly recommend that customers update their origin web servers to mitigate vulnerabilities. Some popular vendors have applied patches that can be installed right away, including Drupal, Symfony, and Zend.
How a shared web cache works
Say a user requests a cacheable file, index.html
. We first check if it’s in cache, and if it’s not not, we fetch it from the origin and store it. Subsequent users can request that file from our cache until it expires or gets evicted.
Although contents of a response can vary slightly between requests, customers may want to cache a single version of the file to improve performance:

(See this support page for more info about how to cache HTML with Cloudflare.)
How do we know it’s the same file? We create something Continue reading