Plugin Vulnerabilities

24 Mar 2025

Developer Outsourcing Security Reporting to Bugcrowd Has Left Insecure Library in WordPress Plugin for Nearly 5 Years

Last week someone checked a WordPress plugin through our Plugin Security Scorecard, which flagged the plugin for a variety of issues:

Three of the issues identified are related. The plugin includes the jQuery JavaScript library, despite that already being included in WordPress. As that is already included in WordPress, the rules of the WordPress Plugin directory state that for “security and stability reasons plugins may not include those libraries in their own code.” That seems like a good idea, as plugins keep getting flagged by the Plugin Security Scorecard as using known insecure versions of those included libraries. This plugin being another example. The developer disclosed two related security issues in the version of the library being used in April 2020.

After we were alerted to that situation, we preceded to see how we could get in touch with the developer, Campaign Monitor by Marigold. Surprisingly, considering the insecurity identified by the tool, their website contains a security.txt file with information on contacting them about security issues. In line with the insecurity, reports are being directed to Bugcrowd instead of handled by the developer. That shouldn’t be happening. As Bugcrowd can’t address the problem, they are an unnecessary intermediary here.

(While having a security.txt file is commendable, it has an expiration date of June of last year. The vulnerability disclosure policy link is to a Terms of Use of page, which isn’t what should be linked to, instead of to their Responsible Vulnerability Disclosure page linked on the vulnerability reporting page.)

As is common with bug bounty security companies, Bugcrowd are trying to mislead people in to believing that ineffective methods to secure software are not ineffective. For example, on their homepage, they claim that developers prove they are doing “everything possible to protect stakeholders by accepting vulnerability reports from the public:”

That doesn’t align with what has happened here. Being proactive about security instead of reactive would actually show everything possible is being done.

The homepage also heavily promotes that Bugcrowd is focused on finding hidden risks that other solutions miss:

As can be seen here, developers are not addressing non-hidden risks that could easily be addressed, so that should be focused on first. The likely explanation for promoting something else is that useful security work isn’t cheap for those providing it. While acting as an unnecessary intermediary can be very profitable.

18 Mar 2025

WordPress Plugin Developer Security Advisory: CleanTalk

One of the little understood realities of security issues with WordPress plugins is that the insecurity of them is not evenly spread across those plugins. Instead, many developers are properly securing their plugins and others get them properly secured when alerted they haven’t done that. A smaller number of plugin developers either are unable or unwilling to properly secure their plugins. With the latter group, among the issues we have seen, are developers who have introduced new serious vulnerabilities that are substantially similar to vulnerabilities that they know have been exploited in their plugins.

In situations where we become aware of developers who have shown that inability or unwillingness to properly secure their plugin, we are releasing advisories to warn customers of our service and the wider WordPress community of the risk of utilizing those developers’ plugins. In addition to checking those posts on our website for information on those advisory, we provide access to the information in several other forms. That includes through the companion plugin for our service, even when not using the service, as well as through a web browser extension and through separate data accessible from our website.

The latest addition to our advisories involves a developer, CleanTalk, who is a security provider. Not only a security provider, but one that claims to be doing thorough security testing of plugins before issuing what they claim is a prestigious security certification. They have issued certifications for their own plugins despite the certified versions containing vulnerabilities and other security issues their testing is supposed to catch.

Certification and Then Exploitable Vulnerability Disclosed

On August 1 of last year CleanTalk issued a Plugin Security Certification for their Spam protection, Anti-Spam, FireWall by CleanTalk. In November it was disclosed that the plugin had contained a serious vulnerability. That had existed in the version that CleanTalk claimed to have done their testing on. CleanTalk had not disclosed it in the changelog of the plugin when the vulnerability was fixed.

On September 17, they issued a Plugin Security Certification for their Security & Malware scan by CleanTalk. In February, it was disclosed that the plugin had contained a serious vulnerability. That had existed in the version that CleanTalk claimed to have done their testing on. CleanTalk had not disclosed it in the changelog of the plugin when the vulnerability was fixed.

