Black Hat Presentation – Web Cache Entanglement


Akamai is aware of the ‘Web Cache Entanglement: Novel Pathways to Poisoning‘ presentation at BlackHat on August 5, 2020. Two security vulnerabilities related to our content delivery networks’ caching functionality were presented as part of this research. Akamai would like to thank James Kettle for disclosing this vulnerability to Akamai in advance of his presentation.

Web cache attacks, in any form including cache poisoning or deception, can be triggered against any web cache (either CDN or centralized caching proxy) where the origin and cache disagree about cacheability. These attack types potentially allow an attacker to influence the content served by the cache. This research discloses two separate, related vulnerabilities, each of which has been or is being mitigated by our technical teams.  

Technical Details

The Akamai content delivery network uses unique identifiers called “Cache Keys” when adding or retrieving content in Akamai’s cache. The two security vulnerabilities are related to the way these keys are generated and used. 

Vulnerability 1: Transform Cache Poisoning 

Certain Akamai products manipulate the cache key to indicate content has been transformed; for example, when using Front End Optimization (FEO) or injecting JavaScript for our mPulse product. An adversary could craft a request that could interfere with product function by manipulating these keys.

This vulnerability allows creating a cache key collision related to content generated and cached automatically as part of Akamai product features. This creates a method to interfere with the proper functioning of caching services but does not allow control of content served by attackers. Mitigation for this attack has been deployed, and no customer action is required to enable protections.

Vulnerability 2: Flexible Cache Key Collisions

Akamai uses flexible cache keys as a feature to give customers the ability to cache multiple objects under a single base path by making changes in their configurations. These values are concatenated into a string that is used to reference the full cache key for the object.  These features are used by a subset of Akamai customers, and this vulnerability does not apply to the majority of Akamai customers.

This vulnerability was introduced due to a character encoding issue that happens when the string is generated.  This issue allows an attacker to trick an Akamai server into caching two different requests to the origin under the same cache key.  

This vulnerability only applies to a subset of objects cached with a flexible cache key. The practical impact of this vulnerability is directly related to the behavior at the origin servers. The vulnerability can increase the severity of some attacks, such as Reflected XSS and other attacks that rely on responses based on input without sanitization. Alternatively, the vulnerability could be used to pollute the cache, making the site unstable and unusable for visitors. 

Akamai is in the process of carefully orchestrating an update to mitigate this second vulnerability. The mitigation for this vulnerability changes the way these keys are generated to prevent an attacker from “forging” a cache key via a specially crafted request. This change will force some requests to go forward to origin and repopulate the cache using the new cache key format over time. Akamai anticipates these changes will have minimal impact on most customers but is monitoring the effect of changes closely.


No action is needed by Akamai customers in response to the transform cache poisoning vulnerability. The change to address the flexible cache key collision vulnerability is currently being deployed, and no action by customers is necessary. For more information on both issues, please contact your customer service representative.

Akamai is committed to making continuous improvements to make our systems more resilient and secure.  We would like to once again thank James Kettle for his effort to make us aware of these vulnerabilities and an opportunity to fix them before his public presentation.

*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Akamai InfoSec. Read the original post at: