WordPress 7.1.2 Patches a Critical Flaw That Attackers Started Exploiting the Same Day It Shipped

Key points

• WordPress 7.1.2, released 22 September 2026, fixes CVE-2026-87902, a high-severity flaw that lets an attacker run arbitrary code on a vulnerable server without needing a password.
• Patchstack recorded the first exploitation attempt at 11:49 UTC on the same day the patch shipped, with attack traffic roughly tenfold higher within twenty-four hours.
• The vulnerable version range runs from WordPress 4.7.0 through 7.1.1, covering nearly a decade of installs.
• Enterprise sites that disabled automatic updates to enforce change-control processes are likely still exposed.

WordPress's reach across the web is why CVE-2026-87902 matters beyond the usual vulnerability disclosure cycle. We've been tracking WordPress security closely: our 17 September story covered the 7.1.1 maintenance release that shipped five days before this one.

The flaw sits in the way WordPress resolves page templates, the files that control how a web page looks. A function called get_page_template() can be tricked into loading a PHP file (executable code used to build websites) from outside the folder it's supposed to stay inside, with no login required. Where the server is configured a certain way and the active theme meets certain conditions, that's enough to achieve remote code execution, or RCE: an attacker can run any command on the server as if they were sitting at the keyboard.

The official WordPress advisory credits Swiss researcher Robert Ressl with responsibly disclosing the bug. CVSS, the standard scoring system for ranking vulnerability severity, rates it 9.2 out of 10.

How did attacks start so fast?

Publishing a patch effectively publishes a map of the hole it closes. Attackers read patch notes.

Patchstack, a service that monitors WordPress security threats, recorded the first probing traffic within five hours of the 7.1.2 release. By the following day, attackers had moved from reconnaissance to actively delivering payloads. The failure mode here isn't slow patching. It's the assumption that a few days of grace exist between patch ships and attacks begin. That window's gone.

One complication: current attacks don't target the WordPress directory directly. Attackers are abusing a legitimate PHP tool called pearcmd.php, which handles package management. They use it to write a malicious file to /tmp, a temporary storage area on the server, then load and execute that file using the WordPress flaw. A security team watching only the WordPress folder for changes would miss the first stage entirely.

Should website owners be worried?

Yes, and the concern is bigger than most organisations will admit.

The affected range stretches from WordPress 4.7.0, released in 2016, through 7.1.1. Enterprises often run WordPress properties they've half-forgotten: campaign microsites built by outside agencies, investor-relations pages from acquisitions, regional country sites that predate the current IT team. Those older, unmaintained installs are precisely the ones still sitting on vulnerable versions.

Most personal or small-business WordPress sites receive security updates automatically, so they're likely already patched. Enterprise sites routinely turn that feature off so IT teams can review changes first. That caution is understandable, but change-control processes that treat an unauthenticated RCE flaw the same as a routine plugin update are protecting the process, not the organisation. Aman Mahapatra, chief strategy officer at Tribeca Softech, told CSO Online that enterprises with the most mature governance are probably the ones most exposed right now, because their own process is holding the fix in a queue while attackers scan.

If an attacker gains RCE on a WordPress server, they can read the site's configuration file, steal database credentials, create hidden administrator accounts, alter payment forms, redirect visitors, and plant persistent code that survives a surface-level cleanup.

Ressl, in comments first reported by CSO Online, was direct: verifying that an automatic update ran successfully is a separate task from simply enabling automatic updates. Both matter.

Find every WordPress install your organisation owns, including the ones marketing built three years ago, and confirm 7.1.2 is running on all of them before the end of the day. The installs nobody remembers are the ones attackers will find first.