Plugin Vulnerabilities

27 Jan 2025

Patchstack Apparently Didn’t Take Basic Step to Get Unfixed Exploitable Vulnerabilities Fixed Before Disclosing Them

Last week WordPress security provider Patchstack disclosed what they claimed was an unfixed exploitable vulnerability in a WordPress theme and one in a related WordPress plugin. We say claim, because some of the information they provided appeared on its face to be very wrong. Early in the post, they wrote that “code that handles user input didn’t have any authorization or nonce check.” Code that handles user input doesn’t necessarily require authorization or a nonce check. For example, doing a search on a WordPress based website doesn’t require either of those things, despite involving user input. A more salient point is they then promptly showed the code and that not only contained a nonce check, but even had a comment about it, “First check the nonce, if it fails the function will break:”

Patchstack claimed to have made at least two attempts to contact the “vendor”, on September 23 and January 16. It isn’t clear if the “vendor” refers to the developer to theme and plugin or the marketplace they are available from, though it seems the former. The marketplace it is available on is Envato’s ThemeForest. If you don’t get a response from a developer, you should next reach out to the marketplace (assuming they don’t have a track record of not responding properly). That would be more important when you are claiming that a vulnerability allows a “user to increase their privileges and take over the WordPress site by performing a series of HTTP requests”

Envato’s information on reporting security issues in their marketplaces is a web search away and they provide a form to report issues.

We reached out to Envato about this on Thursday morning. They responded early yesterday, saying in part, “I just wanted to let you know that we’re investigating this potential vulnerability and to also thank you for taking the time to let us know about it.”

We also reached out to the developer on Thursday, but we haven’t heard back from them.

Today, a new version of the theme was released with a changelog entry that reads “Improved – Security by patching vulnerabilities highlighted by Patchstack.” Since we dont’ have a copy of the theme or plugin we can’t check of their current status. (If someone has access, get in touch with us, so that we can vet them.)

So it seems that Patchstack didn’t bother to contact Envato before disclosure, creating unnecessary security risk, but getting more attention for themselves.

Multiple supposed journalists ran with this with reaching out to developer or Envato for their side of the story, that includes Bill Toulas at the Bleeping Computer and Sead Fadilpašić at TechRadar.

27 Jan 2025

Patchstacks’s Vulnerability Disclosure Program (VDP) Goes Against Important Requirements of EU’s Cyber Resilience Act

In October, the European Union approved the Cyber Resilience Act (CRA) after two years of development. It seems well thought out, probably best shown with the authors understanding the harm that security providers’ own bad security often creates. Unfortunately, in the run up to passage, WordPress and others had tried to portray it as having negative effects on open source software (while also providing a misleading portrayal of security handling at WordPress). That is, despite it actually requiring for-profits entities taking advantage of open source software being required to help secure it. Also, unfortunately, an unscrupulous WordPress security provider is trying to mislead the WordPress community as what the act entails to continue harmfully directing vulnerability reporting away from developers.

That provider being Patchstack, here is how it mentions complying with the CRA through them on a page on its website about their vulnerability disclosure program (VDP):

While they claim “Starting Q4 in 2024, The Cyber Resilience Act (CRA) will introduce obligatory software support and vulnerability disclosure guidelines,” in truth, the act becomes applicable years later. Specially, it becomes applicable to plugin developers on “11 December 2027, with exception of the reporting obligations concerning actively exploited vulnerabilities and severe incidents having an impact on the security of products with digital elements, which should apply from 11 September 2026.” That continues Patchstack’s long track record of misleading to outright dishonest claims.

Things get worse from there. Patchstack’s whole intent is to get vulnerabilities reports directed away from plugin developers to themselves, so they can profit off of the vulnerabilities. That also prevents legitimate security providers from properly vetting vulnerability claims. That makes it harder to catch when vulnerabilities haven’t actually been fixed, which happens often. It also makes it harder to catch misleading claims. That doesn’t seem like something the EU would be supportive of, and the act goes directly against that. Here is the relevant section of the introduction, with our emphasis added:

Manufacturers of products with digital elements should put in place coordinated vulnerability disclosure policies to facilitate the reporting of vulnerabilities by individuals or entities either directly to the manufacturer or indirectly, and where requested anonymously, via CSIRTs designated as coordinators for the purposes of coordinated vulnerability disclosure in accordance with Article 12(1) of Directive (EU) 2022/2555. Manufacturers’ coordinated vulnerability disclosure policy should specify a structured process through which vulnerabilities are reported to a manufacturer in a manner allowing the manufacturer to diagnose and remedy such vulnerabilities before detailed vulnerability information is disclosed to third parties or to the public. Moreover, manufacturers should also consider publishing their security policies in machine-readable format. Given the fact that information about exploitable vulnerabilities in widely used products with digital elements can be sold at high prices on the black market, manufacturers of such products should be able to use programmes, as part of their coordinated vulnerability disclosure policies, to incentivise the reporting of vulnerabilities by ensuring that individuals or entities receive recognition and compensation for their efforts. This refers to so-called ‘bug bounty programmes’.

