There is a version of this story that fits in one line: update WordPress. That line is true, it is the whole of the required action for most people reading this, and if you stop here and go and do it you will have got the value.
What follows is for the part that the one-liner hides. This flaw only becomes code execution if two conditions happen to be true about your site, and both of them are things you can check in under a minute without any security knowledge. One is a directory name inside your theme. The other is a setting in your web server’s PHP configuration that almost nobody chooses deliberately and that PHP’s own recommended production configuration leaves in the dangerous position.
Everything below was checked on September 24, 2026. Where a fact could be taken from a primary source we took it from the primary source and we say which one. Two of the findings are ours, from reading the patched source and from pulling WordPress’s own version control, and they are labelled where they appear.
Update, September 26, 2026. It is in the exploited catalogue now. On September 25 CISA added CVE-2026-87902 to the Known Exploited Vulnerabilities catalogue, with a federal remediation deadline of September 28 and the forensic triage flag set to yes. On the same date CISA revised its own enrichment of the CVE record: the
Exploitationvalue we quote below asnonenow readsactive. We re-pulled both this morning, the KEV feed at catalog version 2026.09.25 and the CVE record fromcveawg.mitre.org, last updated 03:55:51 UTC on September 26. The finding below is left as written, because the point was never that CISA was wrong. It was that the catalogue lags. Here the lag was measurable: three days between a firewall recording successful file writes and the entry appearing. If your provider, scanner or insurer keys off KEV, the alert fires for them today, and the required action is still the one at the top of this article.
What shipped
WordPress 7.1.2 was released on September 22, 2026. It contains one change. The release post calls it “a fix for a critical severity security vulnerability” and nothing else went out with it.
We did not take the timing from the announcement. The release archive on wordpress.org carries an HTTP last-modified header, and so does every backport:
curl -sI https://wordpress.org/wordpress-7.1.2.zip | grep last-modified
# last-modified: Tue, 22 Sep 2026 13:25:21 GMTThe identifier is CVE-2026-87902, credited to Robert Ressl, who reported it privately through WordPress’s HackerOne programme on July 20 and published his own write-up on the day of the release.
The fix was backported to every branch back to 4.7.37, which is 25 releases in total. That number matters more than it looks, and we come back to it at the end.
This is the second security release in five days. WordPress 7.1.1 went out on September 17 with eleven fixes, and we wrote that one up when it landed. If you updated then and assumed you were finished for the month, you are not.
The bug, in WordPress’s own source
We downloaded 7.1.1 and 7.1.2 and diffed the one file that changed. The whole vulnerability is visible in four lines of wp-includes/template.php, inside get_page_template():
if ( $template && 0 === validate_file( $template ) ) {
$templates[] = $template;
}
if ( $pagename ) {
$pagename_decoded = urldecode( $pagename );
if ( $pagename_decoded !== $pagename ) {
$templates[] = "page-{$pagename_decoded}.php";
}
$templates[] = "page-{$pagename}.php";
}Read the first block and the second block together, because that is the whole story. The first block takes a template name and runs it through validate_file(), which returns non-zero when the string contains directory traversal, before allowing it into the candidate list. The second block takes a value that came out of the URL, urldecodes it, and puts it straight into the candidate list with no check at all.
The patch is that check, moved one block down:
- if ( $pagename_decoded !== $pagename ) {
+ if ( $pagename_decoded !== $pagename && 0 === validate_file( $pagename_decoded ) ) {The decoded branch was added in WordPress 4.7.0, released December 6, 2016, so that visitors could reach pages whose slugs contain non-Latin characters. The documentation block above the function still records it: “The decoded form of page-{page_name}.php was added to the top of the template hierarchy when the page name contains multibyte characters.” The gap between that release and the fix is 3,577 days.
The patch also adds a second, broader layer: a new private function _wp_is_template_path_allowed() which locate_template() now calls before accepting any file it found. It resolves the real path and requires it to sit inside the stylesheet directory, the template directory or wp-includes/theme-compat. That one is defence in depth rather than the fix, and it is the part that protects plugins and themes calling locate_template() with their own untrusted input.
Why page- is the whole game
This is the part that decides whether your site is exposed, and it falls out of the code above rather than out of any advisory.
The candidate template name is assembled as page- plus the decoded slug plus .php. WordPress then asks the filesystem whether that file exists, relative to your theme directory. So a traversal payload produces a check like this:
<your theme>/page-templates/../../../../../../usr/local/lib/php/pearcmd.phpOn Linux, that path only resolves if every component of it exists, including page-templates. The attacker cannot invent it, because the page- prefix is hard-coded before their input begins. They have to continue a directory that is already there.
That is why the advisory’s precondition reads “the active child or parent theme contains a top-level directory whose name starts with page-”. It is not a heuristic. It is the only way out of the theme folder.
We also checked the third location locate_template() searches, wp-includes/theme-compat, in case core shipped a launch pad of its own. It contains nine PHP files and no directories at all, so it cannot be used.
Which themes have one
The advisory names five themes. We did not take that on trust. We downloaded the current package for each one from wordpress.org and listed its top-level directories, then did the same for five of the most widely installed themes that the advisory does not mention, and for the three themes bundled with WordPress 7.1.2 itself.
| Theme | Version checked | Top-level page- directory |
Active installs |
|---|---|---|---|
| Twenty Twelve | 4.9 | page-templates |
50,000 |
| Twenty Fourteen | 4.6 | page-templates |
50,000 |
| Neve | 4.2.13 | page-templates |
200,000 |
| Hestia | 3.3.6 | page-templates |
70,000 |
| Sydney | 2.71 | page-templates |
80,000 |
| Astra | 4.14.0 | none | |
| OceanWP | 4.2.6 | none | |
| GeneratePress | 3.6.1 | none | |
| Kadence | 1.5.2 | none | |
| Twenty Twenty-Five | 1.5 | none | |
| Twenty Twenty-Four (bundled) | in 7.1.2 | none | |
| Twenty Twenty-Three (bundled) | in 7.1.2 | none |
All five named themes have it, all five carry the same directory name, and the install counts (wordpress.org rounds them into buckets, so treat them as orders of magnitude) come to roughly 450,000 sites across those five alone.
Two things to take from the right-hand column rather than the left. A brand new WordPress install running a bundled theme cannot be taken this way, which is genuinely reassuring for the simplest sites. And the five named themes are the ones somebody checked, not the complete set. Any theme with such a directory qualifies, including one built for you. The check is one command, and it is in the action list below.
The server side, and why PHP’s own advice does not help
Having a way to include an arbitrary local .php file is serious on its own. Turning it into code execution needs a file on the server that will do something useful when included, and the file attackers have settled on is pearcmd.php, the command-line front end for PEAR, a package manager from an earlier era of PHP.
Including pearcmd.php over the web only becomes dangerous if PHP hands it the query string as command-line arguments. That behaviour is controlled by one setting, register_argc_argv. With it on, ?+config-create+<payload>+/tmp/x.php arrives inside the included script as though somebody had typed it at a shell, and PEAR writes the file.
So we went to look at what that setting defaults to. From the PHP manual’s core directives table, the default value of register_argc_argv is 1, meaning on. The manual also carries a warning: the feature is deprecated as of PHP 8.5.0, with the note that “deriving $_SERVER['argc'] and $_SERVER['argv'] from the query string for non-CLI SAPIs has been deprecated.”
Then we opened the configuration file PHP ships for production use. Here is the relevant block of php.ini-production, verbatim and complete:
; ... When this directive is
; enabled, registering these variables consumes CPU cycles and memory each time
; a script is executed. For security reasons, this feature should be disabled
; for non-CLI SAPIs.
; Note: This directive is ignored for the CLI SAPI
; This directive is deprecated.
; https://php.net/register-argc-argv
;register_argc_argv = OffLook at the last line. It begins with a semicolon, which is a comment in an ini file. PHP’s own recommended production configuration states that the feature “should be disabled for non-CLI SAPIs” and then does not disable it. The setting falls back to the built-in default, which is on. The same is true of php.ini-development.
There is a second tell six lines further down in the same file. auto_globals_jit = On is set live, and its own comment reads “The PHP directive register_argc_argv must be disabled for this directive to have any effect.” Shipped as they are, those two lines contradict each other: the performance option is switched on, and the thing it depends on is left in the state that makes it a no-op.
The official PHP Docker images are worth a separate line, because a large share of modern WordPress hosting is built on them. They still compile PEAR in. From the Dockerfile, verbatim:
# in PHP 7.4+, the pecl/pear installers are officially deprecated (requiring an explicit "--with-pear")
--with-pear \And they treat the ini files as samples rather than configuration:
# https://github.com/docker-library/php/issues/692 (copy default example "php.ini" files somewhere easily discoverable)
cp -v php.ini-* "$PHP_INI_DIR/"; \Copied, not activated. An official PHP image with no further configuration runs with no php.ini at all, which means every built-in default applies, which means register_argc_argv is on. And because the build prefix is /usr/local, PEAR lands at /usr/local/lib/php/pearcmd.php, which is the first of the three paths attackers are probing.
None of this is a WordPress problem. It is the layer underneath, and it is the reason a file inclusion bug that should have been an information leak is instead a full compromise. We made the same structural point about update machinery that reports success while serving a vulnerable build: the defaults are doing what they were configured to do, and the result is still wrong.
Finding one: the first attack landed before the patch existed in public
Patchstack published telemetry from its firewall, and the headline in most of the coverage is that attackers moved within hours of the patch. Their article states the first exploitation attempt at 11:49 UTC on 22 September, the first attempt to write a file through pearcmd at 15:34 UTC, and draws this conclusion, verbatim:
The payloads match the exact encoding the patch addresses, so whoever built them was working from the diff rather than from an independent discovery.
That conclusion requires the diff to have been public at 11:49. We went and checked when it actually was.
WordPress develops in Subversion, and both repositories are public and unauthenticated. You can query the commit log from anywhere. The fix is a single commit by johnbillion titled “Themes: Restrict path traversal in locate_template()”, and here is when each copy of it landed:
| Event | Time (UTC, 22 September) | Source |
|---|---|---|
| First exploitation attempt observed | 11:49 | Patchstack firewall telemetry |
Fix committed to trunk, develop r63792 |
12:04:48 | develop.svn.wordpress.org |
| Backported to the 7.1 branch, r63793 | 12:14:42 | develop.svn.wordpress.org |
| Mirrored to core, r62965 | 12:15:56 | core.svn.wordpress.org |
wordpress-7.1.2.zip published |
13:25:21 | HTTP last-modified on wordpress.org |
| Release announced on wordpress.org/news | 14:01:20 | RSS pubDate |
First pearcmd file-write attempt |
15:34 | Patchstack firewall telemetry |
| CVE-2026-87902 record published | 16:44:15 | CVE Program record metadata |
wordpress-4.7.37.zip, the oldest backport, published |
18:07:53 | HTTP last-modified on wordpress.org |
The commit immediately before the fix, r63791, is an unrelated documentation change timestamped 07:35:23 UTC. So between 07:35 and 12:04:48 there was nothing public to work from, and the first observed attack sits in that window, fifteen minutes and forty-eight seconds before the fix became public.
We want to be careful about how much weight this carries, so here is exactly what we are and are not saying. We are not saying Patchstack is wrong about their own telemetry, and we are not accusing anyone of anything. We are saying that two timestamps from two public records are in an order that the published explanation does not account for, and that the gap is small enough that a clock or a timezone label would explain it as easily as anything else would. The possibilities we can see are: the observation time is off by a small amount, the attacker found the bug independently and was already scanning, or the release was known in advance through a channel we cannot see. We cannot distinguish between them from outside, and we are not going to pick one.
What is worth carrying away regardless of which it is: the popular framing of this event is “attackers reverse-engineered the patch in hours”, and the record does not actually support that framing. If it is wrong, the useful lesson is the less comfortable one, which is that the window before a patch is not safe either.
The rest of the timeline is unambiguous and is the practical point. The oldest backport, the one an older site needs, was published four hours and forty-two minutes after the flagship release and two and a half hours after the first successful file write. Sites on old branches were last in the queue on the day it mattered most.
Finding two: it is being exploited and it is not in the exploited catalogue
CISA maintains the Known Exploited Vulnerabilities catalogue, and a great many organizations, including most of the security tooling a small business would ever encounter, treat presence in it as the signal to act now. We pulled it directly this afternoon. Catalog version 2026.09.23, 1,721 entries, released at 12:51:35 UTC on September 23.
CVE-2026-87902 is not in it. Neither is CVE-2026-93485, the flaw from five days earlier. (It was added on September 25, the day after this was published. CVE-2026-93485 still is not listed. See the update at the top.)
More pointed than that, CISA’s own enrichment of the CVE record, timestamped 16:56:15 UTC on September 22, carries these decision values:
"options": [
{ "Exploitation": "none" },
{ "Automatable": "no" },
{ "Technical Impact": "total" }
]Exploitation: none, recorded at 16:56 UTC. By then Patchstack had already logged the first file-write attempt at 15:34, an hour and twenty-two minutes earlier. Automatable: no, at a point when a named Nuclei template for the CVE was about to enter circulation. Those values stood until September 25, when CISA revised Exploitation to active and added the KEV entry. Automatable: no has not been revised.
None of this makes CISA wrong in any interesting sense. Enrichment is a snapshot and the catalogue is a process with human review in it. It makes the same point we made when we went through the risk-based patching directive: “not in the catalogue” is a statement about the last day or two of paperwork, not a statement about the vulnerability. On that occasion we found one entry that went from vendor advisory to a KEV listing flagged for ransomware use in two days. The catalogue is a lagging indicator, and this week it is lagging behind confirmed arbitrary file writes. The measurement is now closed: the listing arrived on September 25, three days after the first successful file write.
The two scores, and why both are right
You will see this flaw described as 9.2 and as 8.1, and reasonable people are going to argue about it. They are measuring with different rulers.
| Score | Scale | Vector | Assigned by |
|---|---|---|---|
| 9.2, critical | CVSS 4.0 | AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N |
WordPress, in the GitHub advisory |
| 8.1, high | CVSS 3.1 | AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |
CISA, as enrichment on the CVE record |
The interesting difference is how each one handles the preconditions. CVSS 4.0 has a dedicated metric for this, AT:P, meaning attack requirements are present, and it keeps attack complexity low because the attack itself is trivial once those requirements are met. CVSS 3.1 has no such metric, so the preconditions get folded into AC:H, attack complexity high, which is the only place to put them.
For your purposes the scores are close to irrelevant, and we would rather you used the two checks below than either number. What the split is genuinely useful for is calibration: when a vendor and a government body publish scores 1.1 apart on the same flaw within hours of each other, a single number was never going to tell you whether to act.
Every affected branch has a patch, and your site will probably take it by itself
This is the good news and it is unusually good.
WordPress runs automatic background updates for security releases by default, and the backports exist so that an old site can take the fix without a major version jump. We wanted to know whether that is actually true today for every branch, rather than in principle, so we asked WordPress’s update API the same question a real site asks it, once per branch:
curl -s "https://api.wordpress.org/core/version-check/1.7/?version=4.7.0"A site on 4.7.0 gets back 25 auto-update offers, from 7.1.2 all the way down to 4.7.37. The pattern holds the whole way up: a site on 5.8 is offered 5.8.17, a site on 6.4 is offered 6.4.12, a site on 7.0 is offered 7.0.6. Every branch in the affected range has a live offer on its own line, right now.
So how much of WordPress is in that range? We pulled the version statistics API, which reports by branch:
| Group | Share of installs |
|---|---|
| Branch 7.1 (current) | 57.78% |
| Branch 7.0 | 11.28% |
| Branches 4.7 through 6.9 | 29.96% |
| Branches below 4.7 (predate the bug) | 0.98% |
99.02 percent of WordPress installs are on a branch inside the affected range. Roughly thirty percent of all WordPress sites are on a branch old enough that the fix reached them as a backport rather than as the headline release.
Two honest limits on that table. The statistics API reports the branch, not the exact patch level, so it cannot tell us how many sites have taken 7.1.2 as opposed to sitting on 7.1.1. And automatic updates can be switched off, by a constant in wp-config.php, by a plugin, or by a host that manages updates itself. If they were switched off on your site, none of the above happens on its own.
What to actually do
1. Check your WordPress version. In the dashboard, it is at the bottom right of the screen, or under Dashboard then Updates. You want 7.1.2, or the patched release on your own branch if you are on an older one: 7.0.6, 6.9.9, 6.8.10, and so on down to 4.7.37. If it is anything else, click update now and stop reading.
2. Check your theme for the directory. This is the one that decides whether the flaw was ever code execution on your site. If you have file access or an SFTP client, look inside your active theme’s folder for anything beginning with page-. From a shell:
ls -d wp-content/themes/*/page-*/Nothing returned means there is no way out of the theme folder and the worst case on your site was an error, not a shell. A page-templates directory means the precondition was met, and you should treat the update as urgent rather than routine. Check the parent theme too if you use a child theme, because either one qualifies.
3. Search your access logs for the signature. The traversal always arrives percent-encoded, because WordPress’s slug sanitiser preserves escaped octets on its way through. You can see that in core’s own source, in sanitize_title_with_dashes(), where the comment above the line reads // Preserve escaped octets. A real page slug never contains one, so this search has close to no false positives:
grep -iE 'pagename=[^&]*%(25)?2e%(25)?2e|pearcmd|config-create' access.logAlso search for pagename and page_id appearing in the same request, which is the shape attackers are using, because without a page id that resolves to a real page WordPress serves a 404 and never reaches the vulnerable code.
4. If you find a hit that returned 200, treat the site as compromised. A stage one probe that worked returns the content of an unrelated core file, so OPML or RSS output coming back from an ordinary page URL is the tell. Then check /tmp and /var/tmp for unexpected .php files. Their presence means a write succeeded.
5. Ask your host one question. Most people reading this cannot change PHP settings, and on shared hosting the setting is not yours to change anyway, which is the same structural problem we went through in the cPanel root escalation last week. So ask:
Is
register_argc_argvenabled in the PHP configuration for our account, and is PEAR (pearcmd.php) present on the server?
A host that answers both parts in a business day is paying attention. Turning register_argc_argv off does not fix the file inclusion, but it breaks the chain that turns it into code execution, which is the difference between a bad day and a rebuild.
What we could not verify
Whether the 11:49 UTC observation is precisely accurate. Set out above. It is Patchstack’s own published figure and we have no way to audit their firewall clock.
Whether any host or partner was notified of the release in advance. WordPress has historically given some hosting companies advance notice of security releases. We could not establish whether that happened here, and the researcher’s own account says he was not given a release date in advance and had not asked for one. We raise it only because it is one of the explanations for the timeline gap, and we cannot rule it in or out.
Successful compromise of any specific site. Patchstack reports file writes into /tmp and /var/tmp, which are normally not reachable over the web, so what is demonstrated publicly is proof of execution rather than a persistent backdoor. We have seen no public report of a named site being taken this way.
Ubuntu’s assessment. We would normally cross-check a PHP-level issue against distribution trackers. Ubuntu’s security API returned HTTP 503 on three consecutive attempts this afternoon, so there is nothing from that source in this article. Resolved on September 25: the API is answering again, and the entry is in the update below.
Exact install counts for the affected themes. The figures in the table are wordpress.org’s own rounded buckets, which is the only granularity published. The 450,000 total is the sum of five rounded numbers and should be read as an order of magnitude.
Whether the named five are the complete list of affected themes. Almost certainly not, since the condition is a directory name rather than a theme identity. We checked twelve themes. There are thousands.
The short version
WordPress 7.1.2 fixes a flaw that lets an unauthenticated visitor make your site include an arbitrary PHP file from the server. On most sites that is a serious bug. On a site whose theme has a folder starting with page-, running on a server where PHP’s register_argc_argv is on and PEAR is installed, it is a stranger running commands as your web server.
Update. Then check whether your theme has that folder, because the answer tells you whether the last two days were a near miss or an incident.
The fix reaches back to 2016 and every affected branch has a live automatic update offer today, so for most people this resolves itself. The part that does not resolve itself is the second question, and it is worth ten seconds of your time.
If you would rather not run a platform where a directory name in your theme decides whether a stranger gets a shell, that is a reasonable conclusion and it is the one people usually reach after the second incident rather than the first. We have written about choosing between Astro, Next.js and WordPress and about what a Toronto small business site costs to build and run. A static site has no PHP, no theme folder and no template resolver to traverse. If you want us to look at what you are running now, get in touch.
Update, September 25, 2026
Three days on, we re-ran the two checks that were open when this went out.
Ubuntu’s tracker is back, and it confirms the score we relayed. Ubuntu records CVE-2026-87902 as published at 17:17 UTC on September 22, priority medium, with a CVSS 3.1 base score of 8.1 and the vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. That is the same 8.1 the CISA enrichment on the CVE record carries, arrived at independently, and the AC:H in it is the two preconditions this article spends most of its length on. The wordpress package is marked needs-triage on every supported Ubuntu release, with upstream noted as fixed in 7.1.2+dfsg1-1. Ubuntu’s description is worth quoting because it is the most honest one-sentence summary published anywhere:
An unauthenticated attacker can make
get_page_template()page-template resolution include a chosen readable local.phpfile outside the active theme directories. If relevant pre-conditions for both the server and the active theme are met, this can lead to RCE.
Note what it does not say. It does not call this remote code execution outright. It says file inclusion, and then code execution if the preconditions hold. That is the correct framing and it is the one this article took.
It is still not in CISA’s exploited catalogue. We pulled the feed again today: catalog version 2026.09.24, 1,723 entries, released September 24 at 19:00:55 UTC. CVE-2026-87902 is absent on day three, and so is CVE-2026-93485. The catalog is not idle, either. Two entries were added on September 24, both with three-day deadlines. Finding two above stands unchanged, and it is now a longer gap than it was when we wrote it.
Sources
- WordPress 7.1.2 Release, wordpress.org, September 22, 2026, for the release, the “critical severity security vulnerability” wording, the CVE and GHSA identifiers, the credit to Robert Ressl and the backport statement
- GHSA-7hp8-65ch-5whp, WordPress security advisory, for the two preconditions in their published wording, the five named themes, the full list of 25 patched versions and the CVSS 4.0 score of 9.2 with its vector
- CVE-2026-87902, CVE Program record, published 2026-09-22T16:44:15Z, for the publication timestamp, the CWE-98 classification, the affected range below 7.1.2, and the CISA ADP enrichment carrying the CVSS 3.1 score of 8.1 and the SSVC values quoted above
- WordPress 7.1.1 and 7.1.2 release archives, fetched today via HTTP
last-modifiedheaders, for the publication times ofwordpress-7.1.2.zip(13:25:21 GMT),wordpress-7.1.1.zipandwordpress-4.7.37.zip(18:07:53 GMT), and for the December 6, 2016 release date of WordPress 4.7 - develop.svn.wordpress.org commit log, queried directly today, for revisions r63791 through r63795 with their authors, timestamps and paths, establishing that the fix became public in trunk at 12:04:48 UTC on September 22
- core.svn.wordpress.org commit log, queried directly today, for r62965 on the 7.1 branch at 12:15:56 UTC and its commit message
- WordPress 7.1.1 and 7.1.2 source, downloaded and diffed today, for the
get_page_template()andlocate_template()changes, the new_wp_is_template_path_allowed()function, the@since 4.7.0note on the decoded template branch, thevalidate_file()implementation, the “Preserve escaped octets” comment insanitize_title_with_dashes(), the contents ofwp-includes/theme-compat, and the three bundled themes - WordPress.org theme directory API, and the current package for each of the ten themes in the table, downloaded and listed today, for the top-level directory contents and the active install figures
- WordPress.org core version-check API, queried once per branch today, for the 25 auto-update offers returned to a 4.7.0 install and the per-branch offers quoted above
- WordPress.org statistics API, pulled today, for the branch shares in the adoption table
- register_argc_argv, PHP manual core directives, for the default value of
1, the INI_PERDIR changeability, and the PHP 8.5.0 deprecation notice quoted above - php.ini-production, php-src, fetched today, for the verbatim comment block and the commented-out
;register_argc_argv = Offline, and forauto_globals_jit = Onwith its dependency note - Official PHP Docker image Dockerfile, fetched today, for the verbatim
--with-pearcomment, thecp -v php.ini-*line and its comment, and the/usr/localprefix that puts PEAR at/usr/local/lib/php - CVE-2026-87902: Attackers Started Probing WordPress Sites Hours After the Patch, Patchstack, published September 22 and updated September 23, 2026, for the 11:49 UTC and 15:34 UTC observation times, the three-stage attack description, the
pearcmd.phppaths, the dropped filenames, the named user agents including the Nuclei template, and the quoted conclusion about the patch diff - Known Exploited Vulnerabilities Catalog, CISA, catalog version 2026.09.23, 1,721 entries, released 2026-09-23T12:51:35Z, pulled on September 24, for the confirmation that neither CVE-2026-87902 nor CVE-2026-93485 was listed at that point, and re-pulled September 26, 2026 at catalog version 2026.09.25, 1,726 entries, for the CVE-2026-87902 entry added September 25 with a September 28 due date, the forensic triage flag set to yes and the quoted description
- CVE-2026-87902 record, CVE Program API, last updated 2026-09-26T03:55:51Z, retrieved September 26, 2026, for the CISA-ADP SSVC block timestamped September 25 carrying
Exploitation: activein place of the earliernone, and for the KEV reference attached to the same record - CVE-2026-87902: Critical WordPress file inclusion and conditional RCE, Robert Ressl, for the disclosure timeline, the July 20 report through HackerOne and his statement that he was not given a release date in advance
