WordPress update race condition with RCE draws exploit attempts

📌 Later developments: WordPress CVE-2026-119977: CISA confirms active exploitation (November 3, 2026)

On 28 October 2026 WordPress released version 7.1.4, which, among other fixes, closes a race condition in the core update process that can be exploited without authentication to execute code remotely. According to Defiant, the company behind Wordfence, the first exploitation attempts arrived within hours of the patches being released. The story is reported by SecurityWeek, heise Security and The Hacker News; the technical details that follow come from the SecurityWeek article, which quotes Defiant’s analysis and is the only full text we were able to analyse.

What happened

During an update, WordPress unpacks the files of the new version into a temporary staging directory before installing them. According to Defiant, the path of this directory is predictable and, on many servers, reachable from the web. For a few seconds, until WordPress cleans up the temporary files, an attacker who knows or guesses the path can reach the freshly unpacked files, including those of the installer.

When the sources were published no CVE had been assigned yet. Defiant rates the flaw as high severity, but with high attack complexity.

Technical details

• Product: WordPress core, update process.
• Fixed version: 7.1.4; according to SecurityWeek the fix was also backported to older branches, as far back as 4.7.
• Type: race condition leading to remote code execution (RCE), with no account on the site required.
• Conditions, according to Defiant: an update using the full package, which also contains the installer files; public web access and PHP execution in the staging directory; a predictable or discovered staging path; and enough time to complete the attack before WordPress deletes the temporary files.
• Fix: 7.1.4 randomises the staging directory name, adds a protective index file and prevents the unsafe promotion of configuration data found in the staged copy.
• MITRE ATT&CK: T1190 (Exploit Public-Facing Application).

The exploitation window therefore opens only while the site is updating with a full package. That is why, according to Defiant, attackers keep polling the vulnerable paths, hoping to land in those few seconds. The observed requests target setup-config.php, the script WordPress uses to create its initial configuration, inside the staged copy. The available sources do not describe the full chain from reaching the file to code execution.

In total, 7.1.4 fixes 22 security issues, including several XSS flaws, Interactivity API issues, an unauthenticated information disclosure and an authorisation weakness. It also updates the bundled root certificates following the recent eMudhra revocation.

Exploitation attempts: what the sources say

According to Defiant, the first request caught by the new Wordfence firewall rule arrived nine minutes after the rule went live; in the first 21 hours its telemetry recorded more than 18,500 requests targeting setup-config.php paths in the staged copy. The Hacker News, on the other hand, headlines nearly 63,000 attempts in 24 hours: the article text was not available and we do not know which requests were counted, so the two figures are not directly comparable. heise Security also reports observed exploitation attempts.

Wordfence has not reported any successful compromises.

Impact for European and Italian organisations

WordPress powers many corporate websites, service portals and online shops, often managed by agencies or hosting providers. The high complexity lowers the odds of any single attempt succeeding, but scanning is automated and continuous: every full update run on a server where the staging directory is reachable from the web becomes an opportunity. A successful attack leads to code execution on the server, with access to pages, the database and data submitted through forms.

For entities in scope of NIS2, the compromise of an exposed website is an event to assess for notification to the national CSIRT (in Italy, CSIRT Italia at ACN); if the database holds personal data, the 72-hour notification to the data protection authority required by the GDPR must also be considered. Healthcare providers and public administrations using WordPress for bookings or online forms should start with those sites.

What to do now

1. Inventory: list every WordPress installation in the organisation, including test sites and those managed by agencies or external providers, and ask the latter for written confirmation of the update.
2. Update to 7.1.4, or to the fixed release of your branch if you run an older version. Check the version in the dashboard or with wp core version.
3. Block web access to the staging directory (general good practice, not stated by the sources). WordPress updates normally use wp-content/upgrade/: denying HTTP access and PHP execution in that directory at the web server removes the public-access condition, even during an update. The sources do not say whether the update to 7.1.4, run from a vulnerable version, opens the window itself: as a precaution, apply the block before updating.
4. Check your WAF: if a web application firewall sits in front of your sites, make sure its WordPress rules are up to date.
5. Look for traces in the web server logs: requests to setup-config.php outside its normal path, especially under wp-content/upgrade/, and above all 200 responses in the minutes around an update.
6. Check integrity: wp core verify-checksums, recent changes to wp-config.php, new administrator accounts, unexpected PHP files in wp-content/. If you find traces, isolate the site, preserve the logs, restore from a clean backup, change passwords, database credentials and secret keys, then assess your notification obligations.

How ARXDOME helps

ARX Expose shows which services your organisation exposes on the Internet and which products are recognised on them, including forgotten WordPress sites. With ARX Scout Assessment, on request and with your authorisation, a non-invasive vulnerability assessment flags outdated software and exposed admin panels. ARX Sentry collects logs and events from monitored servers, useful for hunting requests to installer paths.

Last updated: 30 October 2026