CVE-2026-111464 in WP Fastest Cache Plugin
Summary
by MITRE • 11/03/2026
The WP Fastest Cache plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.5.3. The plugin caches the response of Core’s wp-activate.php without honoring its no-store/no-cache headers, the wp-activate-* cookie, or the WP_INSTALLING state, writing the credential-bearing activation response to a publicly accessible cache file. This makes it possible for unauthenticated attackers to retrieve the plaintext username and twelve-character password of the most recently activated Multisite registrant from that cached wp-activate.php response. Exploitation requires a Multisite subdirectory installation with public user and site registration enabled, and the credentials are only exposed after a genuine registrant follows their activation link.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in WP Fastest Cache versions up to 1.5.3 represents a critical failure in handling sensitive authentication data within WordPress Multisite environments. This flaw stems from an improper caching mechanism that disregards standard HTTP security directives and application-level state indicators. Specifically, the plugin caches the response generated by the core wp-activate.php script without respecting no-store or no-cache headers, ignoring the presence of specific session cookies such as wp-activate-, and failing to check for the WP_INSTALLING constant which indicates an active installation process. This technical oversight results in the storage of credential-bearing responses into publicly accessible cache files on the web server.
From a technical perspective, this constitutes a classic case of sensitive information exposure due to improper caching policies. The vulnerability allows unauthenticated attackers to retrieve plaintext usernames and twelve-character passwords associated with the most recently activated Multisite registrant from that cached file. The exploitation does not require any form of authentication or complex attack vectors; it merely requires access to the web server's public directory where cache files are stored. This significantly lowers the barrier for entry, enabling even novice attackers to compromise user accounts by simply querying known cache paths associated with recent activation events.
The operational impact of this vulnerability is severe within WordPress Multisite subdirectory installations that have both public user and site registration enabled. Once a legitimate registrant follows their activation link, their credentials are immediately written to the cache in plaintext. Attackers can exploit this by monitoring for new activations or guessing common patterns to locate these cached files. The exposure of usernames and passwords facilitates unauthorized access to administrative accounts, potentially leading further into privilege escalation attacks where an attacker gains control over the entire Multisite network. This compromises not only individual user data but also the integrity and availability of all sites hosted within that multisite installation.
This vulnerability aligns with CWE-209, which describes exposure of sensitive information via error messages or other unintended channels, as well as CWE-524 regarding use of cache containing sensitive information. In terms of offensive security frameworks like MITRE ATT&CK, this behavior maps to T1530 Data from Local System Repositories and potentially T1078 Valid Accounts if the retrieved credentials are used for further lateral movement or persistence within the environment. The lack of proper sanitization and cache control mechanisms highlights a significant gap in how third-party plugins handle sensitive operational data during user registration workflows.
Mitigation strategies must focus on immediate remediation through software updates and configuration adjustments. Administrators should update WP Fastest Cache to version 1.5.4 or later, where the developers have addressed this caching flaw by ensuring that activation responses are not cached publicly. In cases where updating is not immediately feasible, administrators can disable public user registration temporarily until the patch is applied. Additionally, implementing strict file permissions on cache directories and configuring web servers like Nginx or Apache to deny direct access to cache folders can provide a layer of defense in depth. Regular auditing of plugin configurations against security best practices for caching sensitive data is also recommended to prevent similar exposures in other components.