So you need to be able to report issues directly to the developer, which isn’t what happens with Patchstack’s program. More importantly, it states that the process should happen before “detailed vulnerability information is disclosed to third parties.” Patchstack is a third-party trying to profit off of that information.

Then in Article 13, that is reiterated (emphasis ours):

17. For the purposes of this Regulation, manufacturers shall designate a single point of contact to enable users to communicate directly and rapidly with them, including in order to facilitate reporting on vulnerabilities of the product with digital elements.

In line with CRA, our Plugin Security Scorecard lowers the grade of plugins that are directing vulnerabilities away from developers like Patchstack is attempting to get them to do.

While they have a check mark next to the “Share data with EU vulnerability database” on the page, the relevant European Union database doesn’t yet exist. So they couldn’t be sharing with it.

Two other components don’t make sense as they are “Notify users about vulnerability exploits” and “Provide security updates (separately).” Those would be things that a developer would need to do.

It also is important to note the CRA has other requirements that Patchstack doesn’t mention and what they are offering to get vulnerabilities reported to them doesn’t offer. One notable element is having a software bill of materials (SBOM) to help make sure known vulnerable libraries are not in software:

In order to facilitate vulnerability analysis, manufacturers should identify and document components contained in the products with digital elements, including by drawing up an SBOM. An SBOM can provide those who manufacture, purchase, and operate software with information that enhances their understanding of the supply chain, which has multiple benefits, in particular it helps manufacturers and users to track known newly emerged vulnerabilities and cybersecurity risks. It is of particular importance that manufacturers ensure that their products with digital elements do not contain vulnerable components developed by third parties. Manufacturers should not be obliged to make the SBOM public.

As we noted last week, a plugin whose developer claims Patchstack is ensuring is secure contains two libraries with known vulnerabilities, one on which has been publicly known to be vulnerable for 21 months. Our Plugin Scorecard checks if a plugin has a listed SBOM.

The CRA also requires that an assessment is done of the security of software:

In order to ensure that products with digital elements are secure both at the time of their placing on the market as well as during the time the product with digital elements is expected to be in use, it is necessary to lay down essential cybersecurity requirements for vulnerability handling and essential cybersecurity requirements relating to the properties of products with digital elements. While manufacturers should comply with all essential cybersecurity requirements related to vulnerability handling throughout the support period, they should determine which other essential cybersecurity requirements related to the product properties are relevant for the type of product with digital elements concerned. For that purpose, manufacturers should undertake an assessment of the cybersecurity risks associated with a product with digital elements to identify relevant risks and relevant essential cybersecurity requirements in order to make available their products with digital elements without known exploitable vulnerabilities that might have an impact on the security of those products and to appropriately apply suitable harmonised standards, common specifications or European or international standards.

As we will cover in a follow up post, Patchstack is admitting to not properly vetting vulnerability reports, so they are not even close to doing these assessments. Our Plugin Scorecard checks if a plugin is listing the URL of a security review done of the plugin.

Patchstack Promotes being Funded by European Union

While Patchstack is trying to use the CRA to mislead developers and creating additional security risk for the WordPress community, they are claiming on their website to be funded by the European Union:

It appears that the precursor to Patchstack, WebARX, had received funding back in 2021.

It doesn’t seem like the EU would be happy to be associated with a company trying to profit off o misleading the public about their legislation.

23 Jan 2025

New Plugins From Awesome Motive and Brainstorm Force Continue Developers’ Failure to Implement Basic Security

We release advisories warning about WordPress plugin developers who have a repeated track record of failing to handle security well. A reasonable question to ask is if a backward-looking determination is helpful or if past is not prologue with that. A week ago, we looked at an example of a developer continuing to fail that we ran across. This week we ran across another test of this, as two developers we have released advisories for have new plugins available in the WordPress Plugin Directory.

Awesome Motive

For one of those developers, Awesome Motive, we just issued our advisory on December 11. Nine days later, they introduced the plugin WPConsent to the WordPress Plugin Directory. The issue that led to us finally issuing that advisory was a continued failure to address AJAX accessible functions lacking a capability check in the 6+ million install plugin WPForms, even after fixing a vulnerability caused by that. That is really basic security, so a major plugin developer shouldn’t be failing on that front. Yet it also is the case with WPConsent.

In the plugin’s file /includes/admin/admin-ajax.php, there are six AJAX accessible functions registered to only be accessible to only those logged in to WordPress. There should be a capability check to make sure the only intended users have access to the functionality, but there isn’t. Here is the first of those, which only contains a nonce check and not a capability check:

