CVE-2026-87902 is being exploited, there is finally something to search for, and one timestamp moved six hours

The first sighting moved by five hours and fifty-five minutes

WordPress published the 7.1.2 release post at 14:01:20 UTC on 22 September 2026. That timestamp is in the news feed and in the page metadata, and it is the moment the flaw we wrote about yesterday, CVE-2026-87902, became public knowledge in the ordinary sense.

On the evening of 22 September, Patchstack published a post saying its firewall first saw matching requests at 17:44 UTC, which it described as less than five hours after the release. On 23 September the same post was updated. The same field now reads 11:49 UTC. The prose changed with it, from "less than five hours after 7.1.2 was published" to "the same day 7.1.2 was published".

The arithmetic on those two numbers: 17:44 minus 11:49 is five hours and fifty-five minutes. Measured against the release post, the original figure sits 3 hours 42 minutes and 40 seconds after it. The replacement sits 2 hours 12 minutes and 20 seconds before it.

It goes further than that. The commit that fixes this flaw, Themes: Restrict path traversal in locate_template(), landed in the public WordPress development repository at 12:04:48 UTC, as trunk revision 63792. The revised first sighting is 15 minutes and 48 seconds earlier than the commit, and the paragraph containing it says the payloads "match the exact encoding the patch addresses, so whoever built them was working from the diff". Those two statements cannot both be true as published.

Our verdict on the phrase "within hours": the sources support the same day, and that is what this piece will say. The one published figure that cleanly supports "within hours of disclosure" has been withdrawn by the firm that published it, and its replacement makes a stronger claim than anyone is actually asserting.

What changed since yesterday, and what did not

Yesterday's briefing established the shape of this flaw from the primary sources: 25 releases on 17 September and 25 more on 22 September, every branch back to 4.7 patched twice in five days; CVSS 4.0 9.2 from WordPress and CVSS 3.1 8.1 from CISA-ADP; an include rather than a read or a write; two preconditions; and DISALLOW_FILE_MODS mitigating nothing here while disabling the update that fixes it.

It closed on an absence. The advisory published no evidence of exploitation and no indicator to search for, which meant a clean search of your logs proved nothing at all. That is the part that has changed.

The record on 22 September against the record on 24 September. Sources: the GHSA advisory, the WordPress news feed, the CISA KEV JSON, the NVD API, the Patchstack post and the Previdian vulnerability page.

Question	22 September	24 September
Is it exploited?	Not stated by anyone	Two sensor networks say yes
Anything to search for?	Nothing published	Request, response and file indicators
Code execution seen?	Not stated	File writes via pearcmd reported
Commodity tooling?	None known	A named Nuclei template, two branded agents
WordPress statement?	The release post only	Still the release post only
In the CISA KEV catalogue?	No	No, in a catalogue updated since
CISA-ADP exploitation value	None	Still none

The right-hand column is worth reading twice. Everything a defender gained in two days came from two commercial firms selling protection against the thing they measured. Nothing came from the vendor, and nothing came from the state. That is not an accusation, and it is not unusual. It is a description of who actually produces this material, and it has consequences for how much weight a single number from it can carry.

The indicators, and the one that answers the question you actually have

Patchstack has published a set of log indicators, and they are genuinely usable. They fall into three places, and the three places answer three different questions. Collapsing them into one list is the mistake to avoid.

The request indicators tell you that you were scanned. Given a named Nuclei template in circulation, every internet-facing WordPress site will match them sooner or later, and matching them means approximately nothing about your exposure.

The response indicator is the one that matters, and it is the reason this is a better day than yesterday. The reconnaissance stage points the inclusion at an ordinary core file, most often wp-links-opml.php, precisely because that file emits a distinctive OPML document. If that document came back with a 200 from a normal page URL on your site, the inclusion ran. Patchstack's own words are that this should be treated as "a confirmed vulnerable window rather than a blocked attempt".

That is a question about your own server's output, not about the attacker's input, and it is the one a WAF log will not answer for you. Most teams keep request logs and discard response bodies, which is exactly the wrong way round for this flaw.

# 1. Were you scanned? Encoded traversal in the page slug.
grep -aE 'pagename=[^& ]*(%2e%2e|%252e%252e)' access.log

# 2. The pairing that rarely occurs in ordinary traffic.
grep -aE 'pagename=' access.log | grep -aE 'page_id=' | grep -aE ' /(index\.php)?\?'

# 3. The second and third stages, by name.
grep -aiE 'pearcmd|config-show|config-create' access.log

# 4. Did code run? PHP files where none belong.
find /tmp /var/tmp -maxdepth 2 -name '*.php' -newermt '2026-09-17'

