WordPress CVE-2026-87902 exploited within a day of patch as honeypots log 64 attempts

What happened

A vulnerability in WordPress core, tracked as CVE-2026-87902 and fixed in version 7.1.2, went from patched to actively exploited in roughly a day. A report on dev.to, drawing on telemetry from Patchstack and BleepingComputer, describes attack traffic appearing almost immediately after the fix shipped. The bug is rated 8.1 on CVSS v3.1 and allows an unauthenticated attacker to include a local PHP file that the web server can read — a primitive that can escalate to remote code execution.

How the vulnerability works

According to the dev.to write-up, the root cause is a path traversal in the pagename parameter. The attacker supplies a traversal sequence that is encoded twice: the first layer lets it pass WordPress's early sanitisation, and the second is decoded only once the request reaches get_page_template(). At that point the template loader will accept a file outside the active theme's directories, provided the file exists, is readable, and ends in .php or .html.

File inclusion on its own is constrained. The write-up explains that full code execution needs two further conditions: the active theme must contain a top-level page- directory, and PHP must run with register_argc_argv enabled. When both hold, the commonly described chain abuses pearcmd.php, a script that ships with PHP, to turn file inclusion into command execution.

What the attackers did

Previdian honeypot sensors logged 64 attack attempts originating from a single host in New Jersey. The campaign's payload was a web shell hosted on GitHub, which attackers used the flaw to try to plant. The traffic pattern — many probes from one source — fits opportunistic scanning that delivers a payload to the first target that responds.

A successful installation would give the operator an interactive shell running as the web server user, exposing configuration files such as database credentials and anything else that process can reach.

Who is affected

Every WordPress release below 7.1.2 is vulnerable, and the vendor has backported the fix across the maintained branches. The sites most exposed pair an unpatched core with an affected theme and a permissive PHP configuration. The observed campaign did not focus on any particular industry; it probed broadly, so small and mid-sized deployments are as likely to be hit as large ones.

ZoomEye figures cited in the write-up show just under eight million assets fingerprinted as WordPress and, at the time of writing, zero results for the CVE itself. The post attributes that mismatch to indexing lag rather than low exposure: attack traffic was already circulating before per-CVE search had caught up.

What operators should do

The first step is to update to 7.1.2, or the backported release for the installed branch, without delay. Operators should then hunt for the campaign's indicators: requests carrying traversal sequences in template parameters, outbound connections from the web server to code-hosting domains, and PHP files newly written to disk. If any of these are present, credentials reachable by the PHP user should be rotated.

Why it matters

The story is less about the bug than the clock. Exploitation began within about a day of the patch, which means attackers are watching release notes and weaponising them faster than many organisations patch. WordPress's enormous install base — nearly eight million exposed assets on one search engine alone — makes even a small fraction of unpatched sites a worthwhile target.

The mechanics also carry a lesson for defenders: the path from file inclusion to code execution depends on a PHP setting, register_argc_argv, that many deployments do not need. Disabling it and applying similar hardening narrows the blast radius while patching catches up. Finally, the gap between ZoomEye's product count and its per-CVE count is a reminder that indexing lags reality, and a zero result should never be read as an all-clear.