Description

The WP Fastest Cache WordPress plugin before 1.5.1 does not validate the Host header before using it to build the URLs of the asset files it embeds in the pages it caches, and does not include that header in the cache key, allowing unauthenticated attackers to poison cached pages with references to a server they control and have arbitrary JavaScript run for every subsequent visitor.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-25T20:17:03.250Z",
  "pubdate": "2026-08-25T20:17:03.250Z",
  "executiveSummary": "The WP Fastest Cache plugin, in versions prior to 1.5.1, is susceptible to a Host Header Injection vulnerability that facilitates Web Cache Poisoning.\nThis vulnerability arises from the insecure handling of the HTTP Host header, which is utilized by the plugin to dynamically construct URLs for static assets within cached web pages.\nThe core issue is twofold: the plugin fails to validate the integrity of the Host header before processing it, and it neglects to include the Host header in the cache key generation process.\nThis combination allows an unauthenticated remote attacker to manipulate the cache storage by submitting crafted HTTP requests containing a malicious Host header.\nSuccessful exploitation results in the injection of attacker-controlled references into the cached HTML, enabling the execution of arbitrary JavaScript in the browsers of subsequent visitors.\nThe risk is critical, as it compromises the integrity of the served content, bypasses security controls, and facilitates widespread cross-site scripting (XSS) across the site's user base without requiring administrative privileges or interaction beyond visiting the poisoned page.",
  "technicalDetails": "The vulnerability is rooted in the improper implementation of URL generation logic for cached assets within the WP Fastest Cache plugin. When a user requests a page, the plugin identifies static assets such as CSS or JavaScript files and constructs their URLs based on the incoming HTTP Host header provided by the client request.\nThe primary failure occurs because the plugin assumes the Host header is trustworthy and fails to perform validation against an allowlist of authorized domains. Furthermore, the caching mechanism fails to incorporate the Host header into the unique cache key identifier. Consequently, if an attacker sends a request with a manipulated Host header (e.g., 'attacker.com'), the plugin generates a cached version of the page where asset URLs are rewritten to point to 'attacker.com/path/to/script.js'.\nBecause the Host header is excluded from the cache key, this poisoned version of the page is saved in the server's cache and is subsequently served to all legitimate users who request that specific URL, regardless of their actual Host header.\nThe attack flow is as follows: 1. The attacker sends a crafted HTTP GET request to the target server, injecting a malicious hostname into the Host header. 2. The WP Fastest Cache plugin processes this request, builds asset URLs using the malicious hostname, and stores the resulting HTML in the cache. 3. The server serves this poisoned cached page to any subsequent legitimate visitor. 4. When the visitor's browser parses the HTML, it attempts to load static assets from the attacker-controlled server. 5. The attacker's server delivers malicious JavaScript, which executes within the context of the victim's session on the legitimate site, leading to potential session hijacking, data theft, or further client-side exploitation.\nThis vulnerability is classified as an unauthenticated attack, meaning no prior access or privileges are required. It is exposed over the network via standard HTTP/HTTPS channels. The impact is significant, as it transforms the server-side cache into a vector for persistent, widespread XSS attacks, effectively bypassing standard Content Security Policy (CSP) protections that might otherwise be configured on the legitimate domain.\nAffected versions are strictly limited to those identified before 1.5.1. The vulnerability persists until the plugin is updated to a version that enforces strict Host header validation and includes the Host header within the cache key generation logic to ensure that cached content is properly partitioned."
}