Recently, we noted again that evidence keeps running counter to the claim made by the WordPress security provider Wordfence that more vulnerabilities being found in WordPress plugins were an indication that things were getting better because newly introduced vulnerabilities were not being found. As plenty of new vulnerabilities are being introduced, but often they go unnoticed. What also stands out from those examples of newly introduced vulnerabilities is that WordPress plugin developers are not running their plugins through automated testing that could catch serious vulnerabilities and then fixing the issues identified.

The latest example of that involves a developer named WPDeveloper. That developer has plugins with at least 2.7 million installs, according to wordpress.org data. A lot of the install count comes from a plugin named Essential Addons for Elementor, which is one of two 1+ million install count plugins they offer. That plugin had a vulnerability that was widely exploited in May. The exploitation occurred right after the WordPress security provider Patchstack disclosed how the vulnerability could be exploited only hours after it was fixed.

That wasn’t the first security issue being fixed in that plugin. In May of the previous year, we found the developer apparently unintentionally fixing a vulnerability, and missing additional instances of it. The next month, they appeared to unintentionally fix another vulnerability.

In a reasonable world, the developer would take proactive action to make sure their plugins are properly secured going forward after a high-profile security situation like occurred this May. That hasn’t happened.

As we detailed in a more technical post earlier today, the developer released a new version of their 100,000+ install plugin Essential Blocks that contains new code that is easy to spot as being insecure. The new version of the plugin passes user input to the PHP function unserialize(). That is despite a warning in the documentation that you should “not pass untrusted user input to unserialize()” as that “can result in code being loaded and executed due to object instantiation and autoloading, and a malicious user may be able to exploit this”. It didn’t take much more checking to confirm that is exploitable in the plugin.

That is something that automated tools should pick up and warn about, as our own Plugin Security Checker does:

When WordPress plugin developers are not even taking an easy step like this, it is going to be difficult for the security of those plugins to improve.