WordPress Vulnerability: Risks During Updates
Recent insights from Umut Bayram, a researcher at Picus Security, have unveiled significant vulnerabilities affecting WordPress sites during the installation of a critical patch for an actively exploited security flaw.
The update process relies on existing, outdated code for unpacking, which opens a narrow window for potential attackers.
If an unauthorized individual capitalizes on this moment, they can execute arbitrary code on the server. To mitigate this risk, Bayram recommends restricting access to the wp-content/upgrade directory before commencing the update.
The identified flaw, denominated as CVE-2026-119977, impacts versions ranging from WordPress 4.7 to 7.1.3.
Typically, when a core update is initiated, WordPress extracts the new version files into a temporary folder within the wp-content/upgrade directory. This process, unfortunately, leaves the installer accessible to the web server.
An unscrupulous actor, devoid of any account, could feasibly identify the folder’s designation and access the installer prior to its removal by WordPress, consequently gaining the ability to run their own code.
Earlier this week, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) formally recognized this vulnerability within its inventory of known exploited weaknesses.
In response, WordPress released an update (version 7.1.4) last week to rectify this issue, along with corresponding updates for prior versions dating back to 4.7, detailed in a security advisory.
The new update modifies the temporary folder’s naming convention to a random string. Nevertheless, the unpacking process still utilizes the legacy code present on the site, as outlined in the updater code.
In installations using version 5.9 or later, this older code assigns the folder a name based on the downloaded file, permitting a final predictable naming convention.
Prior to the update, it was conceivable for an assailant to exploit the installer to inject a new wp-config.php configuration file into the temporary storage.
Thereafter, the update could replace the legitimate configuration file with this malicious version. The enhancement implemented, which precludes this action, is already functional during the installation update, as WordPress employs the improved code for file transfers.
Identifying At-Risk Sites
It is pertinent to note that not every update will inadvertently expose the installer. The threat is primarily associated with complete packages that invariably encompass installer files.
Conversely, a more minimal, partial package, which is crafted for a specific earlier version, only poses a risk if it inherently includes those files.
For sites configured to enable automatic updates, WordPress will seamlessly implement the fix using the same update mechanism.
A review conducted by The Hacker News of WordPress.org’s update service revealed that updates within the same branch, like from 7.1.3 to 7.1.4, typically involve a partial package, which is suitable for automatic updates.
However, transitioning from an earlier branch, such as from 7.0.7 to 7.1.4, exclusively offers complete packages.
In previous versions, specifically between 4.4 and 5.8, the outdated code Randomly appends characters to the folder’s title, shielding its visibility unless data is compromised through an error message, according to the researcher.
Once version 7.1.4 or its equivalent branch fix is implemented, subsequent updates will utilize a randomized folder name, effectively preventing any wp-config.php file present in the temporary directory from overwriting the legitimate one.
Precautions Prior to Updating
The foremost recommendation from Bayram is to prevent the web server from granting access to the wp-content/upgrade folder entirely.
This is feasible since WordPress interacts with this folder directly on the disk, allowing updates to proceed uninterrupted.
- Restrict access to the folder in the web server configuration. For Nginx, apply
location ^~ /wp-content/upgrade/ { deny all; }. For Apache, insertRequire all deniedwithin a<directory>block designated for that folder in the virtual host configuration. - If alterations to .htaccess are the only option, append
RedirectMatch 403 ^/wp-content/upgrade/to the .htaccess file in the root of WordPress, preceding the rewrite rules. - Avoid placing an .htaccess file within wp-content/upgrade. The legacy updater purges all contents within this folder prior to unpacking an update, rendering the file nonexistent when required.
- Verify that accessing /wp-content/upgrade/ triggers a 403 error.
- Proceed with an update to 7.1.4 or the patched version pertinent to your branch.
Alternatively, a prudent approach involves undertaking a manual update outside the web server’s root directory.
Secure backups of site files and the database, unpack the new version in a directory inaccessible to the web server, transfer the core files while ensuring wp-config.php and wp-content remain untouched, and run the WordPress database update.
This methodology effectively avoids creating any temporary installations within the server-accessible directory.
Relying on WP-CLI’s wp core update command is discouraged, as it utilizes the same updater process and unpacks files within the same folder.
WordPress versions 4.6 and prior are no longer maintained with security updates, presenting a void of remedies. The researcher emphasizes that this vulnerability dates back as far as WordPress version 2.7 released in 2008, urging those users to migrate to a supported version.
Assessing Risks and Vulnerabilities
The CISA’s recent catalog update reflects findings of active exploit attempts, though specifics regarding these assaults remain unspecified.
Wordfence, a specialized WordPress security firm responsible for assigning the CVE identifier, reported observing attack attempts shortly after the implementation of a firewall rule pertinent to the vulnerability on the day of its release.
Two of the busiest sources relentlessly scanned clusters of websites for approximately 14.5 hours, suggesting a concerted effort to execute an attack coinciding with site updates, as delineated in their attack analysis.
The flaw received a rating of 8.1 out of 10 on the CVSS scale, indicating its critical nature. Testing revealed that the opportunity to exploit this vulnerability existed for mere seconds. Notably, WordPress’s advisory assigns a comparatively minor rating to this flaw.
Exploitable code relating to this vulnerability has surfaced in publicly accessible GitHub repositories in recent days.
One repository claims compatibility with sites utilizing predicted folder structures during full-package updates; however, verification of its efficacy remains pending.
For sites that have not updated since the release, Wordfence advocates investigating the following:
- Unexpected inquiries to PHP files located within wp-content/upgrade
- Unknown administrator accounts
- Unfamiliar plugins
- PHP files located in wp-content/upgrade that were not manually placed there
Latest Insights
Bayram relayed to The Hacker News on November 6 that the exposure associated with a partial update is contingent upon the contents of the specific package.
A partial update encompasses solely the files altered between two versions; if installer files are absent, the temporary installation cannot function as a bona fide WordPress setup, thereby denying access to the installer.
Moreover, it is crucial to acknowledge that a site may not always receive the available partial package. WordPress reverts to a complete package if discrepancies in core file checksums are detected or if an update constitutes a reinstallation.
The determining factor, according to the researcher, “isn’t partial versus complete. It’s whether the updater present on the site has already been rectified.”
Source link: Thehackernews.com.
