Summary
This advisory addresses CVE-2026-87902, a Local File Inclusion vulnerability in WordPress Core. It affects various WordPress Core versions up to, and including, 7.1.1. Patches were released on September 22, 2026. Exploitation attempts have been recorded in the wild since September 23, 2026.
Affected and patched versions
WordPress (core wordpress): affected 6.6 up to (not including) 6.6.9, 6.7 up to (not including) 6.7.9, 6.8 up to (not including) 6.8.10, 6.9 up to (not including) 6.9.9, 7.0 up to (not including) 7.0.6, 7.1 up to (not including) 7.1.2, 4.7 up to (not including) 4.7.37, 4.8 up to (not including) 4.8.32, 4.9 up to (not including) 4.9.33, 5.0 up to (not including) 5.0.29, 5.1 up to (not including) 5.1.26, 5.2 up to (not including) 5.2.28, 5.3 up to (not including) 5.3.25, 5.4 up to (not including) 5.4.23, 5.5 up to (not including) 5.5.22, 5.6 up to (not including) 5.6.21, 5.7 up to (not including) 5.7.19, 5.8 up to (not including) 5.8.17, 5.9 up to (not including) 5.9.18, 6.0 up to (not including) 6.0.16, 6.1 up to (not including) 6.1.14, 6.2 up to (not including) 6.2.13, 6.3 up to (not including) 6.3.12, 6.4 up to (not including) 6.4.12, 6.5 up to (not including) 6.5.12; fixed in 4.7.37, 4.8.32, 4.9.33, 5.0.29, 5.1.26, 5.2.28, 5.3.25, 5.4.23, 5.5.22, 5.6.21, 5.7.19, 5.8.17, 5.9.18, 6.0.16, 6.1.14, 6.2.13, 6.3.12, 6.4.12, 6.5.12, 6.6.9, 6.7.9, 6.8.10, 6.9.9, 7.0.6, 7.1.2
Is my site vulnerable?
To determine if your WordPress site is vulnerable, check its installed version. You can find your WordPress version in the administration dashboard. Navigate to the "At a Glance" widget on the dashboard homepage, or visit the "Updates" page. Compare your site's version number against the list of affected versions.
Sites running WordPress Core versions 4.7 up to (not including) 4.7.37, 4.8 up to (not including) 4.8.32, 4.9 up to (not including) 4.9.33, 5.0 up to (not including) 5.0.29, 5.1 up to (not including) 5.1.26, 5.2 up to (not including) 5.2.28, 5.3 up to (not including) 5.3.25, 5.4 up to (not including) 5.4.23, 5.5 up to (not including) 5.5.22, 5.6 up to (not including) 5.6.21, 5.7 up to (not including) 5.7.19, 5.8 up to (not including) 5.8.17, 5.9 up to (not including) 5.9.18, 6.0 up to (not including) 6.0.16, 6.1 up to (not including) 6.1.14, 6.2 up to (not including) 6.2.13, 6.3 up to (not including) 6.3.12, 6.4 up to (not including) 6.4.12, 6.5 up to (not including) 6.5.12, 6.6 up to (not including) 6.6.9, 6.7 up to (not including) 6.7.9, 6.8 up to (not including) 6.8.10, 6.9 up to (not including) 6.9.9, 7.0 up to (not including) 7.0.6, and 7.1 up to (not including) 7.1.2 are vulnerable.
Sites running WordPress Core version 7.1.2 or later, or their respective branch's fixed release (e.g., 6.6.9, 6.7.9, 6.8.10, 6.9.9, 7.0.6), are not vulnerable to this specific issue.
What an attacker actually does
This vulnerability exists within the locate_template() function in WordPress Core. This function is responsible for resolving template names against the active theme directories. The issue arises because the function did not adequately verify that the resolved template path remained within the theme directories. An attacker can exploit this by supplying a template name containing directory traversal sequences, such as .., which allows the function to resolve to a readable PHP file located outside the intended theme directory structure.
The core-reachable vector for this vulnerability is the get_page_template() function. This function constructs a template name in the format page-{$pagename}.php. The {$pagename} part is derived from the URL-decoded 'pagename' query variable provided by a user. By manipulating this 'pagename' query variable, an unauthenticated attacker can inject path traversal sequences. This manipulation forces WordPress to include a chosen readable local .php file from the server, even if it is not part of the active theme.
Successful exploitation leading to remote code execution (RCE) requires two specific conditions to be met on the target server. First, the active parent or child theme must contain a top-level directory whose name begins with 'page-'. Examples of such directories include 'page-templates' found in themes like Twenty Twelve, Twenty Fourteen, Neve, Hestia, and Sydney. Second, there must be a readable .php file on the server that is accessible to the web server's account. A common target for this condition is pearcmd.php, especially when the PHP configuration register_argc_argv is enabled. This configuration is present in the official PHP Docker image and default cPanel setups on PHP versions prior to 8.5. When both conditions are met, an attacker can include pearcmd.php and execute arbitrary commands, gaining full control over the compromised system.
How to detect a compromise
Detecting a compromise related to CVE-2026-87902 involves examining server logs for suspicious activity and inspecting the file system for unauthorized modifications. Attackers exploiting this vulnerability often deploy web shells or write other malicious PHP files to gain persistent access and control over the compromised system.
Review your web server access logs (e.g., Apache access.log, Nginx access.log) for requests containing the pagename query variable with path traversal sequences (../). Look for requests targeting page- prefixed URLs that attempt to include files like pearcmd.php or other unusual .php files outside the standard WordPress directory structure.
Example log patterns to search for:
Requests to
/?pagename=page-templates/../../../../etc/passwd(though this would not lead to RCE, it indicates path traversal attempts).Requests to
/?pagename=page-templates/../../../../usr/share/pear/pearcmd.phpor similar paths targetingpearcmd.php.
Inspect your WordPress installation for newly created or modified PHP files in unexpected locations. Common locations for attackers to drop web shells or malicious scripts include:
wp-content/uploads/wp-content/themes/{your-theme-name}/(especially new files not part of the theme)wp-content/plugins/{plugin-name}/(new files)The root directory of your WordPress installation
Temporary directories (
/tmp/)
You can use command-line tools to search for recently modified files. For example, to find PHP files modified in the last 24 hours within your WordPress root directory: find /path/to/your/wordpress/root -name "*.php" -mtime -1
Look for suspicious code within PHP files, such as eval(), base64_decode(), system(), exec(), shell_exec(), passthru(), assert(), or create_function() used with obfuscated strings or unusual parameters. These functions are often used in web shells.
If you have WP-CLI installed, you can use wp core verify-checksums to check the integrity of WordPress core files. This command compares your core files against the official WordPress checksums and can help identify unauthorized modifications to core files. However, it will not detect malicious files placed in non-core directories like wp-content.
How to fix
To address this vulnerability, update your WordPress installation to a patched version.
Backup your site: Before performing any updates, create a full backup of your WordPress site's files and database.
Update WordPress Core: Update your WordPress installation to version 7.1.2 or the latest available patched release for your specific WordPress branch.
For example, if you are running WordPress 6.6, update to 6.6.9.
If you are running WordPress 7.0, update to 7.0.6.
If you are running WordPress 7.1, update to 7.1.2. You can initiate the update from your WordPress admin dashboard under "Dashboard" > "Updates", or manually update by downloading the latest version from wordpress.org and replacing the core files.
Verify the update: After updating, confirm that your WordPress version reflects the patched release in your admin dashboard.
Scan for compromise: If you suspect a compromise occurred before updating, perform a thorough security scan of your site and server. Remove any detected web shells, malicious files, or unauthorized changes.
Timeline
Date | Event |
|---|---|
2026-09-22 | NVD Publication |
2026-09-22 | Security updates released |
2026-09-22 | Initial exploitation attempts |
2026-09-22 | Exploitation attempts began |
2026-09-22 | Patches released |
2026-09-22 | First exploitation attempt observed |
2026-09-22 | First file write attempt |
2026-09-23 | Exploitation attempts recorded |
2026-09-23 | Public scanning tooling in circulation |
2026-09-25 | Added to CISA KEV catalog |
2026-09-27 | Peak requests |
2026-09-28 | NVD Last Modified |
2026-09-28 | CISA KEV remediation deadline |