A zero-day vulnerability in WordPress core was disclosed, which allows an attacker to perform a denial of service (DoS) attack against a vulnerable application. The vulnerability exists in the modules used to load JS and CSS files. These modules were designed to decrease page-loading time, but have effectively rendered the WordPress core susceptible to DoS attacks.
WordPress holds a market share of more than 29 percent of internet websites and 60 percent of content management systems (CMS) worldwide, turning any vulnerability in the WordPress core into a potentially large-scale exploit.
The vulnerability exists due to a flaw in the server-side static file loading mechanism. The parameter “load” in the vulnerable modules “loadstyles.php” and “load-scripts.php”, which reside under the “/wp-admin/” path, accepts an array of JS/CSS files to fetch while the page is loading. The vulnerable modules are usually used only in pages accessible by authenticated users, with an exception being the login page, which exposes said modules to unauthenticated users as well. Thus, a malicious user can repeatedly request an excessive list of JS/CSS files, causing the server to retrieve vast amounts of data — and in so — render it unresponsive.
Although the load parameter can accept all 181 JS files that appear in the “script-loader.php” module. Our analysis has shown that, in fact, the server doesnʼt retrieve any data when calling JS files that are pulled from an external source such as https://ajax.googleapis.com. Hence, appending these JS files to the requested list is useless from an attackerʼs perspective.
Due to the simplicity of this attack, a low skill attacker can utilize the existing public exploit to take down virtually any unprotected WordPress site. Because the vulnerable modules are essential, a blacklist isnʼt recommended and a simple authentication-based whitelist will not work either because it may break the login page.
WordPress did not patch this vulnerability because they view it as an extensive resource exhaustion attack, and as such should be mitigated by a network firewall/web application firewall. This may, of course, change, and WordPress webmasters should (as always) stay tuned for new patches and versions.
Until today (February 6, 2018), we have only seen a few dozen exploit attempts using this vulnerability, but we might see a steep rise in attacks using this exploit due to the popularity of the platform unless a mitigation will be applied in the near future.
It is advised to set access restrictions to the “load-styles.php” and “loadscripts.php” modules by only allowing trusted IPs to access these resources or by enabling two-factor authentication on the wp-admin directory. Another solution is to set rate limits to these resources.
Vulnerability discoverer Barak Tawily released the following Bash script that patches the exploit by essentially allowing only admins to send requests to the vulnerable modules, and removes the requests to the modules from the login page. The script also removes most of the code from the “noop.php” module due to “re-declaration errors”.