A critical WordPress Core vulnerability was patched on September 22, 2026, and attackers began targeting it the same day, according to Patchstack telemetry.
WordPress.org’s release documentation says WordPress 7.1.2 was released to the public on September 22, 2026, with one security fix. The documentation recommends immediate updates and lists patched releases for older affected branches back to WordPress 4.7.
Patchstack reported that the first exploitation attempts reached its firewall at 11:49 UTC on September 22. By 15:34 UTC, the security firm said it had observed the first attempt to write a file to disk through the attack chain.
That shift matters. The activity did not remain limited to curiosity-driven scanning. Patchstack’s September 23 update said traffic had grown to more than ten times the volume seen on the first evening, reached a wider spread of sites, and moved through stages from vulnerability probing to attempts involving PEAR’s pearcmd.php and attacker-controlled PHP file writes.
The Canadian Centre for Cyber Security updated its advisory on September 25, saying open-source reporting indicated CVE-2026-87902 was being exploited in the wild. The Cyber Centre also noted that the U.S. Cybersecurity and Infrastructure Security Agency had added the vulnerability to its Known Exploited Vulnerabilities database on September 25.
What CVE-2026-87902 affects
The WordPress GitHub advisory rates the issue as critical with a CVSS 4.0 score of 9.2. The vulnerability affects WordPress Core, not a third-party extension.
According to the advisory, an unauthenticated attacker can make get_page_template() include a readable local PHP file outside the active theme directories. Remote code execution depends on preconditions involving the active theme and the server environment.
Those preconditions include an active child or parent theme with a top-level directory whose name starts with page-, such as page-templates. The advisory names legacy Twenty Twelve and Twenty Fourteen themes, plus third-party themes such as Neve, Hestia, and Sydney, as examples with the relevant directory structure.
The advisory also says a chosen local .php file must exist on the server and be readable by the web server account. One path to code execution involves pearcmd.php when PHP’s register_argc_argv setting is enabled. The advisory says the official PHP image for Docker is affected, and default cPanel configuration is affected when PHP prior to 8.5 is in use.
Patched versions are available across older branches
WordPress 7.1.2 contains the fix for the current branch. WordPress.org also lists patched releases for older affected branches, including 7.0.6, 6.9.9, 6.8.10, and releases back to 4.7.37.
That does not mean every old WordPress site is safe to leave on an old branch. WordPress.org’s release documentation says only the most recent WordPress version is actively supported and that WordPress 4.6 and earlier no longer receive security updates.
For businesses, that distinction is practical. A backported security release can close this specific hole on an older branch, but aging website stacks still create update, compatibility, and monitoring problems that tend to surface during emergencies.
Conditional does not mean low priority
Some vulnerabilities sound less urgent when exploitation depends on server conditions. CVE-2026-87902 shows why that assumption can be risky.
The issue does not require a login. It affects WordPress Core. Patchstack reported same-day exploitation attempts. The Cyber Centre later said open-source reporting indicated exploitation in the wild, and CISA added the issue to its Known Exploited Vulnerabilities database.
In a small, well-documented environment, administrators may be able to quickly verify the active theme structure, PHP configuration, hosting details, and logs. In a business environment with multiple sites, legacy themes, contractor-built websites, or managed hosting accounts, verification can take longer than applying the supported security update.
What administrators should check now
Administrators responsible for WordPress sites should treat updating and investigation as separate tasks. Patching closes the vulnerable code path. Review work helps determine whether attackers reached the site before the fix was applied.
- Confirm the deployed WordPress version. Affected sites should be updated to WordPress 7.1.2 or the patched release for the relevant branch.
- Verify automatic updates completed. A site should not be assumed patched until the active version is confirmed in the dashboard, hosting panel, command line, or managed WordPress tooling.
- Review activity from September 22 onward. Patchstack identified high-signal indicators involving encoded traversal attempts in the
pagenameparameter,pagenameandpage_idappearing together, and requests containingpearcmd,config-show, orconfig-create. - Check for unexpected PHP files. Patchstack reported observed file-write attempts using temporary locations such as
/tmpand/var/tmp. Administrators should also check web-accessible directories for new or suspicious PHP files. - Treat firewall rules as a layer, not the fix. Patchstack said its customers were protected by a RapidMitigate rule, but still said WordPress 7.1.2 or the patched release for the site’s branch remains the fix.
The broader lesson for business websites
This WordPress case is part of a broader shift in vulnerability response. Once a patch, advisory, or code change becomes public, attackers can compare versions, build probes, and scan the internet quickly.
Businesses running public websites, ecommerce stores, client portals, VPNs, remote access tools, mail servers, and content management systems need a patch process that can move faster than a monthly maintenance calendar.
That process should answer a few questions before a crisis lands. Which public systems exist? Who owns each one? Who can approve an emergency update? Where are backups stored? How quickly can a restore be tested? Who reviews logs after a critical exposure?
The answer does not have to be complicated, but it has to exist. Critical fixes for internet-facing software need a clear owner, a reliable alert source, recent backups, a tested update path, and a post-patch review process.
CVE-2026-87902 is a WordPress story, but the message is larger than WordPress. When attackers start probing on patch day, businesses cannot afford to find out who owns the website after the scanning begins.
I can suggest related Tech Help Canada articles based on the topic you’re reading now.
Tech Help Canada Staff researches, writes, and reviews practical content for business owners and professionals. Our coverage spans business, marketing, SEO, technology, and the tools and systems people use to grow and operate online. We focus on clear, useful information backed by research, hands-on experience, and editorial review. Learn more about our team and editorial standards. Need help with something? Contact Us
