On a Tuesday morning, WordPress released security updates for 25 version branches due to CVE-2026-87902, a path traversal flaw that lets unauthenticated attackers execute arbitrary PHP code on vulnerable servers. WordPress rated it 9.2 out of 10 on CVSS v4. The attacker needs no account on the site and no action from anyone who has one.
If you're running WordPress 4.7.0 through 7.1.1, you're exposed. Version 7.1.2 contains the fix, with patches backported to 24 older branches, from 7.0.6 down to 4.7.37.
What Happened
An unauthenticated path traversal vulnerability allowed attackers to write arbitrary PHP files to the server filesystem. Once written, these files execute with web server privileges, giving the attacker full control over the WordPress installation and potentially the underlying host.
The vulnerability existed in WordPress's file handling routines. No credentials required. No user interaction needed. Just craft the right HTTP request and you're in.
Timeline
WordPress hasn't published a detailed discovery timeline, but the response pattern is clear:
- Discovery: Vulnerability identified in core file handling
- Patch development: Fix created for current version (7.1.2)
- Backporting: Same fix applied to 24 legacy branches in parallel
- Release: All 25 patched versions published simultaneously
- Disclosure: CVE assigned and public advisory issued
The backporting effort matters. WordPress didn't just fix the current release. They patched every supported version back to 4.7.0, a branch first released years ago.
Which Controls Failed
Unauthenticated file write operations. The application allowed file system writes without verifying the caller's identity or authority. This violates basic input validation and authorization principles.
Path traversal protections. The code didn't properly sanitize file path inputs, allowing attackers to escape intended directories and write to arbitrary locations.
Defense in depth. A single vulnerability shouldn't grant complete system access. Missing controls at the filesystem, application, and infrastructure layers compounded the impact.
Automated patch deployment. Organizations running outdated WordPress versions had no technical reason to delay updates. The failure was operational, not technical.
What Standards Require
PCI DSS v4.0.1 Requirement 6.3.1: "Security vulnerabilities are identified and addressed." If you process payments on a WordPress site, you're required to identify and remediate vulnerabilities. A 9.2 CVSS score qualifies as critical under any risk framework.
PCI DSS v4.0.1 Requirement 6.3.2: "An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained." WordPress is third-party software. If you don't know which version you're running, you can't patch it.
ISO/IEC 27001:2022 Control 8.8: "Management of technical vulnerabilities." You need a documented process to identify, evaluate, and treat vulnerabilities. That process must handle both discovery and remediation timelines.
NIST CSF v2.0 PR.IP-12: "A vulnerability management plan is developed and implemented." The plan should define SLAs for critical patches. A 9.2 CVSS vulnerability demands hours, not weeks.
OWASP ASVS v4.0.3 Section 5.2: "File integrity requirements." Applications must validate file uploads and restrict write operations to authorized users. CVE-2026-87902 violates both principles.
Lessons and Action Items
1. Set patch SLAs based on CVSS scores
CVSS 9.0+ vulnerabilities get 24-48 hours maximum. CVSS 7.0-8.9 get one week. CVSS 4.0-6.9 get 30 days. Document these SLAs and track compliance. Your auditor will ask for evidence.
2. Build a software inventory that includes versions
You can't patch what you don't track. Your inventory needs:
- Application name and version
- Installation location (server, container, VM)
- Owner (team or individual)
- Update mechanism (manual, auto-update, package manager)
- Last patch date
Update this inventory automatically. Manual spreadsheets go stale in days.
3. Test auto-updates in staging first
WordPress offers automatic updates. Many teams disable them because they fear breaking custom themes or plugins. The solution isn't to disable auto-updates, it's to run staging environments.
Deploy auto-updates to staging. Monitor for 24 hours. If nothing breaks, promote to production. If something breaks, you've got time to fix it before attackers exploit the vulnerability in production.
4. Backport security fixes to legacy systems
WordPress backported this fix to 24 older versions. You should do the same for your internal applications. When you discover a vulnerability in current code, check whether the same flaw exists in older branches still running in production.
If you can't patch a legacy system immediately, implement compensating controls: WAF rules, network segmentation, enhanced monitoring. Document why you're running legacy software and when you'll decommission it.
5. Monitor vulnerability feeds for your stack
Subscribe to security advisories for every component in your stack. For WordPress:
- WordPress Security Team blog
- CVE feeds filtered for "WordPress"
- Plugin and theme vendor advisories
Route these feeds to your ticketing system. Assign them to specific teams. Track time-to-patch as a KPI.
6. Verify your incident response plan covers RCE
Remote code execution is a worst-case scenario. Your IR plan should specify:
- Who gets paged for CVSS 9.0+ vulnerabilities
- Maximum time to initial assessment
- Authority to take systems offline
- Communication templates for customers and executives
Run a tabletop exercise quarterly. Use real CVEs like this one as scenarios.
The fix for CVE-2026-87902 exists. It's been backported to every supported version. If you're still vulnerable, the problem isn't technical, it's operational. Fix your patch management process, not just this vulnerability.
