What Happened
On July 17, 2025, attackers exploited critical vulnerabilities in WordPress's REST API batch-processing feature to install webshells and malicious plugins on unpatched sites. SearchLight Cyber disclosed the vulnerability chain, called wp2shell, which lets authenticated attackers bypass security controls and execute arbitrary code on WordPress servers. WordPress released patches in versions 7.0.2, 6.9.5, and 6.8.6, but attacks began at 23:29 UTC on July 17, just hours after public disclosure.
The attack manipulates the REST API's batch endpoint to chain multiple requests, escalating privileges and installing backdoors. Once compromised, attackers maintain access through webshells hidden in seemingly legitimate plugin files.
Timeline
Pre-disclosure: Vulnerability exists in WordPress core, affecting all versions before the July patches.
July 17, 23:29 UTC: Wiz researchers observe first exploitation attempts. Attackers scan for vulnerable WordPress installations and start deploying webshells.
July 18-20: Mass scanning continues. Attackers target sites that haven't applied the emergency patches.
Week of July 21: Macnica researcher Yutaka Sejiyama reports an 81.6% patch rate across a sample of 124,580 websites, leaving about 23,000 sites vulnerable in that sample.
Ongoing: Exploitation attempts persist against unpatched installations. Automated WordPress updates help contain the spread, but manually managed sites remain at risk.
Which Controls Failed or Were Missing
Patch Management Process: The 18.4% of sites that remained unpatched lacked either automated update mechanisms or a rapid emergency patching process. Organizations managing multiple WordPress installations had no centralized inventory or deployment pipeline.
REST API Security Controls: Sites with default REST API configurations lacked rate limiting, authentication requirements for batch endpoints, and monitoring of suspicious API request patterns. The batch-processing feature operated without granular permission checks.
Change Detection: Compromised sites failed to detect unauthorized plugin installations or modifications to core files. Without file integrity monitoring, webshells went undetected until actively used in attacks.
Network Segmentation: WordPress installations with direct internet exposure and no web application firewall (WAF) lacked defense-in-depth layers to block or flag exploit attempts before reaching the application.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.3 mandates applying security patches within one month of release for external-facing systems. For critical vulnerabilities with active exploitation, apply emergency patches immediately or implement compensating controls. Delaying while attackers scan your infrastructure doesn't meet this requirement.
Requirement 11.6.1 requires a change-detection mechanism to alert on unauthorized modifications to critical files. If attackers install webshells in your WordPress plugin directory and you don't detect it, you're out of compliance. File integrity monitoring isn't optional for payment processing environments.
OWASP ASVS v4.0.3 Section 14.2 covers API security requirements. Your REST API endpoints need authentication, authorization checks for each operation, and rate limiting to prevent abuse. The batch-processing feature that wp2shell exploited would fail ASVS verification at Level 2.
ISO/IEC 27001:2022 Control 8.8 (management of technical vulnerabilities) requires maintaining an inventory of assets, monitoring vulnerability disclosures, assessing risk, and applying patches based on urgency. If you don't know which WordPress sites you're running or can't push patches within hours of a critical disclosure, your vulnerability management process has gaps.
NIST CSF v2.0 function PR.IP-12 (a vulnerable system is removed from service or protected until patched) means you either patch immediately or take the site offline. Running a known-vulnerable WordPress installation with active exploitation isn't an acceptable risk posture.
Lessons and Action Items for Your Team
Build a WordPress inventory today. You can't patch what you don't know exists. Use network scanning tools to discover all WordPress installations in your environment, including shadow IT deployments. Document versions, plugin lists, and who owns each site.
Enable automatic updates with testing. WordPress's auto-update feature helped achieve that 81.6% patch rate. For production sites where you need testing first, set up a staging environment that gets updates immediately, then promote to production within 24 hours. Configure your deployment pipeline to handle emergency patches outside the normal release schedule.
Implement file integrity monitoring on WordPress directories. Monitor /wp-content/plugins/, /wp-content/themes/, and core WordPress files for unauthorized changes. Tools like AIDE, Tripwire, or cloud-native FIM services can alert you within minutes of a webshell installation. Set up alerts that page your security team, not just log entries that get reviewed weekly.
Deploy a WAF with virtual patching rules. When you can't patch immediately, a WAF can block known exploit patterns. Configure rules to inspect REST API requests for suspicious batch operations. Update your WAF rules within hours of vulnerability disclosures; security vendors typically release virtual patches before you can deploy code changes.
Restrict REST API access. If you're not using the batch-processing endpoint, disable it. Implement authentication for all API operations, not just administrative functions. Add rate limiting to prevent automated scanning and exploitation attempts.
Test your emergency patching process. Run a tabletop exercise where you simulate a critical WordPress vulnerability disclosure at 5 PM on a Friday. How long does it take to identify affected sites, deploy patches, and verify successful updates? If the answer is "we'd figure it out when it happens," you're not ready for the next wp2shell.
The five-hour window between disclosure and exploitation isn't getting longer. Your response time needs to get shorter.
