Login

Tag Archives: Plugin Security Scorecard

4 Sep 2024

It’s Very Common For Libraries Used in WordPress Plugins to Not Have a Security Policy on GitHub on How to Report Security Issues

Yesterday, we noted in a post that a third-party library used in a very popular WordPress plugin didn’t have any listed security advisories in its GitHub project despite the developing having acknowledge that a vulnerability had been fixed. What we also noted in passing was that there also wasn’t a security policy provided for the library, which would explain how to report other security issues in the library. You can see that in this screenshot for the library’s Security tab on GitHub:

[Read more]

3 Sep 2024

Plugin Security Scorecard August Results

August was the first full month our Plugin Security Scorecard was available. A fair amount of plugins were checked. A total of 144 plugins were checked last month. With 35 of those plugins being security plugins.

As can be seen below, the results for security plugins were not good. With 24 of the 35 plugins getting a D+ or below. That comes from a combination of different issues. Some of those plugins have security issues, including vulnerabilities. Some come from developers that have had repeated issues with vulnerabilities and are not addressing the underlying problems. Most security plugins are failing to implement best practices for security, even when they are running into the problems those cause. Then there is the issue of the plugin developers making security claims that are at least not supported with evidence (and often couldn’t be supported with evidence, since they are not true). [Read more]

3 Sep 2024

600,000+ Install WordPress Plugin MetaSlider Still Using Vulnerable Version of Library 17 Months Later

One of the expanding capabilities of our new Plugin Security Scorecard is the ability to identify software libraries included in WordPress plugins. From there, if there are known vulnerabilities in those libraries in the plugins, that can be warned about when plugins are graded. We can also go back and check if previous checks identified if plugins contained a vulnerable version of those libraries. As we found when adding a library to that checking last week, there is a need to better monitor this situation. That is because we found that a plugin with 600,000+ installs, MetaSlider, is still using a vulnerable version of the AppSero Client library. The vulnerability was fixed 17 months ago. We reached out the developer of that plugin last week as well. They said a fix will be included in the next release of the plugin, which they said might come out this week. (It hasn’t as of us publishing this post.)

The situation highlights other areas where security could be improved. [Read more]

27 Aug 2024

Wordfence Security and Solid Security Developers Not Supporting Standard to Avoid Security Problem They Confronted

In a recent post on the WordPress security provider Wordfence’s blog, they were claiming their “mission is to Secure the Web.” If you understand their business model this rings hollows, as what they offer is built around trying to address the after affects of not securing the web. That very blog post also disputes that, as they confronted a well-known problem with better securing plugins and simply ignored the problem. They are not alone, as the situation detailed in the blog post also directly involves another security provider, StellarWP. StellarWP is the developer of Solid Security.

The blog post discusses a situation where Wordfence bought a vulnerability in another plugin from StellarWP, GiveWP. Twice in the post, they note that they failed to successfully communicate with StellarWP about that. First, they wrote this: [Read more]

13 Aug 2024

WordPress Coding Standards is Failing to Warn About Missing Sanitization and Requiring Unnecessary Sanitization

One of the things that our new Plugin Security Scorecard uses to grade the security of WordPress plugins is a subset of the checks from our Plugin Security Checker. The subset is intended to be things that are always a security issue, which should be addressed. While the full set of checks will flag things that could be secure, but often are not secure and need to be checked. That subset involves checking for things you would expect to be issues with certain types of plugins and from certain developers. But the actual results of plugins checked so far tell a different story.

The 5+ million install plugin Wordfence Security has been found to be using “[t]he function filter_input() is used without a filter, so it doesn’t do any filtering.” Similarly, the 100,000+ install Jetpack Protect plugin is found to be using “[t]he function filter_var() is used without a filter, so it doesn’t do any filtering.” That plugin is from Automattic, the company so closely associated with WordPress that it now is not uncommon for WordPress to be seen as an arm of the company. That isn’t the only plugin from Automattic with issues. With the 4+ million install Jetpack and 7+ million install WooCommerce have been found to have both the previously mentioned issues. The threat posed by that would depend on what is done after the filter-less filtering is done, but the filter-less filtering shouldn’t be happening even if there isn’t a larger issue. [Read more]

12 Aug 2024

“Powerful Firewall Rules” Don’t Stop Exploitation of Reflected XSS Vulnerability in WordPress Security Plugin Shield Security

