TechAtelier
CYBERSECURITY · WORDPRESS · VULNERABILITIES

WordPress: when the patch becomes the attacker playbook

WordPress 7.1.2 fixed CVE-2026-87902 on September 22, 2026. Less than five hours later, probes matching the fix were already being observed on the Internet.

The key lesson is not simply that WordPress had a critical vulnerability. It is how quickly a public patch can be compared, understood and turned into automated probes. For Internet-facing services, the gap between “patch available” and “likely probing” can be only a few hours.

What WordPress 7.1.2 fixes

The release fixes a critical page-template resolution issue. Under specific server and active-theme conditions, an unauthenticated attacker can include a readable local PHP file outside the allowed theme directories, potentially leading to remote code execution.

The issue is tracked as CVE-2026-87902. WordPress recommends immediate updating and backported the fix across supported branches down to 4.7.

The important part: the timeline

  • September 22: WordPress 7.1.2 is released.
  • Hours later: automated probing is observed.
  • 17:44 UTC: Patchstack records its first attempt, less than five hours after release.
  • The probes match the patch: requests use the exact kind of encoding addressed by the fix.

A public patch also reveals the shape of the bug

Once a fix is published, attackers can compare old and new code. The diff sharply reduces the work required to understand the vulnerability and build an automated test.

A probe is not automatically a compromise

The first requests reported by Patchstack targeted ordinary WordPress core files. They were mainly testing whether local inclusion worked. That matters: seeing a probe does not prove attacker-controlled code execution. A response showing unexpected internal-file content, however, is a strong signal that the host was genuinely exposed.

What this changes for patch priority

CVSS helps, but context matters more. Internet exposure, no-auth exploitation, high impact, a public diff, active probing and broad deployment should all raise remediation priority.

For this class of issue, waiting for the next monthly maintenance window may no longer be appropriate.

What this suggests for InfraCheck

A posture tool should not treat every vulnerability as a static score. Detected technology, vulnerable version, Internet exposure and observed exploitation should influence urgency together. A useful model is therefore version + exposure + exploitability + real-world activity.

What to do

  • Update to WordPress 7.1.2 or the patched release for your branch.
  • Verify security auto-updates are actually working.
  • Review logs if the site remained exposed before patching.
  • Look for abnormal pagename requests and encoded traversal patterns.
  • Inspect unexpected or modified files if inclusion appears to have succeeded.
  • Do not treat a WAF as a permanent substitute for the fix.

The reaction window is shrinking

CVE-2026-87902 illustrates a common reality: a security patch protects users who install it, but also tells attackers exactly where to look. The answer is not to hide fixes. It is to make deployment speed part of the defensive posture for critical Internet-facing services.

Sources

Published September 25, 2026.