admin
Some WordPress sites can still be attacked while they install the fix for an actively exploited flaw, according to Umut Bayram, the Picus Security researcher who found it.
The update that installs the fix still unpacks its files using the site’s old, unpatched code, so an attacker who strikes at the right moment can run code on the server. The researcher advises blocking web access to the site’s wp-content/upgrade folder before updating.
The flaw, tracked as CVE-2026-119977, affects WordPress 4.7 through 7.1.3. During a core update that uses a complete package, WordPress unpacks a copy of the new version into a temporary folder inside wp-content/upgrade. That copy includes the WordPress installer, and the web server can usually reach it.
An attacker with no account who can determine the folder’s name and access the installer before WordPress deletes the copy can end up running code on the server. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its catalog of known exploited vulnerabilities earlier this week.
WordPress released the fix last week in version 7.1.4 and in matching updates for older branches back to 4.7, all listed in its security advisory.
The fix gives the temporary folder a random name. But the update that installs the fix unpacks its files using the old code already on the site, as WordPress’s updater code shows. On sites running 5.9 or later, that old code names the folder after the downloaded file, so the name can be predicted one last time.
Before the fix, an attacker could use the installer to write a new configuration file, wp-config.php, into the temporary copy. The update would then overwrite the site’s real file with that file. The part of the fix that stops this already works during the update that installs it, because WordPress copies the files into place using the new code.
An attacker who catches the window during that update can still set up the temporary copy of WordPress with their own database, log in to it, and run PHP code with the web server’s permissions before the copy is deleted, Bayram says in his technical write-up. From there, the attacker can read or write files in the live WordPress site.
Who Is Exposed During the Update
Not every update exposes the installer, the researcher says. Complete packages always include the installer files. A smaller partial package, built for one specific starting version, exposes a site only if it happens to contain them.
On sites that allow automatic background updates, WordPress installs the fix automatically, via the same updater and the same steps.
The Hacker News checked WordPress.org’s update service today for several versions. For updates within a branch, such as from 7.1.3 to 7.1.4, it offered a partial package, including for automatic updates. For a move from an older branch, such as from 7.0.7 to 7.1.4, it offered only complete packages.
On 4.4 through 5.8, the old code adds random characters to the folder’s name. That hides the name unless the site leaks it some other way, such as in an error message, the researcher says.
Once 7.1.4 or a branch fix is installed, later updates use a random folder name, and a wp-config.php file in the temporary copy is never copied over the real one.
What to Do Before Updating
The researcher’s first recommendation is to stop the web server from serving wp-content/upgrade at all. WordPress works with that folder directly on disk, so blocking web access does not break updates, he says.
- Block the folder in the web server configuration. On Nginx, add location ^~ /wp-content/upgrade/ { deny all; }. On Apache, add Require all denied inside a
block for that folder in the virtual host configuration. - If you can only edit .htaccess, add RedirectMatch 403 ^/wp-content/upgrade/ to the .htaccess file in the WordPress root, above the WordPress rewrite rules.
- Do not put an .htaccess file inside wp-content/upgrade itself. The old updater deletes everything in that folder before it unpacks an update, so the file would be gone when it is needed.
- Confirm that a request to /wp-content/upgrade/ returns a 403 error.
- Update to 7.1.4 or to the fixed release for your branch.
The other safe route, he says, is a manual update done outside the web root, the folder the web server serves. Back up the site files and database, unpack the new release in a folder the web server does not serve, copy the core files into place without touching wp-config.php or wp-content, and then run the WordPress database update. This way, no temporary installer is ever created in a folder the web can reach.
WP-CLI’s wp core update command is no substitute, because it runs the same updater and unpacks the package into the same folder.
WordPress 4.6 and earlier no longer receive security updates, so there is no fix for them. The researcher says the flaw goes back to WordPress 2.7, released in 2008, and that those sites should move to a supported version.
Attacks and What to Check
CISA’s catalog addition earlier this week was based on evidence of active exploitation, but the agency did not describe the attacks.
Wordfence, the WordPress security company that assigned the CVE identifier, saw attack attempts begin nine minutes after it deployed a firewall rule for the flaw on the day of the release. Two of the busiest sources kept checking small groups of sites for about 14.5 hours, which the company says, in its attack analysis, aligns with attempts to catch the moment a site updates.
Its score for the flaw in the CVE record is 8.1 out of 10 on the CVSS scale. In its lab tests, the window lasted only seconds. WordPress’s own advisory rates the flaw low.
Code that its authors describe as an exploit for the flaw has appeared in public GitHub repositories since earlier this week. One of them says its code also works on sites that still use a predictable folder during complete-package updates. Whether the code works has not been established.
For sites that stayed on an affected version after the release, Wordfence suggests looking for:
- unexpected requests to PHP files under wp-content/upgrade
- administrator accounts no one recognizes
- plugins no one installed
- PHP files in wp-content/upgrade that no one put there
Update
Bayram told The Hacker News on November 6 that whether a partial update is exposed depends on what that specific package contains. A partial package holds only the files that changed between two releases. If those do not include the installer files, the temporary copy cannot run as a WordPress installation, and the installer never becomes reachable.
A site also does not always get a partial package when one exists. WordPress falls back to a complete package if the site’s core files do not match the official checksums or if the update is a reinstall.
The deciding factor, the researcher said, «isn’t partial versus complete. It’s whether the updater already installed on the site has been fixed.»