In both cases, we saw what appeared to be hackers looking to exploit the vulnerabilities after they were disclosed.

That would be a series of events that you would reasonably think would lead to serious soul searching at the company, instead they have continued to not get their plugins secure and continued to issue these bogus security certifications. The latest one was issued today.

Claimed Security Testing Isn’t Happening

Less than a week after they issued the certification for the first of their plugins, we published a post detailing what we found when we vetted the security testing they were claiming to do. One issue we noted was that they were claiming to test for an issue, buffer overflow, that can’t even happen in WordPress plugins. Either they don’t understand what they are claiming to test for at all or they are assuming that no one else will. We also found that their plugin was insecure, and that insecurity led to a vulnerability. Other plugins they certified also appeared to be at least insecure.

No Response to Being Notified of Vulnerable Library

Two weeks ago, we published a post about their other plugin containing a third-party library that had been publicly known to be vulnerable since July 2022. One of the claimed tests they do as part of the certification is for insecure dependencies. The inclusion of that vulnerable library is an insecure dependency. The vulnerable library was in the version of the plugin that they claimed they tested, so it should have been dealt with by now.

Before publishing, we reached out to CleanTalk to notify them of that. Their plugins lack a security file that would provide information on how best to do that. Their website doesn’t include a security.txt file either. We used the general email address they provide. In the two weeks since then, we have yet to receive a response and the vulnerable library remains in the plugin.

Avoid CleanTalk’s Plugins

Hopefully, we shouldn’t have to tell you to avoid plugins from CleanTalk after what you just read, but we would recommend avoiding their plugins, unless they can show that they have made significant changes to their handling of security.

7 Mar 2025

WordPress Plugin Review Team Failing to Enforce Rule, Which is Leading to Popular Plugins Containing Vulnerable Libraries

As part of our work to expand the ability for our Plugin Security Scorecard to identify security issues in WordPress plugins, we have been increasing the number of third-party libraries it can detect being used in WordPress plugins and incorporating information on vulnerabilities the developers have disclosed in those. One place we have been doing that work is during security reviews of plugins. That led to us adding detection for the library jQuery UI to the tool and warning if plugins contain a version that has any of four vulnerabilities disclosed by the developer to have existed in older versions. In recent weeks, we have published several posts that partially focused on WordPress plugins that are using known vulnerable versions of the library. Those situations don’t paint a pretty picture when it comes to plugins usage of third-party libraries.

One of the plugins incorporated a vulnerable version of the library nearly 3 years after it was disclosed by the library’s developer to be vulnerable.

Three of the most popular file manager plugins also contain a vulnerable version of the library, including one with a million or more installs. The usage of a vulnerable version is in turn caused the developers’ failure to update the file manager library that is the basis for those plugins.

A security plugin also contains a vulnerable version of the library, despite the developer claiming to test plugins, including their own, to ensure they don’t contain insecure dependencies.

Plugins Are Not Supposed to Contain jQuery UI

It turns out that none of those plugins are even supposed to contain that library. The reason for that is that plugins in the WordPress plugin directory are not supposed to a library that already comes in WordPress:

13. Plugins must use WordPress’ default libraries.

WordPress includes a number of useful libraries, such as jQuery, Atom Lib, SimplePie, PHPMailer, PHPass, and more. For security and stability reasons plugins may not include those libraries in their own code. Instead plugins must use the versions of those libraries packaged with WordPress.

For a list of all javascript libraries included in WordPress, please review Default Scripts Included and Registered by WordPress.

On the linked page, one of the libraries listed as being included in WordPress is jQuery UI. The version of jQuery UI listed as being included in WordPress is a vulnerable version. That information isn’t accurate, which we will probably have more about in another post.

So these plugins shouldn’t include the library, but they are. It would be easy for the Plugin Review Team to detect this if they wanted to. It is hard to understand how the rule exist, but the team didn’t implement a system to enforce it. They have had plenty of time, as the rule was added in January 2017. The Plugin Check (PCP) plugin, which comes from WordPress and is described as “a tool for testing whether your plugin meets the required standards for the WordPress.org plugin directory,” doesn’t check if the library is included in plugins either.

