WordPress Update Vulnerability Exposes Sites During Fix Installation

Some WordPress sites remain vulnerable to attacks while installing a fix for an actively exploited flaw, as reported by Umut Bayram, a researcher at Picus Security.

The update intended to address the flaw unpacks its files using the site’s existing, unpatched code, allowing attackers to execute code on the server if they strike at the right moment. Bayram recommends blocking web access to the site’s wp-content/upgrade folder prior to updating.

The vulnerability, tracked as CVE-2026-119977, affects WordPress versions 4.7 through 7.1.3. During a core update, WordPress unpacks a copy of the new version into a temporary folder within wp-content/upgrade, which includes the WordPress installer accessible to the web server.

An attacker without an account can exploit this by identifying the folder’s name and accessing the installer before WordPress deletes the copy. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) recently added this flaw to its catalog of known exploited vulnerabilities.

WordPress released a fix in version 7.1.4 and corresponding updates for older branches back to 4.7, detailed in its security advisory. The fix assigns a random name to the temporary folder, but the update still uses the old code present on the site to unpack its files. On sites running version 5.9 or later, this old code names the folder after the downloaded file, allowing for predictable naming.

Before the fix, an attacker could exploit the installer to create a new configuration file, wp-config.php, within the temporary copy, resulting in the update overwriting the site’s actual file with a malicious one. The fix prevents this during the update that installs it, as WordPress uses the new code to copy the files into place.

Bayram explains that if an attacker exploits the timing during the update, they can set up the temporary copy of WordPress with their own database and execute PHP code with the web server’s permissions before the copy is deleted, potentially allowing them to read or write files on the live site.

Who Is Exposed During the Update

Not every update exposes the installer. Complete packages include the installer files, while a smaller partial package only exposes a site if it contains those files. For sites allowing automatic background updates, WordPress installs the fix automatically using the same updater.

The Hacker News checked WordPress.org’s update service for various versions. For updates within a branch, such as from 7.1.3 to 7.1.4, it provided a partial package. However, for updates from an older branch, such as from 7.0.7 to 7.1.4, only complete packages were offered.

Once version 7.1.4 or a branch fix is installed, subsequent updates utilize a random folder name, and a wp-config.php file in the temporary copy is never copied over the actual one.

What to Do Before Updating

Bayram recommends preventing the web server from serving wp-content/upgrade entirely. Blocking web access does not disrupt updates.

• Block the folder in the web server configuration. For Nginx, add location ^~ /wp-content/upgrade/ { deny all; }. For Apache, include Require all denied inside a block for that folder.
• If only .htaccess can be edited, add RedirectMatch 403 ^/wp-content/upgrade/ to the .htaccess file in the WordPress root.
• Avoid placing an .htaccess file inside wp-content/upgrade, as the old updater deletes everything in that folder before unpacking an update.
• Ensure that a request to /wp-content/upgrade/ returns a 403 error.
• Update to version 7.1.4 or the fixed release for your branch.

Another safe approach is to perform a manual update outside the web root. This involves backing up the site files and database, unpacking the new release in a folder not accessible to the web server, and then executing the WordPress database update.

WordPress versions 4.6 and earlier no longer receive security updates, leaving them without a fix. Bayram notes that this flaw dates back to WordPress 2.7, released in 2008, urging those sites to upgrade to a supported version.

Attacks and What to Check

CISA’s addition of the flaw to its catalog was based on evidence of active exploitation. Wordfence reported seeing attack attempts begin shortly after deploying a firewall rule for the flaw. Its score for the flaw in the CVE record is 8.1 out of 10 on the CVSS scale.

For sites that remained on an affected version after the release, Wordfence suggests monitoring for:

• unexpected requests to PHP files under wp-content/upgrade
• unfamiliar administrator accounts
• plugins that were not installed
• PHP files in wp-content/upgrade that were not placed there by the site owner

Bayram informed The Hacker News that whether a partial update is exposed depends on the specific package contents. A partial package only includes files that changed between two releases, and if those do not contain the installer files, the temporary copy cannot operate as a WordPress installation.

The determining factor is whether the updater already installed on the site has been fixed.

 

Source: The Hacker News