# 5. The decisive one, and it is not a log grep: for any request that
#    matched 1 to 3 and returned 200, recover what the body was.
#    OPML or RSS from an ordinary page URL means the inclusion ran.

pearcmd, at the level a defender needs and no further

The advisory names pearcmd.php as the example of its second precondition, and both sensor networks report it as the file attackers are actually reaching for. It is worth understanding why, because it explains which of your servers are exposed and which are not.

PEAR is the PHP Extension and Application Repository, a package system that predates Composer and still ships inside a great many PHP installations. pearcmd.php is its command line entry point. It is not a WordPress file, it is not a plugin, and it is not something anybody installed on purpose this decade. It is simply present, readable, and it takes instructions from its arguments.

The link between the two is the PHP setting register_argc_argv. The PHP manual describes it as telling PHP "whether to declare the argv and argc variables", and for a web server those variables are derived from the query string. So a PHP file that expects command line arguments, included by a web request on a server with that setting on, receives the query string as its arguments. The manual lists the default value as 1, and records the behaviour for non-command-line servers as deprecated as of PHP 8.5. That deprecation is exactly why the advisory ties its cPanel warning to PHP earlier than 8.5, and why 96.74 per cent of reporting WordPress installations sat on the wrong side of that line when we checked yesterday.

Chained to this flaw, that gives an unauthenticated request the ability to ask PEAR to write a file, with content the requester chooses. Patchstack reports seeing exactly that from 15:34 UTC on 22 September, on its revised timeline, and reports three candidate install paths being tried in sequence, which between them cover most distributions and container images.

One detail keeps this from being worse than it is, and it is the detail most of the coverage has skipped. The files are being written to /tmp and /var/tmp, which are not normally reachable over the web. As Patchstack puts it, that makes them a proof of execution rather than a persistent backdoor. Previdian's telemetry adds the next move: a request that then pulls a PHP upload script from a public code hosting domain. Egress from your web server's account to a raw code hosting endpoint is therefore a fourth place to look, and on most WordPress estates it should be close to zero.

Are the two preconditions holding up in the wild?

This is the question that decides whether a site owner should be frightened or merely busy, and the wild traffic gives a partial answer.

The theme precondition is being guessed, not enumerated. Nearly every observed payload leads with an encoded templates directory, because page-templates is the obvious name for the top-level directory the flaw requires. Patchstack reports also seeing template and a malformed variant. Nobody appears to be fingerprinting the theme first. That means the commodity tooling is currently finding the common case and missing sites whose vulnerable directory is named something else, and those sites are no safer for being missed.

The server precondition is being tested, not assumed. The second stage exists solely to ask whether PEAR is present and whether the argument trick works, before anything is written. That is a careful operator, and it is also a gift: a site that answers no to that question generates a distinctive failed probe rather than a compromise.

Ryan Dewhurst, founder of Previdian and previously the founder of WPScan, put the balance this way to The Hacker News: "certain preconditions make exploitation less likely", and his expectation is mass attempts with "relatively few actual compromises".

That is a reasonable read, and it comes from a firm whose product is an early warning feed, which is to say a firm with a commercial interest in this being alarming. It chose to be measured instead. The counterweight is Patchstack, whose product is a firewall rule, and whose language moved from "active probing observed" to "active exploitation, including attempts to write files to disk" in a single day. Both are describing their own sensors honestly. Neither can tell you about your site.

What the wild traffic establishes about the preconditions, and what it does not. Drawn from the Patchstack post of 23 September 2026 and the Previdian public record for CVE-2026-87902.

What is observed	What it establishes	What it does not establish
Payloads lead with an encoded templates directory	The common theme layout is being targeted	That other page- directory names are safe
Three PEAR paths tried in sequence	The server precondition is being probed, not assumed	How often the probe succeeds
68 attempts, 2 IP addresses, 1 sensor (Previdian)	The campaign reached at least one honeypot	Any rate of success against real sites
Files written to /tmp and /var/tmp	Code executed on those hosts	Persistence, since those paths are not web reachable
A named Nuclei template in circulation	The barrier to entry has gone	That scanning volume equals compromise

Did automatic updates in fact protect most sites? Nobody can tell you

The reassuring argument runs like this: automatic background updates have been on by default for minor releases since WordPress 3.7, every fix for this flaw shipped as a minor release within its own branch, and so most sites patched themselves overnight. Dewhurst leans on it explicitly.

