What Happened
Between January 14 and February 12, 2025, WordPress versions 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 had a remote code execution vulnerability in the core REST API batch endpoint (batch/v1). This flaw allowed attackers to execute arbitrary code on vulnerable installations without authentication. Security researcher Adam Kues reported the issue, and Hadrian's analysis pinpointed the root cause in the batch processing logic. WordPress released patches in versions 6.9.5 and 7.0.2.
Timeline
- January 14, 2025: WordPress 6.9.0 ships with vulnerable batch endpoint code.
- February 12, 2025: WordPress 7.0.1 released, still containing the vulnerability.
- Date unknown: Adam Kues discovers and reports the vulnerability.
- Date unknown: Hadrian identifies the root cause in batch processing.
- Patch release: WordPress releases versions 6.9.5 and 7.0.2 with fixes.
- Current state: Unknown number of installations remain unpatched.
The critical issue isn't the time from discovery to patch, but the delay between patch availability and your deployment.
Which Controls Failed or Were Missing
Vulnerability scanning missed the flaw. Your WordPress installations should be under continuous monitoring. If you're using automated scanners, they failed to catch this before public disclosure. Without scanners, you had no visibility.
Patch deployment was too slow. For a critical RCE affecting the REST API, you need same-day or next-day deployment. If you're still running vulnerable versions, your patch management process failed.
API security controls were inadequate. The batch endpoint accepted unauthenticated requests without proper input validation. Your WordPress configuration should enforce authentication on all API endpoints unless there's a documented reason for public access.
Change management missed the regression. WordPress introduced this vulnerability between versions. Your change review process should flag new API endpoints or modifications, especially in core functionality.
What the Relevant Standard Requires
PCI DSS v4.0.1 Requirement 6.3.3 states: "Security vulnerabilities are identified and addressed" with testing requirements at 6.3.3.1 specifying "all security patches are installed within one month of release." For critical vulnerabilities like RCE, you can't wait a month. This requirement gives you a ceiling, not a target.
OWASP ASVS v4.0.3 Section 14.2.1 requires: "All components are up to date, preferably using a dependency checker during build or compile time." Your WordPress core is a component. If you're not tracking WordPress releases and testing patches in a staging environment, you're not meeting this verification requirement.
ISO/IEC 27001:2022 Control 8.8 addresses technical vulnerability management: "Information about technical vulnerabilities of information systems in use shall be obtained, the organization's exposure to such vulnerabilities evaluated, and appropriate measures taken." Running a known-vulnerable WordPress version means you've failed the "appropriate measures" test.
NIST 800-53 Rev 5 SI-2 (Flaw Remediation) requires: "Install security-relevant software and firmware updates within the time period specified in the organizational security plan." If your security plan says "within 30 days" for critical RCE vulnerabilities, you're not meeting basic hygiene standards.
These standards demand quick patching of critical vulnerabilities, regardless of your workload or the number of WordPress sites you manage.
Lessons and Action Items for Your Team
Build a WordPress inventory today. You can't patch what you don't know exists. Create a spreadsheet with every WordPress installation, its version number, owner, and whether it's internet-facing. Use WPScan or similar tools to automate this. Update it weekly.
Set up automated vulnerability notifications. Subscribe to WordPress security announcements. Configure your scanner to alert on WordPress core vulnerabilities within one hour of disclosure. Don't rely on manual checks.
Create a 24-hour patch window for critical RCE. Your patch management policy should distinguish between "high" and "critical" severity. RCE in a widely deployed platform is critical. Test in staging, deploy to production within 24 hours. If you can't do this, you're not ready for the next WordPress vulnerability.
Harden your REST API configuration. Disable the batch endpoint if you're not using it. Add authentication requirements to all API routes. Use a web application firewall to filter malicious requests. Don't assume WordPress core is secure by default.
Automate your patching pipeline. Manual patching doesn't scale. Use WP-CLI, Ansible, or your configuration management tool to push updates. Test the automation in your staging environment first, then schedule production deployments during maintenance windows.
Document your exceptions. If you can't patch a WordPress site immediately, document why, what compensating controls you've implemented, and when you'll complete the patch. Show this to your auditor when they ask about SI-2 compliance.
Review your API security posture. This vulnerability was in a batch processing endpoint. What other APIs does your WordPress installation expose? Run an API inventory. Test authentication on each endpoint. Verify input validation. Don't wait for the next CVE.
The WordPress REST API vulnerability is not unique. It's a pattern you'll see in other CMS, frameworks, or plugins. Your controls should be robust enough to handle any vulnerability. If you're scrambling to patch WordPress today, you'll scramble for the next issue tomorrow. Fix the process, not just the instance.
