# WordPress: the race between extraction and cleanup during an update

> A WordPress core archive extracted into a predictable web-served directory created an RCE window. We explain the race, conditions and fixes.

Published: 2026-11-05  
Canonical: https://rootzero.eu/en/research/wordpress-update-race-rce-2026/

**Fixed on October 28, 2026; detailed advisory published October 29.** The [WordPress vulnerability](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-4w3m-c66w-69mg) arises during a core update. When an update uses a full package, new files were extracted to a predictable directory inside the web-served `upgrade` folder. An unauthenticated attacker who won the race against cleanup could execute code on the server. The risk comes from the temporary exposure of legitimate files during the update procedure.

## The trust boundary crossed by the archive

An update needs a workspace: receive an archive, extract it, check or move the files, then clean up. These steps are not atomic. Between two server operations, an HTTP client can send requests. If the temporary space is located under a root published by the web server, its contents may become addressable before WordPress has finished installing or removing it.

The [official notice](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-4w3m-c66w-69mg) establishes two specific elements: the extraction path was **predictable** and was in a folder **served by the web**. The combination gives the attacker a temporal target and an access route. The race is of the type *time of check to time of use*: the expected safety of the global sequence does not necessarily hold for each intermediate state visible by HTTP. Success depends on when the files exist and how the server processes them; the advisory does not provide a universal window length or a guarantee of success in each attempt.

This point is more subtle than an ordinary file drop. The attacker does not necessarily have to control the official package; it aims for the transient presence of extracted files in an accessible location. The WordPress publication affirms the possibility of RCE, but does not provide in its text a complete PoC nor all the configuration particularities that lead from file access to execution. We do not transform this conclusion into a recipe independent of the Web server, PHP and the upgrade procedure.

## Why a short window remains relevant

An update only happens occasionally, but WordPress installations are numerous and automatic updates can be predictable across a population of sites. An actor can repeat requests or monitor for signs of an update in progress; this describes the logic of a racing attack, not a measured success rate for this flaw. The risk mainly concerns sites where the web process can serve the temporary folder and where a complete package is used, conditions explicitly mentioned by WordPress.

The advisory record requires careful dating: the [WordPress GitHub advisory](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-4w3m-c66w-69mg), posted on October 29, still stated "No known CVE", while later alerts named **CVE-2026-119977** and reported active exploitation. These documents describe the same flaw at different points in its disclosure. We date each claim and link it to the project's technical advisory.

## How to identify it in an authorized audit

The search begins with a map of the updater states: paths created, permissions, temporary directory, HTTP routing, extraction, renaming and deletion. We can instrument an update on a test environment and record, at each step, which files can be accessed from an HTTP session without authentication. A differential test between vulnerable version and corrected version must show the disappearance of the exposed state. To establish the RCE, it is then necessary to demonstrate the exact passage of an accessible file to execution in the tested configuration; just observing an HTTP response on a temporary path is not enough.

This research protocol is not attributed to the discoverer. WordPress thanks [Umut Bayram](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-4w3m-c66w-69mg) for the report, but the notice does not give all of its experimental steps. The generalizable lesson is to test the **transient states** of a maintenance operation, as well as its final result.

## Correction and operational control

Version **7.1.4** fixes the flaw; WordPress also reports [backported fixes](https://wordpress.org/documentation/wordpress-version/version-7-1-4/) up to affected 4.7 branches. A useful check is the version of the core actually in production, the update channel, permissions and HTTP exposure of the working folder. A successful update today reduces future exposure; it does not alone prove that no query benefited from a previous update. Web logs around update windows and file integrity remain the elements to examine in case of suspicion.

The lesson goes beyond WordPress: placing a temporary staging area in a public directory turns time into an attack surface. The fix must remove the dangerous state, and the test must observe the intermediate times when this state could reappear.

**Main sources:** [advisory WordPress](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-4w3m-c66w-69mg), [WordPress 7.1.4 notes](https://wordpress.org/documentation/wordpress-version/version-7-1-4/), [NCSC-NL alert on CVE-2026-119977](https://www.ncsc.nl/alerts/kwetsbaarheid-in-wordpress-core-met-actief-misbruik-update-nu).