Questionable patching on the part of the WordPress CMS team has caused lots of headaches for WP site owners this week.

A basic maintenance version released on Monday —WordPress 4.9.3— a release meant to fix basic bugs caused huge problems for WordPress site owners by breaking the automatic update mechanism that upgrades WordPress sites in the background, without user interaction.

The WordPress team was forced to release an update the next day —WordPress 4.9.4— to fix the issue introduced on Monday, and restore the background updates system.

Unfortunately, since the background update system was down, this means that all WordPress site owners running v4.9.3 will need to visit their site's admin panel and trigger the update by hand.

No fix for CVE-2018-6389 zero-day

But neither v4.9.3 and v4.9.1 fixed a vulnerability reported by Barak Tawily —CVE-2018-6389— a bug that causes a Denial of Service (DoS) state for WordPress sites.

The issue affects all WordPress versions, including WordPress.com installations, which means that miscreants can crash more than a quarter of all Internet sites just by running a simple script.

Exploit code to leverage this bug has spread quickly on the Internet, and proof-of-concept exploits that can down servers are available online in several places [1, 2].

According to DDoS mitigation provider Imperva, attacks have already taken place, and the number of incidents is expected to grow as more threat actors learn of the issue.

"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," said Imperva engineers Johnathan Azaria and Koby Kilimnik.

Below is a simple explanation for the bug from the same Imperva team, who double-checked and confirmed Tawily's fndings:

The vulnerability exists due to a flaw in the server-side static file loading mechanism. The parameter “load” in the vulnerable modules “load-styles.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.

WordPress team deferred patching to server providers

Tawily said he tried to notify the WordPress team of the flaw, but developers chose not to fix the issue.

"This kind of thing should really be mitigated at the server or network level rather than the application level, which is outside of WordPress's control," the WordPress team responded, according to Tawily.

The researcher released a shell script that patches the flaw until the WordPress team changes heart and adds a fix to WordPress itself. The Bash script gives only admins the permission to send requests to the vulnerable modules and removes the ability to query the vulnerable modules from the login page. There is also a way to fix this with mod_security.

Tawily also released a YouTube video demoing his DoS bug:

Related Articles:

PHP Deserialization Issue Left Unfixed in WordPress CMS

Windows 10 Audio Not Working After Installing Latest Windows Updates

Port of Barcelona Suffers Cyberattack

0Day Windows JET Database Vulnerability disclosed by Zero Day Initiative

Exploit Published for Unpatched Flaw in Windows Task Scheduler