One of the little understood realities of security issues with WordPress plugins is that the insecurity of them is not evenly spread across those plugins. Instead, many developers are properly securing their plugins and others get them properly secured when alerted they haven’t done that. A smaller number of plugin developers either are unable or unwilling to properly secure their plugins. With the latter group, among the issues we have seen, are developers who have introduced new serious vulnerabilities that are substantially similar to vulnerabilities that they know have been exploited in their plugins.

In situations where we become aware of developers who have shown that inability or unwillingness to properly secure their plugin, we are releasing advisories to warn customers of our service and the wider WordPress community of the risk of utilizing those developers’ plugins. In addition to checking those posts on our website for information on those advisory, we provide access to the information in several other forms. That includes through the companion plugin for our service, even when not using the service, as well as through a web browser extension and through separate data accessible from our website.

The latest addition to our advisories involves a developer, Bill Minozzi, who has a rather poor track record of securing their plugins, despite being the developer of security plugins. One recent situation also involved them being dishonest about the severity of a vulnerability in one of their security plugins.

Downplaying Vulnerability that Disclosed Visitor Log

On the support forum for the developer’s StopBadBots plugin, someone asked if a vulnerability in the plugin had been fixed. Part of the response stands out. In response to that, the developer wrote that the “problem you mentioned is not serious” and that “[a]n expert hacker might see non-critical information.” They then claimed “[i]t’s more of a marketing strategy used against us to destroy competitors.” While there are certainly problems with security providers making misleading to outright false claims about competing security plugins and their developers, that isn’t the case here. Contrary to their claims, anyone logged in to WordPress could send a simple request and view the contents of the plugin’s visitor log. That was all disclosed before the developer made that claim. The original source of the public disclosure of the vulnerability was Wordfence, which certainly makes plenty of false claims about competitors, but it seems highly unlikely they were trying to destroy the competition of a plugin with 6,000+ installs versus 5+ million for their own.

The vulnerability was caused by a lack of basic security in the plugin, which we found is still true. The vulnerability involved an AJAX accessible function that should have had a capability check, but it didn’t:

function stopbadbots_get_ajax_data() {
	require_once 'server_processing.php';

Here is what that looked like after it was fixed:

function stopbadbots_get_ajax_data() {
    if (current_user_can('administrator')) {
        require_once 'server_processing.php';

Looking at the hidden changelog for the plugin, the version addressing this was labeled as “Small Improvements.” instead of mentioning that a vulnerability was fixed.

Looking at the latest version of the plugin, we found that the code still missing that capability check with other AJAX accessible functions. Here is one that has another needed check, nonce check, but still no capability check:

function stopbadbots_import_tables_callback() {
	 check_ajax_referer( 'stopbadbots_ajax_fill_nonce', 'security' );
			if (!stopbadbots_fill_db_froma()) {

Here is another that is missing both of those:

function stopbadbots_dismissible_notice2() {
	$r = update_option('stopbadbots_dismiss_language', '1');

That isn’t the only security issue with their plugins.

A Giant Security Mess

In March of last year, we wrote about a new plugin from the developer that was and still is, as we put at the time, fundamentally insecure. The plugin, if it worked, would allow anyone to replace the contents of the website’s database. It also, if not fully set up, would allow an attacker to upload malicious files to the website as well. It is so insecure that it would be reasonable to believe that it intended to be so insecure. It doesn’t appear that is the intent, just that developer doesn’t understand what they are doing.

When we looked at that plugin previously, we found it to not work at all. When we tried it again, we ran into serious errors and we found that the setup process was very broken.

Broken Plugins

In just the limited checking over StopBadBots we did for this post, we found that it was poorly developed, causing errors when there shouldn’t have been them. Unsurprisingly, based on that, it was recently crashing sites of those relying on the plugin. A couple of comments by one individual paint a pretty good picture of bad practices by the developer at the time of the crashing. If the WordPress Plugin Directory was well managed, it seems unlikely that action wouldn’t have been taken with the developer by now.

Avoid Bill Minozzi’s Plugins

What’s been going on with Bill Minozzi’s handling of security would be a problem if they were just the developer of plugins, but they are also the developer of security plugins relied on by thousands of websites. They should have a better handle on security than other developers, not a worse handle than many other developers.

We would recommend avoiding their plugins, unless they can show that they have made significant changes to their handling of security.

Plugin Security Scorecard Grade for StopBadBots

See issues causing the plugin to get less than A+ grade