Exploitation has moved beyond reconnaissance
Patchstack says it first observed CVE-2026-87902-related traffic at 11:49 UTC on 22 September, followed by the first file-write attempt at 15:34 UTC. By 23 September, the company says traffic visible to its firewall had grown to more than ten times the first evening's volume and peaked around midday UTC. Those figures describe Patchstack-protected traffic rather than the global WordPress population.
The observed sequence progressed from requests looking for reachable WordPress files to checks for a PHP utility that can be abused under the vulnerable configuration, then to attempts to make the server write attacker-controlled PHP under temporary directories. Patchstack says some writes contained harmless markers while others contained PHP intended to execute a shell command if later reached. BleepingComputer reported the same escalation from Patchstack's data rather than from a separate telemetry network.
The WordPress flaw still depends on specific server conditions
WordPress's own advisory describes the underlying flaw as unauthenticated page-template path traversal. A crafted template path can escape the active theme directories and cause WordPress to include a readable local PHP file. That is the access-control failure fixed by the September security releases.
Remote code execution requires additional conditions beyond an unpatched WordPress version. The active theme needs a compatible top-level page-template directory and the server needs a readable PHP target that can be influenced through the request. WordPress documents PEAR's command-line helper as one route when PHP is configured to expose command-line arguments. The file-write attempts observed by Patchstack show that attackers are testing that route on real sites, but they do not mean every unpatched installation is equally exploitable.
Security backports reach the 4.7 branch
The affected ranges run from WordPress 4.7.0 through 7.1.1. WordPress fixed the current line in 7.1.2 and published security backports including 7.0.6, 6.9.9, 6.8.10 and equivalent releases through 4.7.37. The project recommends updating immediately rather than relying on theme or server configuration as a long-term mitigation.
For incident review, Patchstack recommends checking for suspicious requests associated with this CVE and unexpected PHP files in temporary directories. That is useful defensive context because the current public evidence includes attempted writes, but a temporary file by itself does not establish durable persistence or a later successful command channel.
One telemetry source cannot measure global compromise
Patchstack says the broader traffic came from a few hundred source addresses, while actual file-write attempts came from a much smaller subset. Its firewall view is useful first-hand telemetry, but it covers only traffic the company can see. No second security provider, WordPress project notice or government advisory reviewed for this update independently measures the same exploitation campaign, and BleepingComputer relies on Patchstack for the underlying observations. The sources reviewed here do not establish how many WordPress sites were successfully compromised, whether written PHP was reachable over the web, or whether attackers established persistent web shells or follow-on access. The evidence now shows public exploitation attempts advancing from scanning to server-side file writes on some vulnerable targets, which increases the urgency of applying the already available fixes.
