WordPress Security Update Could Expose Websites to Hackers During Installation of Critical Fix

Website administrators using WordPress have been warned about a security risk that could allow hackers to compromise their websites while installing an update designed to fix an actively exploited vulnerability.

The warning was issued by cybersecurity researcher Umut Bayram of Picus Security, who discovered that some WordPress websites remain vulnerable during the process of installing a security patch because the older, unpatched updater code is still used to unpack the new files.

The vulnerability, tracked as CVE-2026-119977, affects WordPress versions 4.7 through 7.1.3 and could allow unauthenticated attackers to execute malicious code on affected servers under certain conditions.

The issue creates a narrow window of opportunity for attackers to exploit a website while its administrator is installing the security update.

According to Bayram, when WordPress performs a complete core update, it extracts the downloaded package into a temporary directory located inside the website’s wp-content/upgrade folder.

The temporary directory contains the WordPress installation files, including the installer, which may be accessible through a web browser depending on the server configuration.

An attacker who discovers the temporary directory’s name and accesses the installer before WordPress removes the temporary files could potentially establish a separate WordPress installation and execute PHP code on the server.

This could give the attacker the ability to access or modify files belonging to the actual website.

The United States Cybersecurity and Infrastructure Security Agency (CISA) added the vulnerability to its Known Exploited Vulnerabilities catalogue earlier in the week, confirming that the flaw was being exploited in real-world attacks.

Why Installing the Security Fix Could Still Be Dangerous

WordPress released security patches on October 30, 2026, through version 7.1.4 and corresponding updates for older supported release branches.

The updates were designed to prevent attackers from exploiting the temporary installation directory by assigning it a randomly generated name.

However, Bayram discovered that the process of installing the security update itself could still expose some websites because the updater initially relies on the older code already running on the website.

On websites running WordPress 5.9 and later, the older updater could generate a temporary directory name based on the downloaded update package, making it possible for an attacker to predict its location.

This means that although the security patch introduces stronger protections, those protections are not fully active during the initial stages of installing the update.

Bayram explained that attackers who successfully exploit this brief period could create a temporary WordPress installation connected to their own database.

Once inside the temporary installation, they could execute PHP commands with the permissions available to the web server.

This could subsequently provide access to files belonging to the legitimate website.

Before the vulnerability was addressed, attackers could also manipulate the temporary installation to introduce a malicious wp-config.php configuration file, which could then overwrite the website’s original configuration file during the update process.

The newly released security fix prevents this particular file-overwriting technique by ensuring that the protected configuration file is not replaced by a malicious version from the temporary directory.

Which WordPress Websites Are at Risk?

The researcher explained that not every WordPress update exposes the temporary installer.

The risk depends largely on whether the update package contains the necessary installation files.

Complete update packages include the installer files and can therefore expose the temporary installation directory if the older updater is still being used.

Partial update packages, on the other hand, contain only files that have changed between two WordPress releases. If they do not include the installer files, the same exploitation method may not work.

However, WordPress can fall back to a complete package when the existing core files fail official checksum verification or when an administrator performs a reinstallation.

Bayram therefore warned that administrators should not assume their websites are protected simply because WordPress is performing an automatic or partial update.

The deciding factor is whether the updater code already installed on the website has been secured.

The vulnerability also affects websites using automatic background updates because they rely on the same updating mechanism.

Security Measures Website Administrators Should Take

Bayram recommended that website owners prevent public access to the wp-content/upgrade directory before installing the security update.

He explained that WordPress accesses the directory directly through the server’s filesystem, meaning administrators can block external web requests to it without disrupting the normal update process.

For websites running Nginx, administrators can introduce the following configuration rule:

location ^~ /wp-content/upgrade/ {
    deny all;
}

For Apache servers, access can be restricted through the virtual host configuration using a directory-level access control rule.

Administrators who can only modify their website’s .htaccess file can also introduce the following rule in the WordPress root directory, placing it above the existing WordPress rewrite rules:

RedirectMatch 403 ^/wp-content/upgrade/

The researcher specifically warned against placing an .htaccess file inside the wp-content/upgrade directory because the older WordPress updater deletes existing contents in that directory before extracting the new update package.

After applying the restriction, administrators should confirm that attempts to access the directory through a browser return a 403 Forbidden response.

They should then proceed with installing WordPress version 7.1.4 or the corresponding security release for their existing branch.

Another recommended option is to perform a manual WordPress update outside the website’s public web directory.

This involves backing up the website’s files and database, extracting the new WordPress release in a location inaccessible through the web server and transferring the necessary core files without overwriting wp-config.php or the wp-content directory.

The database update can then be completed through the normal WordPress administration process.

Bayram also cautioned that using the WP-CLI wp core update command does not automatically eliminate the vulnerability because it relies on the same underlying updater mechanism.

Evidence of Active Exploitation

Security researchers have also reported attempts to exploit the vulnerability.

Wordfence, the cybersecurity company that assigned the CVE identifier, reportedly detected attack attempts nine minutes after deploying a firewall rule designed to protect websites against the flaw.

According to the company’s analysis, two particularly active sources continued scanning groups of websites for approximately 14.5 hours.

The pattern suggested that attackers were attempting to identify websites undergoing updates and exploit the brief period when the temporary installer became accessible.

The vulnerability received a severity score of 8.1 out of 10 under the Common Vulnerability Scoring System (CVSS), although WordPress rated the issue as low severity in its security advisory.

Security researchers also observed code described as an exploit for the vulnerability appearing in public GitHub repositories.

However, the effectiveness of all publicly available exploit code had not been independently established at the time of the report.

How to Check Whether a Website Has Been Compromised

Administrators whose websites remained on vulnerable versions after the security release have been advised to investigate possible signs of unauthorised access.

Wordfence recommends checking for unexpected requests targeting PHP files inside the wp-content/upgrade directory.

Website owners should also investigate unfamiliar administrator accounts, plugins that were not installed by authorised users and unexpected PHP files appearing in the temporary upgrade directory.

Bayram further clarified that exposure during an update depends on whether the temporary package contains the WordPress installer and whether the updater already running on the website has been fixed.

WordPress versions 4.6 and earlier no longer receive security updates, meaning websites running those releases do not have an official patch for the vulnerability. The researcher noted that the flaw dates back to WordPress 2.7, released in 2008.

Administrators using unsupported versions have therefore been advised to migrate to a supported release.

The discovery highlights a security challenge for website operators: even the process of installing a security update can create an opportunity for attackers when the underlying updating mechanism has not yet been protected.

Website owners are consequently advised to restrict access to temporary upgrade directories, install the appropriate security releases and investigate suspicious activity rather than assuming that a completed update automatically means their websites are secure.