Login

Tag Archives: Plugin Security Scorecard

31 Jul 2024

11 Month Wait for Security Fix for WordPress Plugin Highlights Value of Checking if Developers Are Supporting Plugins

In August of last year, we found that an update to a plugin coming directly from WordPress, Health Check & Troubleshooting, had introduced a couple of minor security issues. We reported those to the developers through the plugin’s GitHub project at the time. They finally responded and addressed those last week. That isn’t a good response time, but isn’t all that surprising considering the lack of much support for the plugin, despite having 300,000+ active installs. That lack of support ties into something we are now doing with our new Plugin Security Scorecard.

With our Plugin Security Scorecard, we are trying to provide an at a glance way to provide a reasonable idea of the handling of security with a WordPress plugin. As we noted last week, an inspiration for that is the OpenSSF Scorecard, which tries to do a similar thing across a much wider spectrum of software. What that other scorecard seems to lack is evidence that the components of the score (and therefore the overall score) are actually useful in assessing the security of software. With our own solution, we are interested in making sure its grading is based on useful information. That brings us back to Health Check & Troubleshooting. [Read more]

25 Jul 2024

Do Low OpenSSF Scorecard Scores for Libraries Shipped With WordPress Plugins Matter?

Yesterday, we discussed what we found when we tried to assess the value of OpenSSF Scorecard scores for WordPress plugins. OpenSSF Scorecard scores are supposed to “quickly assess open source projects for risky practices.” With WordPress plugins, we found that it was of limited value due to lack of scores for many plugins, lack of an easy ability to check if there is a score for a plugin, and questionable metrics. Another use for this for WordPress plugins would be looking at the scores for libraries included in WordPress plugins. While looking into gathering more information on libraries included in plugins for our Plugin Security Scorecard, we found that a major promoter of the OpenSSF Scorecard project is using multiple libraries in a popular plugin despite low scores. That raises the question of how much weight others should put in those scores, if a major proponent appears not to put much.

Google has been heavily involved in the OpenSSF Scorecard project since the beginning. The blog post announcing the project on the OpenSSF was written by a Google employee. Days later, Google’s Open Source Blog promoted the project. Google’s involvement has continued as new versions of the scorecard have been released. Google is also the developer of the Site Kit by Google plugin, which has 4+ million active installs according to wordpress.org data. That includes 7 third-party libraries referenced in a file generated by Composer in the plugin. [Read more]

22 Jul 2024

WordPress Plugin Directory is Allowing Completely Unsupported Extraordinary Claims of Security Plugin Efficacy

For those looking to improve the security of WordPress websites, security plugins are often thought of as an important part of the solution. Just look at the install count of security plugins. What our testing over the years has found is that very popular plugins often fail to provide much protection, if any. That is corroborated by the many complaints by those using those plugins that they failed to provide the promoted protection and websites got hacked. At the same time, there are much less popular plugins that are offering significantly more protection. What seems to be an obvious part of the explanation for this mismatch is that in the WordPress plugin directory, WordPress is allowing developers to make extraordinary claims of efficacy without even putting forward any supporting evidence for the claims. In other fields, this type of thing wouldn’t be allowed, because of the negative impact it has.

Take a plugin named Bad Bot Blocker. Here is the first paragraph of the description on the plugin directory (with our own emphasis): [Read more]

10 Jul 2024

WordPress Plugin Developers Can Use security.txt Files to Aid in Getting Security Issues Reported to Them

In May, we found that numerous security providers had failed to catch that a vulnerability in the 100,000+ install WordPress plugin Genesis Block hadn’t been fully fixed. It was a good reminder of the importance of relying on vulnerability data that is actually vetted, which isn’t true for most sources. At the time, we had tried to contact the developer to let them know about the failure to fully fix this, but they didn’t provide a contact method to do that. We did find that the parent company of the developer, WP Engine, has a security page, but that doesn’t provide a contact method for non-customers to contact them. It directs customers to contact them through a general contact form. Both of those things are odd. It also mentioned a third-party vulnerability bug bounty program, which wouldn’t be relevant to address the issue we were trying to reach them about (and wouldn’t get us in touch with them).

The vulnerability has remained in the plugin since then. The plugin had remained in the WordPress Plugin Directory despite the plugin being publicly known to be vulnerable. That is, until two days ago, when it was closed on there: [Read more]