WordPress CVE-2026-87902: an unauthenticated path traversal that escalates into remote code execution
Opening
A critical WordPress core vulnerability began attracting exploitation attempts within days of its disclosure, and the pattern is unusually consistent for an early campaign. CVE-2026-87902 is a path traversal issue in the template resolution logic of WordPress core, rated 9.2 on the CVSS scale. It requires no authentication and no user interaction. Public reporting attributes the first confirmed exploitation attempt to 22 September 2026 at 11:49 UTC, with 68 distinct attempts recorded by the firm tracking the activity.
Technical context
The vulnerable code path sits in get_page_template(), the function WordPress uses to decide which theme file renders a given page. Because the function resolves a requested template name against the filesystem rather than against a strict allowlist, a crafted request can walk out of the theme directory and cause the application to include a file of the attacker's choosing. That behaviour makes the bug a local file inclusion problem at heart, and the practical question is always which useful file sits within reach.
The issue affects WordPress versions from 4.7.0 through 7.1.1. Patched releases are 7.1.2, 7.0.6 and 6.9.9, with a backport landing on the legacy 4.7 branch as 4.7.37.
The exploitation chain, step by step
The reported chain does not stop at reading files. Once the inclusion primitive is available, attackers point it at pearcmd.php, a helper that ships with common PHP installations. When the PHP runtime has register_argc_argv enabled and the request reaches the helper with controllable arguments, an included file becomes an argument-driven command execution path. The last ingredient is a writable location: a theme directory whose name matches the page-* pattern gives the attacker somewhere to stage the file that gets executed.
Observed activity matches that shape. Analysis of the attempts lists artefacts such as wp-pear-rce-flag.php and poc87902.php, alongside droppers named with luci_ and zeta_ prefixes, which is what broad opportunistic scanning looks like rather than a targeted intrusion. Source addresses reported across the attempts include 43.250.53.42, 180.251.159.243, 195.178.110.247, 107.189.14.87, 45.61.184.170, 92.246.130.76 and 104.194.9.227.
That pattern matters for defenders. Broad scanning usually precedes focused exploitation by a small margin, so the window in which a patch can be applied before scripted, higher-fidelity attacks arrive is short.
Defensive implications
Patch first. Moving to 7.1.2, 7.0.6 or 6.9.9 removes the traversal primitive entirely, and legacy installations should follow to 4.7.37. Because the bug is reachable without credentials, treat the update as time critical rather than routine.
Patch hygiene is not the same as incident response. If a site was exposed before the fix, look for indicators that predate it: files with the naming patterns above in the web root, unfamiliar entries in theme directories, and PHP files under upload or media paths that no legitimate plugin writes. Review web server logs for traversal sequences in template parameters around the observed exploitation window.
Two configuration details deserve attention. Where PEAR helpers are not needed, removing them narrows the escalation path considerably. Disabling register_argc_argv on production PHP runtimes also breaks the argument-injection step, though it can affect other applications and should be tested before rollout. Neither measure substitutes for the patch.
Finally, keep a staging copy able to test theme and plugin updates in bulk. A site that cannot be patched quickly because of untested dependencies is a site that stays exposed for weeks, and evidence indicates this particular bug is already being exercised in the wild.
Top comments (0)