function wpconsent_ajax_add_category() {
	check_admin_referer( 'wpconsent_add_category', 'wpconsent_add_category_nonce' );
 
	$category_name        = isset( $_POST['category_name'] ) ? sanitize_text_field( wp_unslash( $_POST['category_name'] ) ) : '';
	$category_description = isset( $_POST['category_description'] ) ? sanitize_textarea_field( wp_unslash( $_POST['category_description'] ) ) : '';
 
	$category_id = wpconsent()->cookies->add_category( $category_name, $category_description );
 
	if ( $category_id ) {
		wp_send_json_success( array(
			'id'          => $category_id,
			'name'        => $category_name,
			'description' => $category_description,
		) );
	} else {
		wp_send_json_error( array(
			'message' => esc_html__( 'There was an error adding the category.', 'wpconsent-cookies-banner-privacy-suite' ),
		) );
	}
}

While Awesome Motive shouldn’t have a problem handling security like this (they have a chief security officer who is the Security Reviewer on the team running the WordPress Plugin Directory), it would have only, for example, cost $200 for us to do a comprehensive security review that would have caught that and a variety of other possible issues.

The plugin is yet another GDPR related plugin that isn’t secure.

Brainstorm Force

So that shows that a developer that isn’t handling security continues to do so in the short term, but what about in the longer term? We issued an advisory at the beginning of January of last year for Brainstorm Force. A year later, they introduce SureDash. This plugin contains exactly the same issue as Awesome Motive’s plugin across even more functions.

One example is this function in the file /core/ajax/backend.php:

public function delete_a_sub_content(): void {
	if ( ! check_ajax_referer( 'portal_delete_a_sub_content', 'security', false ) ) {
		wp_send_json_error( [ 'message' => $this->get_ajax_event_error( 'nonce' ) ] );
	}
 
	$sub_content_data = ! empty( $_POST['subContentData'] ) ? Sanitizer::sanitize_meta_data( json_decode( wp_unslash( $_POST['subContentData'] ), true ), 'metadata' ) : []; // phpcs:ignore WordPress.Security.ValidatedSanitizedInput.InputNotSanitized -- Data is sanitized in the Sanitizer::sanitize_meta_data() method.
 
	$post_id = ! empty( $sub_content_data['post_id'] ) ? absint( $sub_content_data['post_id'] ) : 0;
 
	if ( ! $post_id ) {
		wp_send_json_error( [ 'message' => __( 'Invalid post ID.', 'suredash' ) ] );
	}
 
	$deleted = \wp_delete_post( $post_id, true );
 
	if ( $deleted ) {
		wp_send_json_success(
			[
				'message' => __( 'Successfully deleted.', 'suredash' ),
			]
		);
	}
 
	wp_send_json_error( [ 'message' => $this->get_ajax_event_error( 'default' ) ] );
}

That code also has a second fairly obvious security issue. It passes user input to a function, wp_delete_post(), that allows deleting arbitrary content stored as a post. That would allow deleting not just WordPress posts and pages, but other plugin’s data stored as a post. The code should make sure only the intended content is deletable, but it doesn’t.

While the plugin is in the WordPress Plugin Directory, it has this message “Please note that SureDash is currently in its Alpha stage and is not recommended for use on live production websites.” That hasn’t stopped the developers from charging hundreds of dollars for items related to an insecure plugin:

Getting a security review wouldn’t cost much more than they are charging there, as our price for a review would be $500.

17 Jan 2025

300,000 Install WordPress Plugin That Hasn’t Updated Insecure Library in 21 Months Claims Patchstack Ensures the Plugin is Secure

A week ago, someone checked the 300,000 install WordPress plugin FluentSMTP through our Plugin Security Scorecard. That identified multiple issues with the plugin:

The top issue was flagged for us to check on, as it detected that the plugin was using a version of a library that the developer of the library says has a security issue. We confirmed that the plugin did in fact include the version of the library detected by the tool, which has the security issue. We promptly reached out to the developer about that. A week later, we have yet to hear back from them and there hasn’t been an update to the plugin to address this.

The developer of the library disclosed the issue in April 2023, so the developer has had plenty of time to address it already.

On the contact page for the plugin, there is this FAQ item:

Q. How secure is FluentSMTP?

FluentSMTP utilized API and OAuth 2.0 connections to deliver WordPress emails. These are highly-secure methods so all your emails will be encrypted. We also have a dedicated security partner to ensure FluentSMTP won’t make your website vulnerable.

There isn’t any further information provided there about who the security partner is or what it is they are supposed to be doing to ensure the plugin “won’t make your website vulnerable.” That claim doesn’t line up with the security issue that has long been in the plugin.