Not The Only Library This is An Issue With

We have now updated the Plugin Security Scorecard to warn about inclusion of jQuery UI (in addition to warning if a vulnerable version is being used). We are in the process of adding checks for the other libraries included in WordPress. One of those is Thickbox. Among the plugins that include that is the 400,000 or more install NextGEN Gallery. That plugin comes from Awesome Motive, which has as their chief security officer, the Security Reviewer on the Plugin Review team, Chris Christoff.

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:

The 100,000+ install Advanced File Manager:

And finally the 80,000+ install Filester:

Was it just a coincidence that they all contained a vulnerable version of the jQuery UI library?

Before we reached out to the developers to let them know about that, we checked to make sure the tool’s information was correct. That led us to find each of them is based on the same library that provides the file manager, elFinder. The jQuery UI library is part of that library. So elFinder is still using a known vulnerable version of jQuery UI? No. The developer of that updated to a fixed version in December 2023.

So the developers of the file manager plugins haven’t bothered to update the core of their plugins in over a year. It isn’t like the developers of these plugins shouldn’t have security on their radar, prominently on the WordPress Plugin Directory page for Filester is this:

Did you know?
More than 700,000 WordPress websites were attacked during September 2020.
Malicious bots are looking to exploit vulnerable versions of WP file manager plugins.
Fortunately, Filester comes with this vulnerability fixed!
Filester poses no risk to you, so rest assured! 🤗

The developer of elFinder isn’t doing a great job either, as three of the jQuery UI vulnerabilities were disclosed by the developer of the library in October 2021 (1, 2, 3) and the last was disclosed in July 2022. If those incorporating the library in to their own solutions were more focused on security, that would help to avoid mistakes like that. But as these plugins show, that isn’t the case.

That the most popular of those plugins, WP File Manager, is affected by this shouldn’t be surprising as we have been warning not to use plugins from the developer since May 2022 because of their repeated poor handling of security. The plugin also still contains a minor vulnerability we warned the developer they had incompletely fixed a year ago.

We have notified the developers of the three plugins that their plugins contain the known vulnerable library caused by usage of an outdated version of elFinder.

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.

The last part of that is odd. Why would that only be possible in “multisite environments?” They didn’t provide any further details to explain. They provided two links without any context as to what they were supposed to mean. The links showed a couple of things. First Wordfence had failed to vet the fix, as even the code being changed was still vulnerable. One of the links shows code being changed to add a capability check, notably missing is the addition of a nonce check or a pre-existing nonce checks. So there was still at least cross-site request forgery (CSRF) vulnerability. A little more checking showed that the capability check was incompletely applied to file being changed.

In the file /classes/mu.class.php, the following function had a capability check added (the current_user_can() part):

