Unauthenticated WordPress path traversal CVE-2026-87902 escalates to RCE, already exploited

Exploitation attempts against a newly disclosed WordPress core vulnerability began within days of the flaw becoming public, according to a technical write-up on dev.to. The bug, tracked as CVE-2026-87902 and scored 9.2 on the CVSS scale, is a path traversal in WordPress's template resolution logic. It requires no authentication and no user interaction, and public reporting cited by the post dates the first confirmed exploitation attempt to 22 September 2026 at 11:49 UTC, with 68 distinct attempts logged by the firm tracking the activity.

How the flaw works

The problem sits in get_page_template(), the function WordPress consults when deciding which theme file should render a page. Instead of checking a requested template name against a strict allowlist, the function resolves it against the filesystem. A crafted request can therefore walk out of the theme directory and force WordPress to include a file of the attacker's choosing, turning the flaw into what is essentially a local file inclusion bug.

Versions 4.7.0 through 7.1.1 are affected. Fixed releases are 7.1.2, 7.0.6 and 7.9.9's predecessor 6.9.9, and a backport has landed on the legacy 4.7 branch as 4.7.37.

From file inclusion to code execution

The reported chain does not stop at reading files. With the inclusion primitive in hand, attackers aim it at pearcmd.php, a helper that ships with many PHP installations. If the PHP runtime has register_argc_argv enabled and the request reaches the helper with attacker-controlled arguments, the helper can be driven into executing commands of the attacker's choosing. The final ingredient is somewhere writable: a theme directory whose name matches the page-* pattern gives the attacker a place to stage the file that ultimately runs.

What the early activity looks like

Artefacts seen in the analysed attempts include wp-pear-rce-flag.php and poc87902.php, alongside droppers carrying luci_ and zeta_ prefixes — the profile of mass, untargeted scanning rather than a deliberate intrusion. Reported source addresses 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. The dev.to post cautions that this kind of wide-scale scanning tends to precede more selective attacks by only a small margin, leaving administrators little time to patch before higher-fidelity tooling follows.

What defenders should do

Patch first, and treat the update as time-critical rather than routine. Because the bug is reachable without credentials, moving to 7.1.2, 7.0.6 or 6.9.9 — or 4.7.37 on the legacy branch — removes the traversal primitive outright.

Patching is not the same as incident response. For sites exposed before the fix, the post recommends hunting for files matching the naming patterns above in the web root, unfamiliar entries inside theme directories, and PHP files under upload or media paths that no legitimate plugin would write. Web server logs should also be reviewed for traversal sequences in template parameters around the observed exploitation window.

Two configuration changes narrow the escalation path where PEAR helpers are unnecessary, removing them cuts off the route to pearcmd.php considerably. Disabling register_argc_argv on production PHP runtimes breaks the argument-injection step as well, though it can affect other applications and should be tested before rollout. Neither measure is a substitute for the patch. Maintaining a staging environment capable of testing theme and plugin updates in bulk matters too: a site held back by untested dependencies is a site that stays exposed for weeks.

Why it matters

An unauthenticated flaw that escalates from path traversal to full remote code execution, across WordPress releases from 4.7.0 to 7.1.1, is close to the worst case for a web application bug. The affected install base is enormous, early exploitation groundwork is already visible in logs, and the scanning pattern suggests that more focused attacks are a question of when rather than whether. Sites that delay patching — or cannot patch quickly because of plugin and theme dependencies — are precisely the ones the next wave of automated attacks will find.