So who is this security partner? It is Patchstack. Looking at the FAQ on the plugin’s page on the WordPress Plugin Directory, we noticed it states at one point, “We use Patchstack to manage our security report. Please report in the patchstack page.” Following the link, you end up at a page where Patchstack wants you to direct vulnerabilities reports away from the developer to them. That is something that the head of Patchstack has acknowledged isn’t ethical. It also isn’t going to ensure that the plugin is secure, only that Patchstack gets someone else to do all the work for Patchstack in filing out their vulnerability report for them.

What explains the discrepancy between the developer’s claim and the reality there? It could be that Patchstack misled them as to what is going on. It could be that they are trying to mislead others as to their security (it wouldn’t be the first plugin to that.) It could be something else.

What our tool identified isn’t a vulnerability based on what we know about, only a security issue. It could be a vulnerability, but it isn’t our job to try to figure that out, only to report it to the developer. That can’t be done through Patchstack as they only accept certain reporting certain types of vulnerabilities. (This part of a wider problem that also affects WordPress.) Patchstack also requires agreeing to a legal agreement to report things that way, “I have read the Submission guidelines and accept the Terms of services & Privacy policy.” It is an odd thing to demand of someone trying to help the developer, but Patchstack doesn’t appear to be trying to do that. If they were, they could have identified this issue and let the developer know about, instead of trying to divert vulnerability reports to themselves.

16 Jan 2025

1+ Million Install WordPress Plugin Has Been Using an Outdated Known Insecure Version of a Library For Nearly 3 Years

Last year we created the Plugin Security Scorecard tool to help the WordPress community to have a better understanding of the security of plugins and hopefully to get better practices more widely implemented. As part of our work on that, we have been continuing to expand its capability to identify when plugins are using outdated and known insecure/vulnerable third-party libraries. That capability either doesn’t exist elsewhere in the community or isn’t being used. That is highlighted with a plugin that was checked through the plugin today.

The plugin checked was the 1+ million install plugin SVG Support, which had several issues identified:

The first one is the one of most concern. The plugin contains an outdated version of the svg-sanitizer that has known security issue according to the developer of the library. The developer hasn’t provided any details of the issue, so we can’t determine the severity of the issue or if the plugin uses the library in a way that makes this a vulnerability in the plugin. What does stand out is that their security advisory was released on Feb 12, 2022. That came out the same day the version that fixed this was released. The plugin is still using the previous version.

Our Plugin Security Scorecard also noted the out of date version of the library in use:

Checking the support forum on the WordPress Plugin Directory to see if someone had already brought this up, we found that there were multiple topics about security issues in the plugin, but this had gone unnoticed. That includes when the plugin was removed from the directory in July apparently because of a claimed vulnerability in it. That the team running the plugin directory isn’t exactly surprising considering the known problems with properly vetting the security of plugins and their hostility to working with others to address that.

We notified the developer of the plugin’s usage of the outdated and insecure version of the svg-sanitizer library.

15 Jan 2025

WordPress Security Header Plugins Still Claiming to Provide Protection With Headers That Web Browsers Long Ago Stopped Supporting

In looking into complaints about the search functionality of the WordPress Plugin Directory recently, a common complaint we saw is that new plugins don’t get promoted. As part of an alternative search functionality we have been putting together, we decided to try to address that in part by including a new plugin after the first ten results for queries. When doing a search on “security,” that currently highlights a security headers plugin:

The listing for that plugin, HTTP Security Header, now includes a warning about the plugin “being marketed with a strong claim (or claims) of efficacy without citing evidence that backs up the claim.” That is in reference to this claim made on the plugin’s page on the plugin directory:

Security headers are essential for protecting your WordPress website against common attacks, including cross-site scripting (XSS), clickjacking, content sniffing, and certificate transparency issues.

There is no evidence provided to support the claim. It also isn’t true. One security header could, if configured correctly, provide real security. (That header isn’t easily to broadly implement in an automated fashion.) But others don’t provide any practical security to the average WordPress website.

Among the reasons why these headers are of limited value is that headers tell web browsers to do or not do things. They don’t stop an attacker from taking actions, since they can just ignore them. They can only stop a victim from being exploited, assuming they would stop an attack that is actually happening.

Another issue is that if these headers were actually essential for the security of WordPress websites, why isn’t the developer pushing for WordPress to implement those instead of suggesting installing their plugin? That is a broader issue in the WordPress space, that is conspicuously ignored by supposed journalists and others.

It would appear the developer of the plugin doesn’t have even a basic understanding of those security headers, as at least two of the headers their plugin adds to the website have not been supported by web browsers for years.

Here is a note that Mozilla provides for one of those, Expect-CT:

