The number of cyber attacks targeting WordPress has continued to increase at a rapid rate. Some data sources give us a clue that in 2017, there were nearly 100,000 attacks on WordPress websites happening per minute.
Many of these attacks use vulnerabilities in the WordPress core, plugins or themes. Hackers can use these vulnerabilities to steal data, plant malware or launch a denial of service attack.
In the past week, details of a serious Denial of Service (DoS) vulnerability in WordPress have been published by an Israeli security researcher named Barak Tawily. This vulnerability can be used to take down a website in a matter of minutes. It affects most versions, including the latest stable release (4.9.2). This guide will share some details of this dangerous vulnerability and how it can be addressed.
How does this vulnerability work?
The vulnerability is listed on the CVE (Common Vulnerabilities and Exposures) website as CVE-2018-6389 and on Exploit DB as exploit number 43968. Barak Tawily first wrote about it on February 5, 2018 on his blog.
It is a Denial of Service vulnerability. This kind of vulnerability is used to make a server or network resource unavailable by flooding it with many resource requests. The server or network resource is unable to keep up with all of the requests as the system becomes overloaded. When used to target a website, it could result in the website becoming unavailable.
Barak first noticed the problem when he saw an unusual URL that was loading when he visited certain WordPress pages. That URL was
He noticed that the load-scripts.php file was receiving a parameter called
Because WordPress is an open source platform, it was simple for Barak to review the application’s code and determine precisely how WordPress loaded these files. He discovered that load-scripts.php file was designed to economise the loading of external JS files. Another file, called load-styles.php, was doing the same thing for Cascading Style Sheet (CSS) files.
This feature allowed the browser to receive multiple files with a single request, dramatically improve the load time of each admin page. Although it was only designed for use on admin pages, it was also being used on the login page — before the user had been authenticated. This oversight is responsible for the vulnerability.
Barak began to look at ways that load-scripts.php could be exploited. He started by altering the URL to include the JS file’s name multiple times in the hope it would cause WordPress to continually load the same file. This failed because WordPress removed duplicate names from the
He continued to explore the source code of WordPress and discovered that there is a variable that contains a defined list of scripts that can be loaded. If one of the names in the load array matches one of these script names, the server will perform an I/O read action to load it. The list of scripts that are available is defined in a file called script-loader.php. It includes 181 different scripts:
Barak found that when he included these names in the
load array, WordPress would search for each one, performing 181 I/O actions on the server. After it found files, it would combine them into one request, creating even more load on the server.
After testing the vulnerability, he found that the server took 2.2 seconds to gather the files, merge them into one file, and send them to the browser. Barak used a DoS tool written in Python to test the extent of this problem. This tool is capable of sending many HTTP requests in rapid succession to a server. He simply added the names of the JS files to the URL and fed it into his DoS tool.
After performing 500 requests, the server was overloaded and became unable of responding to subsequent requests. He posted a video showing how quickly it could be used to take down a WordPress website.
How many websites have this vulnerability?
Barak suggests that this vulnerability affects nearly all WordPress websites, including all major releases of this CMS, going back 9 years. This means that up to 29% of the world’s websites will be affected by this vulnerability.
Addressing this issue
Barak told WordPress developers about the vulnerability. However, they are refusing to patch it, replying: “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.”
Fortunately, Barak decided to create his own patch to ensure that only authenticated users were able to access the functionality in load-scripts.php. He has created a forked WordPress project that fixes the vulnerability and a Bash script that modifies the relevant files.
How secure is WordPress?
The developers of WordPress take security seriously. They have extensive processes for their release cycles, security releases, and bug checking. WordPress is also heavily involved with the Open Web Application Security Project (OWASP) — an online community that is focussed on improving web security.
There are thousands of WordPress developers working hard to address the top 10 security risks identified by OWASP including:
- Injection attacks
- Broken Authentication and Session Management
- Cross-Site Scripting (XSS)
- Insecure Direct Object Reference
- Security Misconfiguration
- Sensitive Data Exposure
- Missing Function Level Access Control
- Cross-Site Request Forgery (CSRF)
- Using Components with Known Vulnerabilities
- Unvalidated Redirects and Forwards
The steps that WordPress developers take to address these issues helps to make it one of the safest content management systems available.
The WordPress team has already fixed more than 2,450 security vulnerabilities since they first launched their application. In most cases, they fix vulnerabilities within a few days. The fastest response time for a WordPress vulnerability patch was just under 40 minutes.
WordPress also has a Bug Bounty Program in place. This program gives developers rewards if they find bugs. However, their bug bounty program only covers vulnerabilities that are strictly the fault of developers. In this case, they believed that server administrators should control access to
Most of the security issues that WordPress faces are not caused by the core application — they occur because of vulnerability in plugins and themes. It is estimated that over 50% of all WordPress exploits come from one of these vulnerabilities. The risk of these vulnerabilities can be mitigated by using a theme from a security conscious developer and limiting the number of plugins you use.
Thanks for reading, for more WordPress security articles, subscribe to our blog or follow us on social media.