63,000 Attacks in a Day: Teardown of the WordPress Core RCE

What happened

A high-severity remote code execution flaw in WordPress Core, affecting versions 4.7 through 7.1.3 with a CVSS score of 8.1, has led to mass exploitation attempts. Wordfence blocked 62,969 attacks targeting this vulnerability in just one day.

The flaw stems from a design weakness in how full-package core upgrades stage files. During an upgrade, WordPress uses predictable, web-accessible staging paths. An unauthenticated attacker who knows these paths can request or write to them while the upgrade is running. If the attacker times it right, they can execute code on the server.

The timing requirement is why the CVSS score is 8.1 instead of higher. However, the attack volume shows that attackers aren't deterred by this. They can automate guessing and timing at scale when the path is predictable.

Timeline

This overview focuses on established facts. For detailed disclosure and patch dates, check your vendor advisory.

1. Vulnerability exists in Core since version 4.7, affecting releases up to 7.1.3.
2. Flaw disclosed and rated at CVSS 8.1, with the staging-path mechanism described publicly.
3. Mass exploitation begins. Wordfence blocked 62,969 attempts within a 24-hour window.
4. Defenders face a narrow gap between disclosure and automated scanning. Sites updating weekly or monthly remain exposed during this gap.

The key takeaway isn't a specific date but the sequence: disclosure, then immediate automated attack traffic. Your patch cycle competes with attacker tooling, not research time.

Which controls failed or were missing

1. Predictable, web-accessible staging paths. This design flaw allows attackers to anticipate and access temporary directories used during upgrades. Fixing either the predictability or web exposure would significantly increase the cost of exploitation.

2. A race condition in the upgrade window. The exploit works only if the attacker acts during the upgrade. This creates a state where files are accessible before integrity or access controls are applied.

3. Slow patch adoption. The flaw spans versions 4.7 through 7.1.3. Sites delaying core updates remain vulnerable. Sites with auto-updates disabled for "stability" reasons are most at risk.

4. Detection relying on a third party. The 62,969 blocked attempts were visible because a security vendor operates a firewall across many sites. Without independent monitoring, you're blind to what's hitting your own origin.

5. Writable web roots. Core upgrades require the web server process to write to the application directory, granting more privilege than a read-only serving process should have.

What the relevant standards require

Map each failure to a requirement your auditor can test.

PCI DSS v4.0.1

• Requirement 6.3.3 mandates installing critical or high-security patches within one month of release. An 8.1 CVSS flaw requires a monthly patch cadence as the maximum, not the goal.
• Requirement 6.3.1 requires identifying and ranking vulnerabilities using industry-recognized sources.
• Requirements 6.4.1 and 6.4.2 involve protecting public-facing web applications through vulnerability assessment or continuous automated solutions.
• Requirement 10.4.1.1 requires automated audit log review mechanisms.

OWASP Top 10 (2021)

• A06: Vulnerable and Outdated Components covers running unpatched core software.
• A04: Insecure Design involves predictable, exposed staging paths.
• A05: Security Misconfiguration applies to web-accessible temporary directories and permissive write access.

OWASP ASVS v4.0.3

• V12 (Files and Resources) addresses controlling file access and preventing direct access to non-public files.
• V14 (Configuration) involves hardening the build and deployment process.

ISO/IEC 27001:2022

• Annex A 8.8 requires obtaining timely vulnerability information and taking action.
• Annex A 8.16 requires monitoring networks, systems, and applications for anomalies.

SOC 2 Type II

• CC7.1 covers detection and monitoring for new vulnerabilities, and CC7.2 covers monitoring for anomalies indicating malicious acts.

NIST Cybersecurity Framework (CSF) v2.0

• ID.RA (Risk Assessment) and DE.CM (Continuous Monitoring) are the relevant outcome categories.

Lessons and action items for your team

Shorten the patch window by decision, not by effort. Implement a rule that any high-rated core CMS flaw is patched on an accelerated schedule, measured in days. Treat the PCI one-month limit as a ceiling. Enable automatic core updates for minor and security releases, testing them in staging to mitigate fear of breakage.

Inventory your WordPress estate. You can't patch what you don't know. Include marketing microsites, acquired-company blogs, and forgotten campaign pages. Record the Core version for each, flagging anything within the affected range.

Block staging paths at the edge. Deny public HTTP access to upgrade and temporary directories at the web server or reverse proxy. Restrict wp-admin and update endpoints by IP or VPN where possible. This addresses the exposed-path weakness even before patching.

Close the race window operationally. Run core upgrades during maintenance windows with the site in maintenance mode or fronted by a rule blocking external requests until the upgrade completes.

Tighten file permissions after upgrades. Don't leave the web server identity with write access across the web root. Where possible, push updates through CI/CD to an immutable release, keeping the runtime filesystem read-only.

Build your own detection, not just a vendor's. Alert on bursts of requests to upgrade-related paths, unexpected file creation inside the web root, and new PHP files appearing outside expected directories. Feed web server logs into your SIEM and write rules for repeated hits on staging paths from a single source. This satisfies PCI DSS Requirement 6.4.2 and 10.4.1.1 with evidence you control.

Test the response, not just the tooling. Conduct a tabletop exercise where a high-severity CMS flaw appears on a Friday. Determine who decides to patch, who can change the WAF, and how long until every site is verified. Gaps in that chain define your real patch window.

The staging path was predictable, the timing gap was exploitable, and attackers were already automated. Your defenses must be just as fast and automatic.