Note: The Expect-CT is mostly obsolete since June 2021. Since May 2018, all new TLS certificates are expected to support SCTs by default. Certificates issued before March 2018 were allowed to have a lifetime of 39 months, so they had expired in June 2021. Chromium plans to deprecate Expect-CT header and to eventually remove it.

The note is outdated, as Chromium removed the code for this in December 2022 (it was already disabled).

With the other header, X-XSS-Protection, Mozilla has this warning that the header can actually create vulnerabilities:

Warning: Even though this feature can protect users of older web browsers that don’t support CSP, in some cases, X-XSS-Protection can create XSS vulnerabilities in otherwise safe websites. See the Security considerations section below for more information.

The Chrome web browser removed support for the header in October 2019. Firefox never supported it.

The plugin does have a glowing review that it improved the security of someone’s website:

I recently integrated the Security Header plugin into my WordPress site, and it has significantly improved my website’s security posture. The user-friendly interface made it easy to enable essential HTTP security headers with just a few clicks.

It was left by the developer of the plugin!

securityheaders.com Strikes Again

The idea that security headers are actually important for protecting WordPress websites seems to often trace back to a website that provides grades based on usage of security headers, securityheaders.com, without providing evidence that these grades actually correlate with improved real world security. Worse still, the developer has actually removed checks for headers they previously claimed were important.

This plugin looks to trace back to that as well, as the screenshots shown for the plugin are of grades on that website.

Other Plugins Also Include These Headers

This plugin isn’t alone in making unsupported claims about security headers and promoting using headers that are no longer supported by web browsers. A quick look showed that plugins with 100,000+, 70,000+ installs, and 50,000+ installs are still promoting the Expect-CT header despite it not serving a purpose at this point. Among other plugins, a million+ install security plugin from a major web host includes tfhe X-XSS-Protection header and claims it provides “Advanced XSS Protection.” That the developer, Siteground, is doing that is likely explained by their utter lack of understanding of security.

10 Jan 2025

Automattic Employee Changed WordPress Plugin Directory Search Algorithm to Promote Automattic’s Jetpack Plugin

As part of working on our Plugin Security Scorecard last year, we spent a fair amount of time using the search functionality of the WordPress Plugin Directory. Through that, we again and again ran across search results that prominently featured plugins with high install counts that were not relevant to the search results, while relevant plugins were sometimes buried later in the results.

One of the examples were you can see that happening is on a search for “translation”, which has as its fourth result, a 3+ million install backup plugin:

Similarly, a search for “export” brings up an 8+ million install ecommerce plugin in the sixth spot:

A search for “events” brings up a 5+ million install security plugin ahead of events related plugins:

We could go on and on like that.

This is a Known Issue

After seeing that, a search of the Trac ticket system for the WordPress website found an open issue related to this. That ticket noted that “plugin search greatly favors the plugins with the most installations.” There was a response from an employee of Automattic, who appears to control the weighting of the search results, that made this claim:

The goal behind the ranking alg is giving end users the best plugin experience possible. The user is trying to solve a problem and plugins that have a larger install count are much more likely to provide good long term support. There are also a number of other factors used in the alg that help newer plugins improve their rankings (support thread resolution, ratings, etc).

An irrelevant plugin with a high install count isn’t going to better solve a problem than a relevant plugin with a smaller install count. Plugins can have high install counts, not because they are better, but because they are being automatically installed by other plugins or web hosts. Developers can and sometimes do radically change a popular plugin that gained a high install count to do something very different (sometimes with serious negative security implications).

What Explains the Results?

There is another explanation that comes to mind for the poor weighting of the results. It benefits someone. Who would it benefit? It would benefit the developer of a plugin that has packed a lot of unrelated functionality in to one plugin and it has millions of installs. As their plugin would rank highly across a wide range of searches even when it is less relevant than plugins that offer more targeted functionality. Who has that plugin? Automattic with its Jetpack plugin. The same Automattic that employs the person controlling the weighting.

If that were true, you would assume that person wouldn’t have openly admitted to weighting the search results to promote Jetpack. Amazingly, they did and linked to a post on an Automattic blog touching on that in the Trac ticket. The most relevant portion is this:

I expressed this on the search relevancy ticket and I know that some of it is controversial. Opinions usually are. Let me try an example. (Disclaimer: I’ve worked on Jetpack Stats in the past.)

Users search for “stats” 93 thousand times a year. (It’s the 13th most frequent search on the plugin directory.) Here are the top four search results with the old algorithm:

The old search suggests that 90 thousand people per year go and install plugins that collectively, have only proven that they can “handle” 20 thousand users. Scaling stats as a service (as many plugins do) can be quite hard and expensive. Sending 90k new users per year to these plugins seems unrealistic. Even if the plugin doesn’t work as a hosted service, it still needs to scale answering support requests from end users.

Let’s compare that to the top four suggestions from the new search algorithm:

