On February 2, 2018, exploit with the code CVE-2018-6389 (EDB-ID: 43968) was discovered leading to the denial of service type of attack by increasing resource usage through the unprotected load-scripts.php file.

Exploit background information

You can read more about this exploit here: WPScan Vulnerability Database ID 9021 and Common Vulnerabilities and Exposures CVE-2018-6389. Use of the load-scripts.php (and load-styles.php) is a convenient way to concatenate multiple JavaScript (or CSS) files and deliver them as a single file. But, for this method, list of files to concatenate is only sanitized and checked to confirm they exist, but the script is not limiting the number of files to include. And this allows an attacker to use a very simple method to run DOS attack on any WordPress powered website is dramatically increase resources usage that can lead to the unresponsive server and for regular users to get 503 errors. The method for the attack is described in great detail here: How to DoS 29% of the World Wide Websites – CVE-2018-6389.

CVE-2018-6389 example URL
CVE-2018-6389 example URL

These two PHP files (load-scripts.php and load-styles.php) take the list of JS and CSS files, load each file listed, and output them as a single file. This was a very useful method to minimize the number of request browser makes to load all needed JS and CSS files. But, now, with widely used HTTPS with HTTP/2 protocol, the number of requests browser makes is no longer an issue, and all files are loaded through a single request. So, use of this method is no longer necessary.

This method of attack will not be effective on all WordPress websites. It depends on the server side cache, server power, use of proxy servers (like Cloudflare) that can filter DoS attacks. My guess is that almost all shared hosting WordPress websites will be affected, and most of the low-cost Cloud/VPS servers. And that is still a lot of websites to target.

Stop this exploit on your website

So, until the WordPress core is properly protected (if that is even possible at this point) from this exploit, there is a simple method how to stop WordPress from using these files and for the server to disable these files.

Step 1: Disable concatenation

This is very simple to do, just add this to your wp-config.php (on a new line above /* That’s all, stop editing! Happy blogging. */ line):

define('CONCATENATE_SCRIPTS', false);

Step 2: Disable access to load-scripts.php and load-styles.php

Now, you need to prevent access to these two files and return 403 Forbidden message to anyone trying to access these files. There are many ways to do this, you can consult your hosting company to help you with that, or you can use the simple method provided here that will work in most of the cases (and the method used on Dev4Press website already).

Apache

To do this, you need to add few lines of code into the .htaccess file (on Apache servers):

<FilesMatch "load-scripts\.php|load-styles\.php">
  Order allow,deny
  Deny from all
</FilesMatch>
Nginx

If you use Nginx, you need to add these few lines to server config file (consult your hosting company if you are not sure how to do it):

location ~ ^/(load-scripts|load-styles\.php) {
  deny all;
}

Notice: if you have files with these exact names somewhere else on your website (in the plugin or theme), this method will prevent access to these files too, so if that is the case, you will need better Files matching rules to include the wp-admin path in the rule.

What more will you gain?

By disabling concatenation and denying access to the two load scripts, you will ensure that CVE-2018-6389 can’t be used on your website. If you use HTTPS and your server supports HTTP/2 protocol, you will not miss the concatenated files and you will even gain some server performance back, because any page that uses these two scripts effectively needs three PHP requests, when this is disabled, you will need only one for each page that used these scripts before.

So, this is a win-win method, you are stoping exploit from being used, and you will reclaim some small amount of server resources back.

Official WordPress patch

At this moment, it is not clear what the official patch will be like. The core can be modified to allow the use of these scripts for logged in users only, but this will not prevent this problem if your website allows free registrations – the attacker can create an account and then run the attack.

Please wait...

About the author

MillaN
MillaN
Dev4Press owner and lead developer

Programmer since the age of 12 and now WordPress developer with more than 8 years of WordPress experience, author of more than 100 plugins and more than 20 themes.

5 Comments

  1. Jon says:

    Thanks for this – very helpful and simple to implement. One question though: if access to the files is prevented via .htaccess, is there any need to disable concatenation via wp-config.php? Having added the rule to my .htaccess file, but not disabled concatenation, the exploit no longer works. I use a caching plugin (WT3C – with HTTP/2 enabled) that combines .js and css for better page speed. If I disable concatenation will that not affect this caching option?

    Please wait...
    1. MillaN says:

      Thanks for the comment Jon! If you don’t disable concatenation, WordPress will attempt to use it on the admin side, and pages loading will fail. Cache plugins usually work for the front end (not admin side), so concatenation options is not affecting them. I use WP Rocket plugin, and it works fine.

      For this to work both .htaccess code and disabling of concatenation must be applied.

      Please wait...
  2. Jon says:

    Ta very much for the additional explanation. Odd that I have used this in .htaccess:

    Order allow,deny
    Deny from all

    …but not added the option to disable concatenation and I have no problems with the admin area and the exploit no longer works when I test it.

    Thanks again, I’ll make sure that I disable concatenation anyway…just to be sure!

    Please wait...
    1. MillaN says:

      Without concatenation disabled, WordPress still attempts to use load-script.php and load-styles.php file. Maybe due to the cache in browser you still don’t have issues, or something else has disabled concatenation on your website (maybe you have some plugin that did that).

      Please wait...
    2. Jon says:

      Hmmm….the code in ‘greater than’ and ‘less than’ was stripped from my reply. It should be (without the symbols) :

      FilesMatch “wp-admin/load-scripts\.php|wp-admin/load-styles\.php”
      Order allow,deny
      Deny from all
      /FilesMatch

      Please wait...

Leave a Reply

Your email address will not be published. Required fields are marked *