Originally published at https://tekmag.thsite.top/cve-2026-87902-wordpress-path-traversal-under-active-exploit-after-712-patch/
CVE-2026-87902 is a critical unauthenticated path traversal vulnerability in WordPress core that lets an attacker read any readable file on the server and, under two preconditions, execute code as the web user. The fix shipped in WordPress 7.1.2 on September 22, 2026 and was backported to 24 older branches, but attackers began probing sites within hours of the advisory.
I verified the timeline and version range directly against the official WordPress 7.1.2 release announcement and cross-checked the exploitation data with Patchstack's operational analysis of the attack traffic. The numbers hold up: first probes at 17:44 UTC on September 22, a CVSS v4.0 score of 9.2, and 25 backported releases in the fix.
Key Takeaways
- WordPress 7.1.2, released September 22, 2026, patches CVE-2026-87902, an unauthenticated path traversal in page template resolution affecting every version from 4.7.0 to 7.1.1, with fixes backported to 24 older branches.
- The bug is a CVSS 9.2 critical: any readable file on the server can be included without authentication, and remote code execution is possible when the site pairs a theme with a
page-*directory with a PEAR install. - According to Patchstack, active exploitation started at 17:44 UTC on September 22, traffic volume jumped more than 10x by September 23, and public Nuclei scanning templates put the flaw in the hands of anyone by September 24.
- Updating is the only complete fix. Firewall rules are a stopgap, and Wordfence's free firewall rule is not scheduled to deploy until October 22, 2026.
What Is CVE-2026-87902, and How Does It Work?
The flaw sits in get_page_template(), the function in wp-includes/template.php that decides which template file renders a page. A neighboring code path guards its input against path traversal with validate_file(); the pagename branch did not. An attacker sends a double-encoded sequence, %252e%252e%252f, which decodes to ../. That encoding survives WordPress's URL sanitizer, which strips literal dots but preserves percent-encoded octets, so the include can escape the theme directory and point at any readable .php file on the server.
The fix in 7.1.2 works on two layers. The decoded pagename branch now runs validate_file() before a candidate is added, and a new _wp_is_template_path_allowed() function requires every resolved template to live inside the theme's stylesheet, template, or theme-compat directory. That second layer treats this as a class of problem instead of one hole.
The full technical breakdown, including the RCE preconditions, is in the GitHub security advisory describing how page template resolution leads to conditional remote code execution.
Which WordPress Versions Are Affected, and What Should You Update To?
Every release from 4.7.0 through 7.1.1 is vulnerable. The September 22 security release patched the current branch at 7.1.2 and backported the same fix to 24 older branches, from 7.0.6 down to 4.7.37, for a total of 25 backported releases.
After updating, your dashboard's Updates screen should read "You are running the latest version," or you can confirm $wp_version in wp-includes/version.php. Sites with automatic background updates enabled handled this on their own. Versions older than 4.7.0 are not eligible for a backport and must move to a supported branch.
Wordfence's public service advisory confirms the complete patch matrix and the firewall coverage timeline, and Help Net Security's summary of the 7.1.2 release walks through the 25-branch backport list and the get_page_template flaw.
What Turns a File Read Into Remote Code Execution?
Remote code execution is not guaranteed for every installation. Two conditions must hold at the same time: the active theme or its parent must have a top-level directory whose name starts with page-, and the server must run with register_argc_argv set to On in the web SAPI while keeping a readable pearcmd.php on disk. The advisory lists Twenty Twelve, Twenty Fourteen, Neve, Hestia, and Sydney as themes with the relevant layout. The current default themes, Twenty Twenty-Three through Twenty-Five, have no page-* directory, which blocks the RCE path on modern installs, but the local file inclusion still works on any vulnerable version regardless of theme.
The vulnerability is a critical local file inclusion on its own; remote code execution requires a theme layout and a PEAR installation working against the attacker.
On the server side, the official PHP Docker image ships with register_argc_argv On by default, and cPanel's default configuration on PHP versions before 8.5 is affected. When you check, test the web SAPI through PHP-FPM, not the CLI, which always reports the setting as On.
How Has the Active Exploitation Unfolded?
According to Patchstack, the first probes hit at 17:44 UTC on September 22, the same day as the release, and the first write attempt through pearcmd.php arrived at 15:34 UTC on September 23. The operation moved in three observed stages: reconnaissance probes against harmless core files, a pearcmd.php check with a config-show argument to confirm PEAR and register_argc_argv were usable, and finally a swap to config-create to write attacker-controlled PHP to disk.
By September 23, attack traffic was already running more than 10 times the first-evening volume, public Nuclei scanning templates were circulating, and BleepingComputer reported the specific payload filenames the attackers dropped, including wp-pear-rce-flag.php, poc87902.php, and luci_.php, written into /tmp and /var/tmp. Some payloads were just markers; others executed shell commands.
By September 24, the source set had spread from a small cluster to hundreds of IP addresses, a pace SecurityWeek documented in its report on the immediate exploitation of the flaw. No CISA KEV entry had been published for the CVE as of that date. Attackers moved just as fast on the Ray flaw CISA flagged for active exploitation last month, and both went from advisory to in-the-wild attack within days.
How Can Site Owners Protect Themselves Right Now?
Updating is the only complete fix. The dashboard's Updates screen, a single wp core update on WP-CLI, or automatic background updates all do it. If you cannot update today, the interim steps below buy time, not a cure.
Block the traversal sequences at the firewall level: a real page slug never contains .., so deny any pagename carrying %252e, %252f, or a decoded ../. Turn register_argc_argv Off in the web SAPI's php.ini and remove or deny access to pearcmd.php if it is present. Check your theme's top-level directories for a page-* layout, and search your access logs for double-encoded pagename values and config-show or config-create arguments.
On firewall products, Wordfence's PSA notes that its premium firewall rule deployed on September 22 while the free rule is delayed to October 22 under the standard 30-day cycle. Patchstack RapidMitigate and Imunify360 both shipped coverage on September 22 as well.
Firewall rules are a bypassable stopgap; the update is the fix, and on the free Wordfence tier the protection gap runs until October 22.
The same update discipline we saw in Microsoft's record September Patch Tuesday release applies to WordPress core, where the patch matrix still reaches back to the 4.7.x branch and thousands of sites run those old versions in production.
Conclusion
CVE-2026-87902 shows how fast an unauthenticated WordPress core flaw moves from advisory to in-the-wild RCE campaign: probes within hours of release, more than 10x traffic the next day, public scanning tools, and hundreds of source IPs by day two. Update to 7.1.2, or the matching backport for your branch, now; everything else is a delay, not a fix.
CVE-2026-87902 is the clearest signal yet that the long tail of older WordPress versions, from 4.7.0 to 7.1.1, is where modern attacks concentrate.
Already updated? Tell us in the comments whether you found probing attempts in your logs, and drop anything the mitigation list missed below.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"question": "What is the WordPress 7.1.2 security release?",
"answer": "Released on September 22, 2026, it fixes CVE-2026-87902, a critical unauthenticated path traversal in page template resolution (CVSS 9.2). The fix was backported to 24 older branches, from 7.0.6 down to 4.7.37."
},
{
"question": "Do I need a specific theme to be at risk of code execution?",
"answer": "No theme is needed for the local file inclusion, which works on any site running 4.7.0 to 7.1.1. Remote code execution additionally requires a theme with a top-level page-* directory (such as Twenty Twelve, Neve, Hestia, or Sydney) and a server with register_argc_argv On plus a readable pearcmd.php."
},
{
"question": "How do I confirm my site is patched?",
"answer": "The dashboard Updates screen should show \"You are running the latest version.\" You can also check $wp_version in wp-includes/version.php or run wp core version on WP-CLI. Sites with automatic background updates enabled should have updated on their own."
},
{
"question": "Is a WAF rule enough, or do I still have to update WordPress?",
"answer": "WAF rules are a bypassable stopgap, not a substitute. Updating is the only complete mitigation. Note that Wordfence's free firewall rule is not scheduled until October 22, 2026, so free-tier sites on WAF-only protection have a month-long gap."
},
{
"question": "What should I look for in my logs after an attack?",
"answer": "Search for double-encoded pagename values containing %252e, references to pearcmd, and config-show or config-create arguments. Attackers have also dropped marker files with names like wp-pear-rce-flag.php and poc87902.php into /tmp and /var/tmp."
}
]
}
Frequently asked questions
What is the WordPress 7.1.2 security release?
Released on September 22, 2026, it fixes CVE-2026-87902, a critical unauthenticated path traversal in page template resolution (CVSS 9.2). The fix was backported to 24 older branches, from 7.0.6 down to 4.7.37.
Do I need a specific theme to be at risk of code execution?
No theme is needed for the local file inclusion, which works on any site running 4.7.0 to 7.1.1. Remote code execution additionally requires a theme with a top-level page-* directory (such as Twenty Twelve, Neve, Hestia, or Sydney) and a server with register_argc_argv On plus a readable pearcmd.php.
How do I confirm my site is patched?
The dashboard Updates screen should show "You are running the latest version." You can also check $wp_version in wp-includes/version.php or run wp core version on WP-CLI. Sites with automatic background updates enabled should have updated on their own.
Is a WAF rule enough, or do I still have to update WordPress?
WAF rules are a bypassable stopgap, not a substitute. Updating is the only complete mitigation. Note that Wordfence's free firewall rule is not scheduled until October 22, 2026, so free-tier sites on WAF-only protection have a month-long gap.
What should I look for in my logs after an attack?
Search for double-encoded pagename values containing %252e, references to pearcmd, and config-show or config-create arguments. Attackers have also dropped marker files with names like wp-pear-rce-flag.php and poc87902.php into /tmp and /var/tmp.
References
- WordPress 7.1.2 Release (official announcement by John Blackbourn, September 22, 2026)
- GitHub Security Advisory GHSA-7hp8-65ch-5whp: unauthenticated path traversal in page template resolution
- Wordfence PSA (September 22, 2026)
- Patchstack: Attackers Started Probing WordPress Sites Hours After the Patch (September 22, updated September 23, 2026)
- Help Net Security: WordPress 7.1.2 fixes critical unauthenticated path traversal vulnerability (September 23, 2026)
- SecurityWeek: Critical WordPress Vulnerability Exploited Immediately After Disclosure (September 24, 2026)
- BleepingComputer: Hackers Start Exploiting Critical WordPress Flaw for Code Execution (September 24, 2026)
Top comments (0)