Among the issues there, an Automattic employee had access to what the top search results are. They don’t appear to be made public. That person not only works for Automattic, but was involved in the feature of Jetpack he is admitting to shaping the algorithm to push it to a top result.

We should note that it would possible to provide more relevant results while keeping Jetpack ranking high for stats, but it would not rank highly for other terms it does now.

In another Trac ticket linked to in the quoted texted above, there are a lot more concerning things mentioned. In that, he states that there are only two real options for statistics:

There are really only two options in the world that can work for a hundred thousand sites a year: Google Analytics and Jetpack.

Notably, neither of those options are handled by plugins, but third-party services that a plugin can connect to. Relying on a third-party service can have a big downside, that many recent negative reviews of Jetpack are highlighting. Automattic started charging a lot of money for the previously free stats. It also seems incongruous with WordPress, which is an opensource project.

Elsewhere, he says he is worried about people trying to game the search results:

I certainly understand the concern, and that is a big part of the reason I am going into such depth on this ticket with my thinking. The search query is all out in the open for folks to see it (which was a big discussion because we are worried about people trying to game it).

Which is exactly what he is doing.

Another aspect is that the install count outweighing relevancy was noted in 2016:

It seems to many weight is given on active installs other relevancy which cause some plugins to be in almost every search result, like MailPoet or TablePress.

It wasn’t fixed.

Bizarrely later in the ticket, thread the Automattic employee claims everyone agrees what he has done is better than the previous result, despite there being numerous comments expressing the exact opposite opinion:

So from my perspective the current search is not at all answering the question of “what plugin would serve me best for tracking stats on my website?”. Everyone seems to agree that the new search is significantly better. Personally, I still think it is pretty bad and has lots of room for improvements, but its a good start.

Lack of Conflict of Interest Policy

A fairly obvious question this should raise is isn’t this against WordPress’ conflict of interest policy? It seems like it should be, but there isn’t a conflict of interest policy.

Automattic Doesn’t Use This Algorithm for Their WordPress.com Plugin Search

In 2023, there was controversy over the copy of the WordPress Plugin Directory that Automattic had created on WordPress.com and how it was outranking the original in Google’s search results. Notably, Automattic has chosen not to use the same search algorithm despite it having been created and maintained by one of their employee. That can be seen by looking at the results for “translation”:

The backup plugin isn’t in the results.

Alternative Search Options

Seeing as the poor state of the results of the WordPress Plugin Directory is not seen as a mistake and unlikely to be fixed, trying to work to fix it seems futile at this point. The next option would be to look for alternative options. There are now two that we are aware of.

One has existed since last year, called Ploogins. That is marketed as being a “Cutting-edge AI-Driven WordPress Plugin Advisor”. In our testing, the results of doing the types of queries they suggest provide results that look the same if you did a simpler keyword search. The AI element does create a significant lag in producing the search results versus alternatives. The search also includes some premium plugins. There are some glaring limitations, like a limit of 21 results to filter from, and months out of date information in some cases. Overall, it is a better alternative to WordPress’ broken results, but there is a lot of room for improvement.

The second option is our own search tool that we have soft launched. While still early in development, across a range of test queries, it has been providing relevant results while not have the same performance issue as Ploogins. We also give searchers more control of what they are searching on. For example, if you want to search by plugin author, you can do that. Or search only for plugins that extend WooCommerce or Elementor, you can also do that.

A good example of how different the results are across the three options is a search for “series”, which we came across as being mentioned as one the searches that the WordPress Plugin Directory produced bad results for in the past. With the WordPress Plugin Directory search, only the first result looks relevant:

Ploogins only has a few results, but two that are relevant:

Hidden away are more relevant results, though plugins that don’t appear to be supported by their developers anymore:

Whereas our search exposes those plugins as well:

You can also see from that that we are incorporating our Plugin Security Scorecard grades in to the results. Our rankings incorporate that as a minor ranking factor as well.

In light of what has been going on with WordPress recently we are working to include not just plugins from the WordPress Plugin Directory, but elsewhere in the ecosystem. We include plugins from WooCommerce.com (filtering out those also in the WordPress Plugin Directory), the Not WP Repository, and we just started adding plugins from CodeCanyon. We also allow developers of plugins not in any of those, the option to provide information on their plugins in a JSON formatted file to incorporate those plugins in our search results (those files could also be used by other search providers as well).

17 Sep 2024

WordPress Plugin Security Review: Two Factor

Before we start using a new WordPress plugin on our website, we do a security review of it, which led to us doing one for Two Factor. That is also now one of the plugins covered our new Continuous WordPress Plugin Security Review service to identify if updates to plugins have introduced new security issues after we have completed a review of it.

