WordPress RCE Vulnerability Draws Immediate Attention
Within a mere nine minutes of a firewall rule being enacted, malicious actors commenced their pursuit of a recently addressed Remote Code Execution (RCE) vulnerability in WordPress, a frenzy that has persisted unabated.
According to Wordfence, 62,969 attempts to exploit this flaw were thwarted within the inaugural 24 hours following the release of WordPress version 7.1.4 on October 28. This critical vulnerability permits unauthorized users to execute code on a server.
The vulnerability is assigned a Critical Vulnerability Severity Score (CVSS) of 8.1 and impacts WordPress Core versions 4.7 up to 7.1.3.
This issue was flagged by cybersecurity researcher Umut Bayram, though a Common Vulnerabilities and Exposures (CVE) identifier has yet to be established.
Transience of the Bug
Distinctively, this WordPress RCE flaw separates itself from the continuous influx of plugin vulnerabilities that site administrators often overlook.
It is an inherent flaw within WordPress itself, rather than a defect residing in a plugin, making it impervious to rectification through simple deactivation. The vulnerability lurks within WordPress’s update mechanism.
When a complete Core package is installed, WordPress temporarily unpacks new files into a designated directory located under wp-content/upgrade.
This staging area, predictable in nature and often accessible online, also houses the WordPress installer. An assailant quick enough to request the installer at a precise moment can exploit this staging area to achieve PHP code execution.
The critical factor here is timing. Wordfence’s laboratory examinations reveal that the temporary directory remains accessible for mere seconds before WordPress purges it.
A solitary request has minimal likelihood of success, prompting attackers to engage in relentless polling.
Significant clusters of malicious activity were observed by Wordfence, as two primary sources targeted specific groups of sites for approximately 14.5 hours continuously, systematically cycling through version identifiers and staging paths.
Others exhibited meticulous probing of directory configurations, all orchestrated to coincide with site updates.
Mitigation Measures Implemented
The release of WordPress 7.1.4 introduces several safeguards: it randomizes the staging directory, incorporates an index guard, and eliminates insecure promotion of configured data.
Notably, this fix was backported to earlier versions dating as far back as 4.7, ensuring that even older installations can receive protection. However, versions 4.6 and earlier have ceased to receive any security updates.
In addition to rectifying the RCE vulnerability, this release addresses 21 other issues, some of which are notably easier to exploit than the RCE flaw.
These include several stored cross-site scripting vulnerabilities across various components such as block delimiters, the Categories block, and comment pagination labels, among others.
Additionally, an unauthenticated information disclosure vulnerability may expose unpublished Customizer changes, alongside an authorization weakness within the Notes REST API and complications tied to the Interactivity API, including prototype pollution.
Moreover, the bundled root certificates were refreshed following the revocation incident involving eMudhra.
Navigating the Risks
The most prudent advice is to implement the update without delay, a recommendation echoed by WordPress. However, this guidance comes with a certain degree of awkwardness, as the update process itself constitutes an attack vector.
Defiant’s Alex Thomas has acknowledged this nuanced dilemma, especially when a reader raised pertinent concerns.
For those capable of managing server or CDN settings, restricting HTTP access to wp-content/upgrade prior to commencing the update sequence is advisable; however, he refrained from promoting it as the primary message.
He posited that urging millions to enact path restrictions first might lead to procrastination in executing the update that rectifies all 22 vulnerabilities.
Both strategies are defensible, and administrators who possess real authority over their server architecture should ideally consider implementing both measures in the aforementioned order.
Approximately three hours following the release, Wordfence’s firewall rule was dispatched. Premium, Care, and Response clients received immediate access, while complimentary users must endure a wait until November 27 due to the standard 30-day delay—a protracted period to remain vulnerable.
Those utilizing Wordfence are also advised to verify the activation of Extended Protection, as the attacks attempt direct access to a staged PHP file without loading WordPress.
Critical Insights
- The RCE vulnerability in WordPress was addressed in version 7.1.4, impacting Core versions ranging from 4.7 to 7.1.3.
- Wordfence neutralized 62,969 exploit attempts within 24 hours, with the first successful match occurring merely nine minutes post-deployment.
- Exploitation hinges on a fleeting window of opportunity that occurs during the complete package update, lasting mere seconds.
- No successful breaches have been documented by Wordfence thus far.
- It is imperative to update to version 7.1.4 or an analogous branch and inspect wp-content/upgrade for any inadvertent PHP files.
Final Thoughts
With nearly 63,000 attempts recorded and zero confirmed breaches, we witness a scenario where the flaw presents significant difficulty in exploitation but remains effortless to probe.
The WordPress RCE vulnerability is unlikely to precipitate widespread chaos among numerous sites. However, it may catalyze increased scrutiny of some unpatched sites over the upcoming month, particularly those awaiting a complimentary firewall rule.
For those sites configured for automatic updates, it is advisable to verify the current version under Dashboard > Updates rather than relying solely on the assumption of successful updates.
Source link: Techaeris.com.