public function mu_save_site_settings()
{
	if (!current_user_can('manage_options')) {
		wp_send_json_error('Forbidden.');
	}
 
	global $wpc_siteID;

The next function should have also had that added, but it wasn’t:

public function mu_get_site_settings()
{
	global $wpc_siteID;
	$output = '';
 
	$wpc_siteID = $siteID = sanitize_title($_POST['siteID']);
	ob_start(); // begin collecting output
 
	if ($this->mu_is_connected($siteID)) {
		include WPS_IC_DIR . 'templates/mu/connected.php';
		#include WPS_IC_DIR . 'templates/mu/site-settings.php';
	} else {
		include WPS_IC_DIR . 'templates/mu/not-connected.php';
	}
 
	$output .= ob_get_clean(); // retrieve output from myfile.php, stop buffering
 
	wp_send_json_success($output);
}

So even as described by Wordfence, the issue had only been partially fixed. It turns out the issue is still exploitable even when not using WordPress Multisite.

Plugin Vulnerability Data Providers Don’t Vet Their Data

That Wordfence got things so wrong runs counter to their claim to have a team of experts and their CEO Mark Maunder’s claim that their vulnerability “data is impeccable.”

They were not alone in that. WPScan, which also claims to have a team of experts, claimed the issue was fixed:

While also somehow claiming that they hadn’t verified it (somehow that is a miscellaneous detail):

Patchstack, also claims to have a team of experts, yet they also claimed it was fixed:

They are claiming to have provided a “virtual patch”, so either they knew the fix was incomplete and claimed otherwise, or their virtual patch is incomplete as well.

The reality is that WPScan and Patchstack simply copy information from Wordfence without vetting, despite Wordfence’s data being known to be unreliable going back to before it was public. (Wordfence also copies data from the other providers without vetting it.)

So Much is Vulnerable

When trying to determine what a hacker might be interested in exploiting related to this, you run into the problem that is so much code that is accessible it is hard to guess what a hacker might be interested. But to provide an example of what Wordfence and the other security providers somehow missed, let’s take a look at a function to change the plugin’s settings. In the file /classes/ajax.class.php, the function wps_ic_settings_change() is registered to be accessible through WordPress’ AJAX functionality to anyone logged in to WordPress:

126	$this->add_ajax('wps_ic_settings_change');

That function doesn’t include a capability check or a nonce check to limit access to changing the settings:

/**
 * Change Settings Value
 */
public function wps_ic_settings_change()
{
	global $wps_ic;
 
	$what = sanitize_text_field($_POST['what']);
	$value = sanitize_text_field($_POST['value']);
	$checked = sanitize_text_field($_POST['checked']);
	$checkbox = sanitize_text_field($_POST['checkbox']);
 
 
	$options = new wps_ic_options();
	$settings = $options->get_settings();
 
	if ($what == 'thumbnails') {
		if (!isset($value) || empty($value)) {
			$settings['thumbnails'] = [];
		} else {
			$settings['thumbnails'] = [];
			$value = rtrim($value, ',');
			$value = explode(',', $value);
			foreach ($value as $i => $thumb_size) {
				$settings['thumbnails'][$thumb_size] = 1;
			}
		}
	} else {
		if ($what == 'autopilot') {
			if ($checked == 'checked') {
			} else {
				$settings['otto'] = 'automated';
			}
		}
 
		if ($checkbox == 'true') {
			if ($checked === 'false') {
				$settings[$what] = 0;
			} else {
				$settings[$what] = 1;
			}
		} else {
			$settings[$what] = $value;
		}
	}
 
	if ($what == 'live_autopilot') {
		if ($value == '1') {
			// Enabline Live, clear local queue
			delete_option('wps_ic_bg_stop');
			delete_option('wps_ic_bg_process_stop');
			delete_option('wps_ic_bg_stopping');
			delete_option('wps_ic_bg_process');
			delete_option('wps_ic_bg_process_done');
			delete_option('wps_ic_bg_process_running');
			delete_option('wps_ic_bg_process_stats');
			delete_option('wps_ic_bg_last_run_compress');
			delete_option('wps_ic_bg_last_run_restore');
		}
	} elseif ($what == 'css' || $what == 'js') {
		// Purge CSS/JS Cache
		$this->purge_cdn_assets();
	}
 
	self::$cacheIntegrations->purgeAll();
 
	update_option(WPS_IC_SETTINGS, $settings);
 
	wp_send_json_success();
}

So anyone logged in to WordPress can change the plugin’s settings. An attacker could cause anyone logged in to change settings through CSRF as well.

More Issues Probably Exists

Our Plugin Security Scorecard and Plugin Security Checker tools flag the plugin as possibly having yet more security issues.

Developer Notified

We reached out to the developer earlier today to let them known about the incomplete fix and offered to help them address it.

Free Warning

As some part of the vulnerability might be targeted by hackers, we are adding accurate data on it to the free data that comes with our Plugin Vulnerabilities plugin.

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?”:

Yes, developed by TechnoWich, WP ULike follows the latest security and coding standards, with over 80,000 active users and a high WordPress rating.

The install count and rating don’t have any stated connection with whether it is secure or not. They do claim to follow “the latest security and coding standards,” but provide nothing to support that.

You can get an incomplete automated independent assessment of the handling of the security of WordPress plugins with our Plugin Security Scorecard. Somebody did that today with this plugin (which led to us noticing the security claim by the developer), the tool identified multiple issues with the plugin:

One of them involves the developer misusing a security function, which disputes the claim they follow security standards. Specifically, they are using the PHP filter_input() security function without specifying a filter, so it doesn’t provide any security. Looking at the code in question, there isn’t a vulnerability, as the misused function isn’t actually needed:

149	$isUsingCloudflare = !empty(filter_input(INPUT_SERVER, 'CF-Connecting-IP'));

Another identified issue involves usage of a WordPress function, maybe_unserialize(), known to be insecure, where the response from WordPress to securing it has been to suggest that plugins don’t use the function instead of fixing it. That doesn’t seem a like a good response, but using it in spite of that in the plugin doesn’t seem to be in line with following security or coding standards.

As an automated tool, the Plugin Security Scorecard is limited in what it can check for, but considering the issues it identified with the plugin’s code and that the developer isn’t providing the results of a security review of the plugin, it wouldn’t be surprising that there are more issues. And there are. One example highlights that the plugin is missing some basic security, which gets close to a serious security vulnerability.

In the file /admin/settings/functions/actions.php, the function ulf_import_ajax() is made accessible to anyone logged in to WordPress through its AJAX functionality:

123	add_action( 'wp_ajax_ulf-import', 'ulf_import_ajax' );

The code in the function is missing a basic security check:

  function ulf_import_ajax() {
 
    $nonce  = ( ! empty( $_POST[ 'nonce' ] ) ) ? sanitize_text_field( wp_unslash( $_POST[ 'nonce' ] ) ) : '';
    $unique = ( ! empty( $_POST[ 'unique' ] ) ) ? sanitize_text_field( wp_unslash( $_POST[ 'unique' ] ) ) : '';
    $data   = ( ! empty( $_POST[ 'data' ] ) ) ? wp_kses_post_deep( json_decode( wp_unslash( trim( $_POST[ 'data' ] ) ), true ) ) : array();
 
    if ( ! wp_verify_nonce( $nonce, 'ulf_backup_nonce' ) ) {
      wp_send_json_error( array( 'error' => esc_html__( 'Error: Invalid nonce verification.', 'ulf' ) ) );
    }
 
    if ( empty( $unique ) ) {
      wp_send_json_error( array( 'error' => esc_html__( 'Error: Invalid key.', 'ulf' ) ) );
    }
 
    if ( empty( $data ) || ! is_array( $data ) ) {
      wp_send_json_error( array( 'error' => esc_html__( 'Error: The response is not a valid JSON response.', 'ulf' ) ) );
    }
 
    // Success
    update_option( $unique, $data );
 
    wp_send_json_success();
 
  }

That missing security check being a capability check to limit what WordPress users can access the function. The code allows anyone who has access to a nonce, which is intended to prevent an attacker causing someone else to take an action, to update arbitrary WordPress options (settings). There is almost no situation where a plugin should have code allowing to update arbitrary settings, as that could allow an attacker to take control of a website. Instead, the developer should only allow certain options to be updated.

So who has access to the nonce? As far as we can tell, no one. As the code that generates that doesn’t appear to be used in the plugin. It looks to be connected to the paid “Pro” version of the plugin. So the insecure code really shouldn’t be in the plugin.

If an attacker logged in to WordPress could find another security issue that allows them to generate the needed nonce, they could, among other things, takeover the website.

Properly Assessing WordPress Plugins’ Security

The best way to assess the security of a WordPress plugin is a security review. Well, assuming the entity doing the review is really doing a security review, which isn’t always the case. If a developer is telling you their plugin is secure, they should be able to provide the results from a recent review to support that.

If a security review hasn’t been done, then our Plugin Security Scorecard can provide a much more limited assessment of the plugin’s security.

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.

26 Mar 2025

ShortPixel Not Honest About Security Fix in Enable Media Replace

Yesterday, a new version of the WordPress plugin Enable Media Replace was released. The changelog for the new version was “Fix: A potential “Reflected Cross-Site Scripting” vulnerability has been patched, responsibly disclosed by the PatchStack team.” The developers claim that a “potential” vulnerability had been fixed turned out to not be true. As there was an actual vulnerability. We also found the code in the plugin still isn’t properly secured and we have notified the developer of that.

…

[Read more]

25 Mar 2025

Vulnerability Disclosure Programs and Bug Bounties Are Being Used for the Wrong Thing, Leading to Poor Security Results

Last month DEF CON and the Cyber Policy Initiative at the University of Chicago at released the inaugural Hackers’ Almanack, which “curate[ed] the top technical discoveries from DEF CON that have significant potential impact on public policy.” One section written by Sven Cattell put forward a view of the how vulnerability disclosure programs (or more accurately described as vulnerability reporting programs) and bug bounties should be used that runs counter to how WordPress security providers and others usually present them:

The evaluations used in AI and the unit tests and integration tests deployed in traditional software probe for known problems. Red teaming, on the other hand, looks for unknown problems. As AI pushes us into this new frontier of technology, these unknown unknowns are often the most elusive yet critical vulnerabilities to uncover. In traditional software we deal with these with disclosure programs and bug bounties. [Read more]

6 Mar 2025

CVE Rule Allows MITRE to Hide When They Are Failing to Provide Timely Information on Vulnerabilities

The CVE system is treated as a reliable source of information on vulnerabilities, both in WordPress plugins, but also more broadly. It isn’t. It also is failing with a more basic element, actually having the records for claimed vulnerabilities. On Friday of last week, a source of security exploit attempt data we recently started monitoring was showing that a vulnerability identified as CVE-2024-48248 was receiving exploit attempts. What was odd about that is the CVE entry for that ID was empty. It looked like this at the time:

[Read more]

4 Mar 2025

CleanTalk Claims to Vet WordPress Plugins for Insecure Dependencies While Their Security Plugin Contains Known Vulnerable Library

Last week we posted about the three most popular file manager plugins containing a vulnerable version of the jQuery UI library. The inclusion of the vulnerable version of that library was detected by our Plugin Security Scorecard. None of those plugins have been updated to address that yet, despite us notifying the developers a week ago. Over the weekend, another plugin was checked through the tool and identified to contain a vulnerable version of that. Incredibly, it is a security plugin, Security & Malware scan by CleanTalk:

[Read more]

3 Mar 2025

Plugin Security Scorecard February Results

February was the seventh full month our Plugin Security Scorecard was available. A fair amount of plugins were checked. A total of 86 plugins were checked last month. With 4 of those plugins being security plugins.

The overall results were not great. No plugins got an an A+, A or B+. Those three grades require the developer is taking proactive measures with security, so most plugin developers are not taking measures to provide the best security. 19 of the plugins did get a B, which requires that they are avoiding unnecessary security issues. [Read more]

28 Feb 2025

Persistent Cross-Site Scripting (XSS) Vulnerability in Traffic Manager

Our Plugin Vulnerabilities Firewall blocked an attempt to exploit a vulnerability we traced back to the plugin Traffic Manager. The plugin was closed on the WordPress Plugin Directory in September 2022 for a claimed security issue. No details were provided. Based on the timing of the closure and public claims about vulnerabilities in the plugin, that would appear to be related to a different security vulnerability than the hacker was trying to exploit. This security issue they were trying to exploit is a persistent cross-site scripting (XSS) vulnerability.

The details provided with the block show that an AJAX request was made with the action used UserWebStat. And the value of a POST input “page” sent with the request was a script tag. Traffic Manager makes the function UserWebStat() in the file /traffic-manager.php accessible through an AJAX request with that action for those logged in to WordPress as well those not logged in: [Read more]

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]