If you want a security review of plugins you use, when you become a paying customer of our service, you can start suggesting and voting on plugins to get security reviews from us. For those already using the service that haven’t already suggested and voted for plugins to receive a review, you can start doing that here. You can use our tool for doing limited automated security checks of plugins to see if plugins you are using have possible issues that would make them good candidates to get a review. You can also order a review of a plugin separately from our main service.

The review was done on version 0.9.1 of Two Factor. We checked for the following issues during it as part of our standard review:

Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
Deserialization of untrusted data
Security issues with functions accessible through WordPress’ AJAX functionality (those have and continued to be a common source of disclosed vulnerabilities)
Security issues with functions accessible through WordPress’ REST API (those have started to be a source of disclosed vulnerabilities)
Persistent cross-site scripting (XSS) vulnerabilities in the frontend portions of the plugin and in the admin portions accessible to users with the Author role or below
Cross-site request forgery (CSRF) vulnerabilities in the admin portion of the plugin
SQL injection vulnerabilities (the code that handles requests to the database)
Reflected cross-site scripting (XSS) vulnerabilities
Security issues with functions accessible through any of the plugin’s shortcodes
Security issues with functions accessible through any of the plugin’s blocks
Security issues with functions accessible through the admin_action action
Security issues with functions accessible through the admin_init action
Security issues with functions accessible through the admin_post action
Security issues with import/export functionality
Security issues with usage of the is_admin() function
Security issues with usage of the add_option(), delete_option(), and update_option() functions
Security issues with usage of the update_user_meta() and wp_update_user() functions
Security with usage of determine_current_user filter
Security issues with usage of the wp_set_current_user(), wp_set_auth_cookie() and wc_set_customer_auth_cookie() functions
Security issues with usage of the reset_password() and wp_set_password() functions
Security issues with usage of the extract() function
Lack of IP address validation
Proper usage of sanitize_callback when using register_setting() to register settings
Existence of register_uninstall_hook or uninstall.php file that removes any WordPress options and database tables added by the plugin
CSV injection
Host header injection vulnerabilities
Lack of protection against unintended direct access of PHP files
Insecure and unwarranted requests to third-party websites
Any additional possible issues identified by our Plugin Security Checker

Results

We found two places where security could be improved.

We have reached out to the developer about the lack of proper uninstallation. This is the second review we have completed since we introduced a check for that and the second one lacking a proper uninstall process. That followed another review where that was an issue, which led to us to start checking for that. It is a problem even for some of the most popular plugins.

Lack of Proper Uninstallation

The plugin doesn’t implement one of WordPress’ methods for properly handling uninstalling the plugin. That leads to configuration information for users’ preferred second factor of authentication to be left behind in the WordPress database.

Lack of Protection Against Direct Access to PHP Files

The plugin’s .php files do not have code at the beginning of the files to restrict direct access to them. We didn’t see anything that could be exploited in the files without the restriction in place, but adding the code the plugin already has in other files would make things more secure.

26 Feb 2025

Developer of 1+ Million Install WordPress Plugin Warned Multiple Times of Known Vulnerable Library in Plugin and Still Hasn’t Addressed It

Yesterday, we covered our finding that the 1+ million install WordPress plugin WP File Manager contains a known vulnerable version of the JavaScript library jQuery UI. While following up on another element of that situation, we ran across the developer of the library having been warned publicly about that twice in the past. The developer responded both times that they would address it and then didn’t. That also means that they knew about the problem with another library and didn’t warn the developer of it.

The first notification was in April 2023 and the response from the developer then was: [Read more]

25 Feb 2025

Popular WordPress File Manger Plugins Contain Third-Party Library With Multiple Vulnerabilities

Last week three WordPress file manager plugins were checked through our Plugin Security Scorecard tool. An issue identified by the tool in each plugin was flagged for us to review. That issue being that the plugin’s contained a known vulnerable library. What was curious was is that each plugin was flagged for the exact same vulnerabilities in the same library. Here is the relevant part of the results for the 1+ million install WP File Manager:

[Read more]

24 Feb 2025

Settings Change and Persistent Cross-Site Scripting (XSS) Vulnerabilities in Donate visa

Today we saw what appeared to be a hacker probing for usage of the WordPress plugin Donate visa in third-party data we monitor. The probing was done by requesting a file from the plugin if the plugin had existed on a website, /wp-content/plugins/donate-visa/readme.txt. The plugin was closed on the WordPress Plugin Directory on November 5, 2024. The reason given for the closure is “Security Issue.” Nothing was provided to vet the claim there was a security issue. Competitors of ours have claimed there is an unfixed vulnerability that allows attackers “with Subscriber-level access and above, to perform an unauthorized action.” They provided nothing to back that up. Looking at the code, we found what they appear to be referring to, but as is so often the case, they didn’t bother to do proper vetting and got a basic detail wrong. The real vulnerability is one you would expect to be exploited.

