WordPress patches a critical severity security vulnerability

WordPress has patched what it described as a critical severity security vulnerability that would allow an unauthenticated attacker full remote code execution (RCE) capabilities. There have already been reports of attacks in the wild.

Given its popularity, WordPress has frequently been under attack, and patched another maximum severity bug allowing RCE in July. WordPress said the current hole, tracked as CVE-2026-87902, was discovered and reported to the company by Switzerland-based security researcher Robert Ressl.

The post announcing the WordPress 7.1.2 security release said that the fix addressed an issue where “an unauthenticated attacker can, under certain conditions, make page template resolution include a chosen readable local PHP file outside the active theme directories. If relevant pre-conditions for both the server environment and the active theme are met, this can lead to remote code execution (RCE).”

It urged users to update their sites immediately, and said that the fix had been backported through version 4.7, as the hole also impacts many older versions of WordPress.

Noah Kenney, principal consultant at Digital 520, said his top concern was the massive extent of damage an attacker could inflict with this hole. 

“Once attackers have PHP execution, they can read wp-config.php, obtain database credentials and authentication keys, create administrator accounts, alter payment or lead capture forms, redirect visitors, and install persistent code,” he said. “The less obvious part is how they get there. Pearcmd.php is a legitimate PHP package management tool, but attackers can abuse its configuration commands to write content of their choosing to disk. The current attacks use it to place malicious PHP in /tmp, then use the WordPress flaw to load and execute that file. A security team monitoring only the WordPress directory for changes could miss that first stage entirely.”

New risk reality

But IDC and others saw the speed with which attacks began as the most concerning element of this report. 

“This WordPress vulnerability is a textbook example of the new risk reality: attackers are exploiting critical bugs within hours of disclosure, and most enterprises are not patching fast enough to keep up,” said IDC Research Director Philip Harris, citing reports from security firm Patchstack that attackers had leveraged the hole shortly after WordPress posted the patch. 

Patchstack said, “When this post first went up, every request we had seen was reconnaissance against harmless core files. That is no longer true. Attackers are now including pearcmd.php and using it to write PHP files to disk and public scanning tooling for this CVE is in circulation.”

IDC’s Harris noted that Patchstack’s telemetry illustrated the new reality, with attacker reconnaissance occurring within five hours of the patch, and full exploitation within about a day. “The window between disclosure and exploitation has collapsed to the point that mean time to exploit for critical vulnerabilities is now negative in some cases, meaning exploit code appears before or immediately after a patch ships,” he said. “This WordPress bug tracks that pattern closely: Patchstack recorded the first probing traffic under five hours after WordPress 7.1.2 was released, and traffic volume increased roughly tenfold within a day as attackers moved from scanning to actual payload delivery.”

Aman Mahapatra, chief strategy officer for New York City-based technology consulting firm Tribeca Softech, agreed.

“The number that should anchor this story is not the 9.2 CVSS score, but it is the gap between patch and exploit. With this vulnerability, that gap was effectively zero,” he said. “WordPress shipped 7.1.2 on September 22, and Patchstack blocked the first exploitation attempt at 11:49 UTC the same day, using payloads that matched the exact encoding the patch was written to fix. Attackers did not discover this bug. They read the fix. Publishing a patch is now functionally publishing an exploit guide, and any enterprise still running a remediation cycle measured in weeks is operating on a timeline that stopped existing some time ago.”

Speedier patching needed

One response to the speed of attacker actions is to automate updates, but that is not necessarily a good option. Some enterprise CISOs are nervous about excessive patch automation; they want to review and approve any system changes, mostly to avoid disasters such as 2024’s Crowdstrike incident. 

Ressl said in an interview that another concern about automated updates is that many enterprises don’t perform sufficient verification that the updates executed properly.

“Having automatic updates enabled is not the same as verifying that the patch is installed,” he said. “Compatibility and availability concerns are legitimate reasons for testing updates. My recommendation is a rapid, tested rollout with verification across all exposed installations, including staging sites.”

Mahapatra added that the problem with update automation is especially severe in larger enterprises. 

“WordPress applies minor security releases automatically by default, which means the average hobbyist blog is probably already patched,” he pointed out. “Enterprise sites routinely disable those auto-updates to enforce change control, so the organizations with the most mature governance are the ones most likely to still be exposed this week, because their own process is holding the fix in a queue while attackers scan. Change control that cannot distinguish an unauthenticated remote code execution flaw from a routine plugin update is protecting the process rather than the enterprise, and this is the vulnerability that makes that distinction expensive.”

And, noted Nidhi Luthra, executive advisor for Acceligence: “A security release can become an attacker roadmap almost immediately, so emergency patching for internet-facing systems needs an hours-level response.”

Forgotten WordPress sites may not be patched

Mahapatra added that another, perhaps bigger, concern is the fact that many enterprise WordPress deployments happen below the radar. They are not typical shadow IT, because they are fully authorized at the time, but they are still often unknown to IT management. 

In enterprises, he said, “the exposure is materially larger than most organizations will assume because most enterprises do not think of themselves as WordPress shops, and almost all of them are. The risk sits in the web estate that IT never inventoried: marketing microsites, campaign landing pages, regional country sites, investor relations pages built by an outside agency, and the properties of companies acquired three years ago that nobody got around to migrating. The affected [WordPress version] range runs from 4.7.0 through 7.1.1, nearly a decade of installs, and the forgotten sites are precisely the ones still sitting on old branches.”

Mahapatra said that he has especially seen this in enterprises in the finance vertical.

“When I walk through external attack surface reviews with banking CISOs, the WordPress instances that surface are almost never the corporate site,” he said. “They are the sites that belong to marketing, a subsidiary, or an agency contract that expired, and none of them appear in the CMDB the security team is patching against.”