Plugin Vulnerabilities

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.

24 Jan 2025

New Insecure WordPress Plugin Marketed With Fake Norton Secured and (Retired) McAfee SECURE Security Seals

Yesterday, we reported on a new plugin from a WordPress plugin developer Brainstorm Force with a long track record of poor security, unsurprisingly was also insecure. One thing that we noticed while looking into that is on the homepage for that new plugin, SureDash, was that midway down the page, there are a couple security seals, Norton Secured and McAfee SECURE, around the logo for PayPal:

[Read more]

24 Jan 2025

WordPress Plugin Review Team Reviews Failing to Catch Basic Security Failure (Including in a Plugin From the Team’s Security Reviewer)

At the end of last year, one of the team reps for the team running the WordPress plugin directory provided an assessment on what the team had been up to. It incredulously credited one past member of the team for a “magnificent legacy” of a scanner tool, despite it being no secret that person had blocked efforts for years to improve the team’s scanner tool (and more generally blocked efforts to address the problems they were causing). Beyond that, it made repeated claims about the team’s handling of security, including this in the first paragraph:

Throughout this time, we remained focused on our primary goals: enhancing security, improving the review process, and fostering community engagement. [Read more]

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.

23 Jan 2025

Our Plugin Security Scorecard Now Supports Checking ClassicPress Plugins

While the WordPress fork ClassicPress has gotten renewed attention with what has been going on with WordPress recently, we have had efforts related to the security of its plugins for years. Back in 2021, we started doing proactive monitoring to try to catch serious vulnerabilities in plugins that were in the ClassicPress plugin directory. Alongside that, we ran the plugins through our Plugin Security Checker, which leads to us detecting a less serious vulnerability. The developer promptly fixed the issue, which isn’t something we can say that often with WordPress plugin.

Last year we introduced a new tool, the Plugin Security Scorecard, which seeks to provide a better understanding of the security of WordPress plugins, as well as promote developers implementing better security practices. The tool continues to highlight the poor state of even some of the most popular WordPress plugins. Last week, for example, a 1+ million install plugin was run through the tool and found to contain a version of a third-party library that had been know to be insecure for nearly three years. [Read more]

22 Jan 2025

Plugin That Patchstack Is Claimed to Ensure Is Secure Contains an Additional Outdated Known Insecure Library

Last week we talked about two popular WordPress plugins that had been run through our Plugin Security Scorecard and identified as containing a rather out of date version of third-party libraries, which according to the libraries developers, contained a security issue. The libraries in question were different in the plugins, but it turns out they also have another library in common, where they are both using outdated known insecure versions. One of those is the 1+ million install SVG Support, where someone reported to the developer at the end of October that it was also using an outdated and known insecure version of the library DOMPurify. There still hasn’t been an update to the plugin to address that. More people have been reporting that issue. After seeing that, we started looking in to adding a check for DOMPurify to our Plugin Security Checker. Through that, we found a couple of fairly popular plugins are also still using older versions that the developer of the library is insecure.

We contacted the developer of one of those yesterday to let them know about the problem. The version they are using is subject to issues that were publicly disclosed by the developer of the library in September and October. There are not any topics on the support forum for the plugin about that, which is interesting considering the other plugin had multiple people reported it to the developer. [Read more]

22 Jan 2025

WordPress Plugins Can Include a Lot of Software That the Plugin’s Developer Doesn’t Have Any Connection To

How much do you consider a WordPress plugin developer’s handling of security of their plugins when choosing to use or not use a plugin? Probably not much, considering even if you wanted to, your access to information to make an informed assessment is limited. That is also backed up by the popularity of plugins from developers that have long track records of very public indifference, at best, to security. Depending on the plugin, you have to be worried about not just their handling of security, but the handling of security by developers of third-party libraries that are included in their plugin.

The amount of third-party in some plugins has surprised us. As part of working on our Plugin Security Scorecard since last year, we have been expanding the amount of libraries it can provide information on and warnings when there are publicly known security issues. A few days ago, the security plugin Shield Security was run through the tool again and more libraries were flagged to be included in our data set. There were 5 more libraries in for us to see about adding, that is on top of the 47 that were included in our dataset that are in the plugin. That is a lot of third-party software being included in a plugin originally called WordPress Simple Firewall. [Read more]

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.

17 Jan 2025

Two-Factor Authentication (2FA) Won’t Stop an Attacker From Using Their Own WordPress Account to Engage in Malicious Activity

Two-Factor Authentication (2FA) Won’t Stop an Attacker From Using Their Own WordPress Account to Engage in Malicious ActivityTwo-factor authentication (2FA) can be useful for securing WordPress websites in certain circumstances, but it is often touted as being useful for things it isn’t needed for or capable of helping with. We often see it claimed that people should use it to protect against brute-force attacks against WordPress admin passwords. That is, despite those attacks continuing to not happen. Using a 2FA when you don’t need to can even create vulnerabilities that would allow an attacker access to your website, so understanding what it can and can’t do is important.

Another place 2FA isn’t the solution for is when an attacker is using their own WordPress account. That was part of the advice with a recent claim of a malware campaign against WordPress websites. The source for that was claiming that the hacker would cause a new WordPress account with the Administrator role to be created. They did that by causing someone already logged in as Administrator to make that happen without them taking any action. The source was then suggesting implementing 2FA to stop the attacker. [Read more]

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.