As part of refining our new Plugin Security Scorecard tool, we are very interested in making sure that the grading provided by that is useful. As we noted last month, an inspiration for our own tool, the OpenSSF Scorecard, doesn’t necessarily produce great results. To an extent, that a major company behind that doesn’t appear to care much about the scores. Currently, many security plugins get low grades with our tool, based on a combination of general issues and issues specific to security plugins. Seven of the graded security plugins currently have an F grade. Some because the plugins are themselves vulnerable. Others because of a litany of other issues with the plugins. One of those in the latter category is Shield Security. The F grade is based on the following issues:

  • Base64 obfuscated content detected.
  • The plugin’s changelog on the WordPress Plugin Directory is missing information on the latest version of the plugin, making it hard to know what changes have been made if any of those are security fixes.
  • The plugin doesn’t contain a security.txt file (or alternatively a SECURITY.md or SECURITY-INSIGHTS.yml), which would provide information on how to report security issues to the developer.
  • The plugin isn’t listing in a security.txt file where the results of a security review that has been done of the plugin can be found. A well done security review would provide a good measure of the security of the plugin at the time it was done.
  • The plugin blocked less than half of the exploit attempts from the Plugin Vulnerabilities Firewall regression testing suite the last time the plugin was tested, so it missing a lot of the protection it could, and another plugin is, offering.
  • The plugin is being marketed with a strong claim (or claims) of efficacy without citing evidence that backs up the claim.
  • The plugin isn’t providing a warning that its information on vulnerabilities in WordPress plugins is unreliable because it comes from a source known not to properly vet the information. That lack of vetting can lead to situations where a “fixed” vulnerabilty is subsequently widely exploited because there wasn’t really a fix.
  • The plugin is spreading misleading information about brute force attacks against WordPress websites, which are not actually happening, and causing the WordPress community to not focus on real security threats.

That plugin getting a F grade seems reasonable considering how many security vulnerabilities are being found in the plugin. A couple of weeks ago, we talked about one of those after our own firewall plugin stopped an attempt to exploit one of those. What we didn’t focus on there is that Shield Security’s firewall wouldn’t stop the attack. It isn’t the only recent vulnerability where that is true. That brings us back to our scorecard. [Read more]

9 Aug 2024

Freemius Still Hasn’t Resolved All the Security Issues in Their SDK Library

In a blog post last year, Freemius bizarrely criticized us for not working with them to fix vulnerabilities in their library that ships with many WordPress plugins, while linking to a post from the year before where they admitted to having been the ones refusing to work with us. The post last year revolved around them belatedly addressing a security issue that we had tried to address with them the year before. They also criticized us for publicly disclosing vulnerabilities we had discovered during a security review of a plugin using it, instead of allowing competitors to disclose them instead. (In a previous incident, they accused us of full disclosure of a vulnerability, despite us only knowing about it because it had already been exploited and fixed.) In both posts they derisively referred to those in the security industry as “trolls”. That type of behavior shouldn’t be acceptable in the WordPress community.

Unsurprisingly, considering Freemius’ abusive attitude towards the security industry and their unwillingness to take responsibility for their continued poor handling with security, they still haven’t gotten all the security issues resolved related to what we brought up with them two years ago. [Read more]

2 Aug 2024

WordPress is Telling People to Report Security Issues Through a Bug Bounty Program That Doesn’t Accept Many of Them

In August of last year, we noted a significant problem with reporting security issues with a WordPress plugin that comes directly from WordPress, Health Check & Troubleshooting, which has 300,000+ installs. That problem being that they didn’t provide a method to report most security issues to them privately. Because of that, we reported the issues we had noticed had just been introduced in to the plugin through a public issue on the GitHub project for the plugin. It took until July for there to be a response. That response reinforced the problem. Here is the response we got:

Thank you for the report, as you note these are technically negated by various other mechanics, so this will be treated as a public hardening task. [Read more]

1 Aug 2024

Security Reviews and Software Bill of Materials (SBOMs) Should be Standard for WordPress Plugins

Recently, we have taken a renewed look at how to assess the security of WordPress plugins, as part of building up the capabilities of our new Plugin Security Scorecard tool. Right now, it is hard to easily assess the security of plugins and what has filled the gap is often useless advice that suggests checking on things that are easy to check on, but don’t have any correlation with the security of plugins. Our new tool tries to surface useful information to help assess if plugins are secure enough for usage on websites with varying degrees of security risk. Among other things, that includes warning about plugins still in the WordPress Plugin Directory despite being known to be vulnerable, warning about developers that have a track record of not handling security well, plugins that are not being supported anymore, and security code that is being misused. But there is more information that could be provided by developers, which we are hoping to help incentivize more common usage of by incorporating checking for their inclusion when calculating security grades.

Already, as part of the grading system, we check for inclusion of a security.txt file (or several equivalents) that provides information on how to contact the developers about security issues. Today we started checking for an additional piece of information in that file and next month we will add a check for another. [Read more]