What Happened
On September 22, WordPress released version 7.1.2 to patch CVE-2026-87902, a critical remote code execution vulnerability discovered by security researcher Robert Ressel. This flaw affected WordPress versions 4.7.0 through 7.1.1. Within five hours of the patch release, Patchstack recorded the first probing traffic targeting the vulnerability. Organizations running unpatched WordPress instances became immediate targets.
Timeline
September 22, time unknown: WordPress releases version 7.1.2 with security fixes.
September 22, under 5 hours post-release: Patchstack detects first exploitation attempts in the wild.
September 22 onward: Active scanning and exploitation continue across vulnerable instances.
This timeline highlights a critical gap: the window between patch availability and deployment is now a period of active exploitation, not just theoretical risk.
Which Controls Failed
Asset inventory breakdown. Forgotten WordPress sites became breach entry points due to a failure in asset management. Organizations knew they had WordPress somewhere but couldn't enumerate every instance when the patch dropped. PCI DSS v4.0.1 Requirement 2.4 requires maintaining an inventory of system components in scope. If you can't list your WordPress installations in under an hour, you're not meeting this requirement.
Patch deployment velocity. Five hours from patch to probe means your traditional "patch Tuesday plus testing" cycle is obsolete for critical vulnerabilities. Many organizations have a 7-14 day window for critical patches, with additional time for change control approval. That's 168 hours minimum. Attackers needed five.
Change control rigidity. The tension between "move fast" and "don't break production" killed speed. Teams waited for change advisory board meetings, ran through test suites, and scheduled maintenance windows. Meanwhile, scanning began. ISO 27001 Annex A.12.6.1 addresses technical vulnerability management but doesn't mandate the speed required here. Your policy probably says "promptly" without defining what that means when exploitation starts in hours.
Monitoring gaps. Organizations that couldn't detect exploitation attempts in real-time had no way to know they were under active attack while waiting for their patch window. NIST CSF function DE.CM-1 (Detect: Continuous Monitoring) requires monitoring for anomalous activity, but if you're not watching for CVE-specific exploitation patterns within hours of disclosure, you're monitoring yesterday's threats.
What Standards Actually Require
PCI DSS v4.0.1 Requirement 6.3.3: Install relevant security patches within one month of release. For critical patches, this drops to "as soon as possible" per the requirement's guidance. Five hours from patch to exploitation means "as soon as possible" now means same-day for internet-facing systems processing cardholder data.
NIST 800-53 Rev 5 SI-2: Flaw remediation requires organizations to install security-relevant patches within time periods defined by organizational assessment of risk. Your assessment needs to account for weaponization speed. If you're still using 30-day windows for critical RCE vulnerabilities, your risk assessment is wrong.
SOC 2 Type II CC7.1: The entity uses detection and monitoring procedures to identify anomalies. If your WordPress instances are in scope for SOC 2, your monitoring must detect exploitation attempts within hours, not days. Your auditor will ask what you detected and when.
ISO/IEC 27001:2022 A.12.6.1: Technical vulnerabilities shall be identified and appropriate measures taken in a timely manner. "Timely" is the weasel word here. Your vulnerability management procedure needs to define timely as "same-day deployment for critical RCE on internet-facing systems."
None of these standards explicitly say "patch in five hours," but they all require you to define timeframes based on risk. When exploitation starts in five hours, your 30-day window fails the risk-based requirement.
Lessons and Action Items
Build a critical patch fast lane. Create a separate process for critical RCE vulnerabilities on internet-facing systems. This process bypasses normal change control and uses automated testing plus production monitoring instead of manual QA cycles. Document this as an exception process in your change management policy. You're not abandoning control; you're acknowledging that the risk of not patching exceeds the risk of a rushed deployment.
Maintain a living asset inventory. You need a script that can list every WordPress instance in your environment within 15 minutes. Tag each with version, internet exposure, and data classification. Update this weekly, not quarterly. If you can't enumerate your WordPress installations faster than attackers can weaponize a vulnerability, you've already lost.
Define "critical" with teeth. Update your vulnerability management policy to explicitly state that critical RCE vulnerabilities on internet-facing systems require same-day patching. Include language about automated deployment, compressed testing windows, and emergency change control. Get this approved by your CISO and your change advisory board before the next CVE drops.
Automate WordPress updates for low-risk instances. That marketing site running WordPress? Enable automatic updates. Yes, this means accepting the risk of an update breaking something. That risk is lower than the risk of a five-hour exploitation window. For high-value instances, use staging environments that auto-update, then promote to production after automated testing.
Monitor for exploitation, not just vulnerabilities. Deploy detection rules for active exploitation attempts. Patchstack saw probing in five hours because they monitor for it. You need the same visibility. Configure your WAF or SIEM to alert on CVE-specific exploitation patterns within hours of patch release. If you're learning about exploitation from your incident response team instead of your monitoring tools, your detection failed.
Test your emergency patch process now. Don't wait for the next WordPress RCE. Pick a non-critical system and run through your emergency patch process. Time how long it takes from "patch available" to "patch deployed." If that number is more than eight hours, you need a faster process. Document what slowed you down and fix it.
The five-hour window from patch to probe isn't an anomaly. It's the new baseline. Your patch management process needs to match this reality, or you're managing yesterday's risks with tomorrow's consequences.
