When someone goes to submit a plugin to the WordPress Plugin Directory, they are told it will go through a manual review before it is allowed in:

After your plugin is manually reviewed, it will either be approved or you will be emailed and asked to provide more information and/or make corrections.

That review is supposed to check for security issues:

At that point, someone will manually download and review your code. If we find no issues with the security, documentation, or presentation, your plugin will be approved. If we determine there are issues, you will receive a second email with details explaining what needs to be fixed.

Despite that, we keep finding that brand new plugins in the Plugin Directory contain serious vulnerabilities that are flagged by an automated monitoring tool that the team running the directory have refused to take advantage of for five years. The latest instance involves a plugin that contains a vulnerability that would allow a hacker to take control of a website by sending a single request to the website.

With another new plugin, it seems incredibly hard to believe any review happened.

After getting alerted that the plugin might contain a serious vulnerability, we tried to check on that. But we ran in to a serious problem, as once we activated the plugin, the frontend and backend of WordPress no longer worked. Instead, error messages were shown warning about a “Call to undefined function” involving different functions. That seems like something that would be hard to miss if a review was done.

If the reviewer didn’t install the plugin, there are plenty of things that should have raised significant concern. The plugin is named bigdump-restore and the description is “Restore very large Bigdump Restores safetly and friendly.” The plugin allows replacing the contents of the website’s database, so proper security would be more critical than the average plugin.

If you look at the plugin’s main file, there is some rather odd code, which copies a file in the plugin, which has a .txt file extension, to a new location with a .php extension:

99
100
101
102
103

$source = BIGDUMP_RESTORE_PATH .'tools/tools.txt';
$target = ABSPATH .'/bigdump-restore/bigdump-restore.php';
try{
	copy($source,$target);
 }

Code in that file was flagged by our automated monitoring system, as it allows uploading a file to the website in a way that is often insecure. In this case, it allows anyone to upload a file provided it has a certain name and file size and there isn’t already a file in that location:

9
10
11
12
13
14
15
16
17
18
19
20
21

if(!file_exists('bigdump.inc') and !file_exists('bigdump.php')){
    if (isset($_FILES['attachment']['tmp_name']) and is_uploaded_file($_FILES['attachment']['tmp_name'])){   
        // Determine the file location
        $newname = dirname(__FILE__) . '/' .basename($_FILES['attachment']['name']);
        if($_FILES['attachment']['name'] <> 'bigdump.php') {
            $errors[]='Wrong File Name';
        }
        if($_FILES['attachment']['size'] <> 40318) {
            $errors[]='Wrong File Size';
        }
        if(empty($errors)==true){
            // Move the file from temporary location to determined location
            if (!(move_uploaded_file($_FILES['attachment']['tmp_name'], $newname))) {

Like the vulnerability in the other plugin, it would allow a hacker to take control of a website by sending a single request to the website. That’s a very serious issue, but even if it as used as intended, there is still a very serious security issue.

That code is intended to be used to upload software called BigDump, which allows replacing the contents of a database. If the plugin didn’t break WordPress, then activating the plugin and uploading the intended file, would then allow anyone to visit a page on the website, /bigdump-restore/bigdump.php, and overwrite the database. So an attacker could erase the website’s contents, which would be bad, but they also could replace the database with new data, then log in to the website as an Administrator and place malicious code on the website.

How could a manual review have allowed this through? The best answer seems to be that there wasn’t one.

There are other things that point to reviews not happening, including that the team running the Plugin Directory has only 4 members and somehow one member is supposed to have reviewed tens of thousands of plugins:

Mika Epstein has reviewed 46,800 plugins for inclusion in the WordPress Plugin Directory.

The Plugin is From Security Plugin Developer

What is going on with WordPress seems like it should be a big issue with the WordPress security industry, considering that trust is such an important part of security and having these reviews done in a way that catches serious vulnerabilities would greatly improve the security of WordPress websites. But we have been the only ones that have been trying to get something done about this. What probably helps to explain that is that the developer of the plugin is themselves part of the WordPress security industry.

The developer of the plugin, Bill Minozzi, is also the developer of multiple WordPress security plugins. The most popular one, StopBadBots, has 10,000+ installs. It is hard to understand how someone could have created such an insecure plugin while also creating security plugins, but it happened.