The argument is sound in structure. The problem is that it cannot be checked, and the reason is oddly specific. WordPress publishes a public version distribution at its statistics endpoint. Fetched on 24 September 2026, it reports 43 entries, every one of them at branch level: 7.1 at 57.777 per cent, 7.0 at 11.284, 6.9 at 7.588, and so on down to 3.0. There is no 7.1.2 line, and no 7.1.1 line.

That granularity is exactly one decimal place short of the question. The 57.777 per cent on the 7.1 branch contains both the patched 7.1.2 and the vulnerable 7.1.1. The 42.223 per cent on everything else contains both a diligently updated 4.7.37 and an abandoned 4.7.12. The public data cannot separate them, so any claim that most sites are now patched, from anybody, is an inference rather than a measurement.

WordPress version distribution from api.wordpress.org on 24 September 2026, with our arithmetic. Shares are of reporting installations, which is not the same as all installations.

Population	Share	What it means for this flaw
On the 7.1 branch	57.777%	Contains both 7.1.2 and vulnerable 7.1.1
On any older branch	42.223%	Each has a patched release, down to 4.7.37
On a branch older than 4.7	0.98%	No fix exists and none is coming
Identifiable as patched	Not published	The endpoint reports branch level only

The 0.98 per cent is the honest bad news, and it is a number worth holding on to. Roughly one reporting installation in a hundred runs a branch older than 4.7, which is where the backports stop. For those sites there is no update to apply, automatic or otherwise. Breaking the PEAR chain and blocking traversal sequences in the pagename parameter is the whole of their defence, and it always will be.

The friendly name to attack here is "automatic updates". Automatic updates are a strong mechanism and they have probably done most of the work. They are not a control you can evidence to an auditor, a board or a client, because no public data source will tell you which of your sites took the update and when. If you want that answer for your own estate, you have to go and get the version string off each site yourself.

The official record still says nothing happened

We checked all three places a UK security lead would reasonably look, on 24 September 2026, two days into reported exploitation.

WordPress. The news feed carries nothing since the 7.1.2 post itself. The GHSA advisory text is as it was: the description, the two preconditions, the version lists, the credit to Robert Ressl. No indicators, no exploitation note, no update banner. The release post's own metadata shows it was modified on 23 September at 14:04 UTC, but the body still contains no reference to exploitation of any kind.

CISA. The Known Exploited Vulnerabilities catalogue, fetched directly from the JSON feed, is at version 2026.09.23 with 1,721 entries. CVE-2026-87902 is not in it. This is not a stale catalogue: it added four entries on 22 September, including two Check Point flaws, an F5 BIG-IP APM flaw and an Arista flaw. It has been curated since the exploitation reports and this is not in it.

NVD. The record was published at 17:17:28 UTC on 22 September and last modified at 20:00:03 the same evening. Its only severity metric is the CVSS 3.1 8.1 from CISA-ADP. Its SSVC decision point, stamped 16:56:15 UTC on 22 September, records exploitation as none.

There is one more number that deserves attention, and it is on Previdian's own page. The same page that marks this vulnerability as confirmed exploited, with first-party honeypot evidence, displays an EPSS score of 0.4 per cent. EPSS is a model of the probability of exploitation in the next thirty days, and on a vulnerability with a named Nuclei template and observed file writes, it reads as 0.4 per cent. The firm publishing both numbers side by side is, to its credit, not hiding the contradiction.

None of these are failures exactly. KEV has an evidentiary bar and a federal remediation obligation attached, so a two-day lag on a vendor-agnostic web flaw is defensible. SSVC values are stamped once and not continuously refreshed. EPSS is a model, and models lag. But the practical consequence for a UK security lead is blunt: if your exposure process is driven by KEV membership, by the NVD exploitation field, or by an EPSS threshold, then as of this morning this vulnerability is invisible to all three while two sensor networks watch it being exploited.

What to do, in the order worth doing it

Note what is absent from that list: blocking IP addresses. Two published lists exist and they do not overlap, and Patchstack reports the source population moving from a small cluster to several hundred addresses in a day. Its own advice is that blocklisting individual sources is not a strategy, and we agree.

The question that exposes the gap

Yesterday this flaw had two preconditions, a contested score and nothing to search for. Today it has indicators, a Nuclei template, reported file writes and two competing timestamps, and every one of those facts arrived from a company that sells a product for it. The vendor has said nothing further. The catalogue that triggers remediation deadlines does not list it. The national record still says exploitation: none.

So the question is not whether you have patched. You probably have, and automatic updates probably did it for you while you slept.

The question is this: if the only people who can tell you that a flaw is being exploited are the two firms selling protection against it, what is your process doing on the day they are wrong, or the day they disagree by five hours and fifty-five minutes and neither version carries a correction note?