Mitigate WordPress CVE-2018-6389

Last Revised: October 2, 2021

Although it is not usually very normal, from time to time vulnerabilities appear in WordPress such as CVE-2018-6389.

In WordPress through 4.9.2, unauthenticated attackers can cause a denial of service (resource consumption) by using the large list of registered .js files (from wp-includes/script-loader.php) to construct a series of requests to load every file many times.


This problem comes from the [load-scripts.php] and [load-styles.php] files that allow the loading of a series of predefined scripts and styles. In this case I will talk about the scripts although the patch to be applied is for both files.

NOTE: This entry is documented as of 2018-02-09.


This file loads a list of scripts [wp_scripts] that are in the [script-loader.php] file. This list is of more than 180 possible values that would give rise to be able to make a query of the style to:


In principle this address can be loaded without problem, except that being such a large file takes about two seconds to generate. That can cause that in a massive attack, the server ends up being saturated.


At the moment there is no patch as such in the WordPress code and it is raised if this is a problem to be corrected by the system itself or by external elements (Firewall, WAF …). Other proposals are to limit the number of elements that can be loaded when making the call to the script.


Although there is no simple solution at the moment, some possibilities are being considered at various levels.


A first solution that has been given is to apply this nginx rule that would limit the length of the parameters to 1024 bytes. Keep in mind that the maximum length is more than 2600 bytes. Personally and taking into account that the number of scripts to be loaded should not be very high (25 scripts could have a length of about 350 bytes), I would reduce the limit to 512. In any case you would have to browse the site to define in each case (and template) what is necessary.

location ~* ^/wp-admin/load-(scripts|styles).php$ {
  if ( $query_string ~* "^.{512,}$" ) {
    return 444;

Apache HTTPD

In the particular case of Apache HTTPD, another possible solution is proposed, which must include the use of the cookie that a user has been browsing the website.

RewriteEngine on
RewriteCond %{HTTP_COOKIE} !wordpress_logged_in_
RewriteRule /wp-admin/load-scripts.php - [F]

Loading the data (PHP)

Another possible solution that they propose in a WordPress fork is to change the way in which the data of this script is loaded.

Script bash for Linux

Or to run this Linux script in the main WordPress folder.

Script PHP

In the same way that the previous step is executed from the Linux command line, this solution proposes that you upload the file to the root folder, run it (he will make changes to the files) and delete the file.

ModSecurity Rules

Although you can always apply a rule like this to your firewall.

SecRule  REQUEST_URI "@rx  (?i:/wp-admin/load-scripts.php?.*?(load%5B%5D|load[]|load%5B]|load[%5D)=([^&,]*,){20,})"  "id:1,msg:'Potential use of CVE-2018-6389',deny"

Seguir con Seguridad para WordPress

About this document

This document is regulated by the EUPL v1.2 license, published in WP SysAdmin and created by Javier Casares. Please, if you use this content in your website, your presentation or any material you distribute, remember to mention this site or its author, and having to put the material you create under EUPL license.