What Happened
In early 2026, Searchlight Cyber discovered two critical remote code execution vulnerabilities in WordPress Core, tracked as CVE-2026-63030 and CVE-2026-60137. These vulnerabilities, known as "wp2shell," affect WordPress versions 6.9.x and 7.0.x. Shortly after disclosure, proof-of-concept exploits appeared on GitHub, making it easy for attackers to exploit them.
The WordPress security team responded by forcing automatic security updates across all affected installations. This bypassed the usual process where administrators decide when to patch. Meanwhile, Cloudflare deployed temporary WAF rules to block exploitation attempts while sites updated.
Timeline
Here's what we know about the timeline:
- Discovery: Searchlight Cyber identified the vulnerabilities in WordPress Core.
- Disclosure: The WordPress security team was notified.
- Public Exploit Release: Proof-of-concept code was published on GitHub.
- Forced Updates Deployed: WordPress enabled automatic security updates for versions 6.9.x and 7.0.x.
- WAF Protections Activated: Cloudflare implemented temporary rules to block exploitation attempts.
The gap between the public exploit release and forced updates was a critical window where unpatched WordPress installations were vulnerable.
Which Controls Failed or Were Missing
This incident highlights three control failures:
Vulnerability Management: Organizations using WordPress didn't patch within hours of the exploit release. If your patching SLA is "monthly" or "within 30 days," you're at high risk for internet-facing applications. Once exploit code is public, your window closes.
Change Control vs. Security Urgency: Teams requiring extensive testing or approval workflows couldn't respond quickly. Your change management process needs an emergency bypass for critical security updates with public exploits.
Dependency Visibility: Many organizations aren't aware they're running WordPress or which version. If you can't list all WordPress installations within 15 minutes, you can't patch them in time.
What the Relevant Standard Requires
PCI DSS v4.0.1 Requirement 6.3.1 mandates identifying security vulnerabilities and assigning a risk ranking. Requirement 6.3.3 states critical security patches must be installed within one month of release. However, when public exploits exist, one month is too long.
NIST CSF v2.0 under the Protect function (PR.IP-12) calls for a vulnerability management plan addressing newly discovered vulnerabilities. While it doesn't specify timelines, a risk-based approach demands faster action when exploit code is public.
ISO/IEC 27001:2022 Control 8.8 requires obtaining timely information about technical vulnerabilities and evaluating exposure. The standard expects action in response to risk, which increases with exploit availability.
These standards assume you have time to test and plan. Public exploits eliminate that buffer. Your vulnerability management policy needs explicit language about emergency patching when exploitation is active or imminent.
Lessons and Action Items for Your Team
Build a Public-Exploit Response Playbook
Document your process for handling vulnerabilities with public exploits:
- Who gets notified within 30 minutes of a public exploit release?
- What's your decision tree for emergency patching versus temporary mitigation?
- Which approvals can you bypass in a security emergency?
- How do you roll back if the patch breaks production?
Test this playbook quarterly. If you can't execute emergency patches outside business hours, you'll be vulnerable outside business hours.
Deploy Automated Inventory for Third-Party Software
You need real-time answers to "where are we running X?" Build continuous asset discovery that identifies:
- Web frameworks and CMS platforms (WordPress, Drupal, Joomla)
- Version numbers, not just "WordPress is installed"
- Internet-facing versus internal instances
- Ownership and contact information for each installation
If you're using WordPress, implement the WP-CLI across all instances to query versions and apply updates programmatically.
Implement Tiered Patching SLAs
Replace your single "patch within 30 days" policy with risk-based tiers:
- Tier 1 (public exploit + internet-facing): Patch within 24 hours or implement compensating controls
- Tier 2 (CVSS 9.0+ without public exploit): Patch within 7 days
- Tier 3 (CVSS 7.0-8.9): Patch within 15 days
- Tier 4 (everything else): Patch within 30 days
Document compensating controls for Tier 1 situations. In this incident, that meant Cloudflare WAF rules or temporarily disabling REST API access. You need pre-approved options you can deploy while patches are tested.
Enable Automatic Security Updates Where Possible
WordPress's forced update decision protected millions of sites whose administrators weren't monitoring security advisories. Evaluate where you can enable automatic security updates:
- Does your CMS support automatic security-only updates?
- Can you auto-patch container base images in non-production environments?
- What about security updates for dependencies in your CI/CD pipeline?
Yes, automatic updates can break things. But unpatched RCE vulnerabilities definitely break things. Choose your risk.
Test Your Emergency Communication Chain
When CVE-2026-63030 and CVE-2026-60137 hit, who on your team knew about it within the first hour? Run a tabletop exercise: at 2 AM on a Saturday, GitHub publishes exploit code for a critical flaw in software you use. Map out:
- How the security team learns about it
- How you identify affected systems
- Who has authority to approve emergency patches
- How you notify application owners
- What you tell executive leadership
The WordPress security team made the hard call to force updates because they knew most administrators wouldn't act fast enough. Don't put yourself in a position where someone else has to make that call for you.