The only code that looks like it could be related to the claimed vulnerability is the code that handles saving the plugin’s settings. That is handled by the function donate_visa_dvsmp_ajax() in the file /includes/class-donate-visa-dvsmp-plugin.php. That doesn’t include any security checks: [Read more]

21 Feb 2025

The Good and Bad of Unexplained Change to WordPress Plugin Directory That Exposes Owners of Plugins

Yesterday, the team running the WordPress Plugin Directory announced they had recently made a significant change to the directory. No explanation was given for why it was done. Nor why it was done without warning or discussed beforehand. The change has some positive benefits, but also some apparent downsides. The change is what is shown as the author of a plugin. Here is an example of the change. The 400,000+ install plugin NextGEN Gallery used to be listed as being by Imagely:

[Read more]

20 Feb 2025

Backdoor Code Routes Malicious Actions Through WordPress REST API

Website hackers are not exactly known for their sophistication, other than in the misleading portrayals put forward by too many security companies and security journalists. But sometimes malicious actors can do things that are more sophisticated. In the latest instance of that we ran across, they also screwed up. Checking on a website today, we found that there was visible code showing on the top of the website:

[Read more]

14 Feb 2025

Hacker Probing For WordPress Plugin With Many Vulnerabilities That Wordfence and Other Providers Incorrectly Claimed Were Fixed Last Year

Today we saw what appeared to be a hacker probing for usage of the WordPress plugin WP Compress on our websites. The probing was done by requesting a file from the plugin if the plugin had existed on our website, /wp-content/plugins/wp-compress-image-optimizer/readme.txt. We don’t use that plugin on that website or any of them. So what might explain a hacker’s interest in the plugin? Last year the WordPress security provider Wordfence claimed that a vulnerability had been fixed in the plugin, of a type that sounds like it could explain a hacker’s interest. Here is part of their description:

This makes it possible for authenticated attackers, with subscriber-level permissions and above, to edit plugin settings, including storing cross-site scripting, in multisite environments. [Read more]

11 Feb 2025

WordPress Plugin Developers’ Assurances Their Plugins Are Secure Continue to Not Bear Out

We recently ran across a WordPress plugin developer claiming that a security partner was ensuring their plugin was secure. We had run across the plugin because the developer had continued to use a known vulnerable third-party library for 21 months. It turned out to not be the only known vulnerable library in the plugin. There also is an additional unfixed security issue caused by the security partner, Patchstack, failing to make sure a vulnerability was properly fixed or to provide the information needed for others to vet their false claim it was fixed. They are hardly the only plugin developer claiming that their plugins are secure. Can you trust their claims?

One way to try to determine the answer to that would be to look at the evidence they providing to back the claims up. But they don’t provide any. For example, the developer of the 80,000+ install WP ULike provides this information in a FAQ in response to the question “Is WP ULike secure?”: [Read more]

10 Feb 2025

WordPress Plugin Includes Version of Third-Party Library That Was Publicly Known to Be Vulnerable Years Before Plugin Was Even Released

As part of providing a more comprehensive view of the handling of the security of WordPress plugins through our Plugin Security Scorecard tool, we have been expanding the number of third-party libraries it can detect in plugins. If developers of those libraries disclose security advisories on GitHub for those libraries, we incorporate them into the results of the tool as well. Last week we added detection for the jQuery UI JavaScript library. It has already had someone run a plugin through the updated tool that caught the plugin containing a version of a library that contains multiple vulnerability according to the developer:

[Read more]

10 Feb 2025

WordPress Plugin Security Review: AspireUpdate

As part of the ongoing situation between Matt Mullenweg and the WordPress community, there has increased concern about various aspects of WordPress. One area of concern is the continued ability to get updates for WordPress software from the WordPress update infrastructure. That led to the release of a new plugin, AspireUpdate, as part of a larger project to provide alternative infrastructure, AspirePress. As part of our focus on supporting efforts to reform WordPress, we decided to do a security review of the plugin.

If you want a security review of plugins you use, when you become a paying customer of our service, you can start suggesting and voting on plugins to get security reviews from us. For those already using the service that haven’t already suggested and voted for plugins to receive a review, you can start doing that here. You can use our tool for doing limited automated security checks of plugins to see if plugins you are using have possible issues that would make them good candidates to get a review. You can also order a review of a plugin separately from our main service. [Read more]

4 Feb 2025

Patchstack Isn’t Actually Patching Vulnerabilities

You would reasonably think that a security company named Patchstack would be focused on patching security vulnerabilities, but it turns out they are not. In fact, they are actually making it harder for vulnerabilities to get patched.

If you head over to Patchstack’s homepage, they currently claim at the top of the page to offer the “fastest protection for WordPress security vulnerabilities” and claim to have
9,100+ virtual patches to protect you:” [Read more]