Web Cache Poisoning DoS through HTTP/2 headers
Description
This vulnerability occurs when a web caching system incorrectly caches HTTP error responses (such as 400 Bad Request) triggered by malformed HTTP/2 headers. An attacker can exploit this by sending specially crafted requests with invalid HTTP/2 headers to legitimate resources. When the cache stores the resulting error response, all subsequent users requesting that resource receive the cached error instead of the actual content, effectively denying access to the resource.
Remediation
Configure the caching layer to exclude error responses from being cached. Specifically:
1. Ensure that HTTP responses with 4xx and 5xx status codes are not cached by setting appropriate cache control directives
2. For reverse proxies like Nginx, Varnish, or Apache, configure cache rules to only cache successful responses (2xx and 3xx status codes)
3. Implement strict HTTP/2 header validation at the edge or application layer to reject malformed requests before they reach the application
4. Set cache control headers on error responses to prevent caching:
Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Expires: 0
5. Review and test cache configuration to verify that error responses are not stored, particularly when triggered by malformed HTTP/2 headers
6. Consider implementing request validation middleware that normalizes or rejects invalid HTTP/2 headers before processing