Late last week, Wordfence created a mess by claiming there was an unfixed vulnerability in WooCommerce. What that situation showed is they are not doing the work that people clearly believe they are doing. That includes not checking if vulnerabilities have actually been fixed or if they even existed, before widely making claims about supposed vulnerabilities. We will get in to more detail about that in a few moments, but first we will take a look at a couple of other recent examples, which show that wasn’t a one-off fluke.

We should note at the outset that the CEO of Wordfence, Mark Maunder, recently claimed their “data is impeccable” when we brought up the well-known problems with it.

Unfixed Vulnerability

Last week, a new version of the 300,000+ install WordPress plugin PDF Invoices & Packing Slips for WooCommerce was released. The changelog for that suggested that a security issue had been addressed as one of the entries reads “Fix: potential SQL injection bug in Number Tools.” Three days later, Wordfence claimed that this had fixed a vulnerability in the plugin:

The PDF Invoices & Packing Slips for WooCommerce plugin for WordPress is vulnerable to SQL Injection via the get_numbers() function in all versions up to, and including, 3.7.5 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with shop manager-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

Other than a link to the changelog and the changes made, they didn’t provide any more information. So their customers can’t double check on their claims there. That is a problem, because the vulnerability they mentioned does exist, but it wasn’t fixed. There is a related second vulnerability they also missed.

That shouldn’t have happened if they were doing the work they should do. We are not saying that on a hypothetical basis. As at least one of the customers of our main service was using the plugin, we reviewed the changes made. As we warned our customers a day before Wordfence claimed the vulnerability had been fixed, the vulnerability hadn’t been fixed. The developer had made changes to try to address a SQL injection vulnerability, but it was incomplete. We used what went wrong as an example for a post yesterday. We also contacted the developer of the plugin about that and they are working on a fix.

Wrong Versions

While the CEO of Wordfence claims their data is impeccable, they claimed the plugin “is vulnerable to SQL Injection via the get_numbers() function in all versions up to, and including, 3.7.5”. That can’t be right, as the referenced function was only added in version 3.7.2.

Copying Patchstack’s Inaccurate Data

With the previously mentioned vulnerability, Wordfence was apparently relying on the changelog of the plugin as their source for listing a vulnerability. With a vulnerability in the Brave Conversion Engine, they were instead relying on information coming from Patchstack.

We previously quoted the CEO of Wordfence claiming their data is impeccable. Right after saying that, he wrote, “Our competitors do a pretty darn good job too.” There is a big contradiction there. If Wordfence is copying data from competitors and the competitors data is less than impeccable, it would follow that so is Wordfence’s. So he isn’t telling the truth even between those two sentences.

On November 20, we warned our customers that the Brave Conversion Engine had tried to fix a vulnerability, but had failed to do so. We looked into that because at least one of our customers was using the plugin and we saw that one of the changelog entries for the latest version, 0.6.3, said “Fixed: XSS vulnarability in Text Element.” We contacted the developer about the incomplete fix and they made a second attempt in version 0.6.4, with the changelog entry reading, “Fixed: XSS vulnerability in List Element.” The vulnerability still hasn’t been fully resolved two months later, though.

On December 27, Patchstack apparently vaguely claimed this had been fixed in version 0.6.3. Patchstack didn’t provide even really basic information, so we are guessing that they are referring to the same issue since it was attempted to be fixed in that version and their vague claim matches with that vulnerability. A further issue here is that Patchstack was allowed to issue a CVE ID for this, despite not providing the information needed to re-create this, as is required for CVE Records.

Based on Patchstack’s vague claim, Wordfence made a similar claim:

The Brave – Create Popup, Optins, Lead Generation, Survey, Sticky Elements & Interactive Content plugin for WordPress is vulnerable to Stored Cross-Site Scripting via admin settings in all versions up to, and including, 0.6.2 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.

If they had simply checked the changelog, they should have realized something was wrong here, but they didn’t.

In addition to getting it wrong that this has been fixed, the vulnerability is accessible to users lower than Administrators, which is contrary to what Wordfence claimed.

A Potential Vulnerability in WooCommerce Claimed to be a Vulnerability

One of the changelog entries for version 8.5.0 of the WooCommerce plugin is “Fix – Remove the potential for a Reflected XSS attack in relation to a dismissable notice in the edit comments screen. #42728” This led to Wordfence claiming that a reflected cross-site scripting (XSS) vulnerability was fixed in that version, despite the changelog saying “potential for a Reflected XSS”.

On Tuesday, WooCommerce 8.5.0 was released and quickly pulled back to an unrelated issue.

On Friday, Wordfence started claiming that earlier versions of WooCommerce contained the vulnerability.

This led to panicked users of the plugin posting on the WooCommerce support forum and a series of inaccurate replies by Wordfence.

Here was one of their employees’ first explanation of the situation:

It looks like this was in fact a miscommunication – Version 8.5.0 containing a patch was not only pushed to github but also to the WordPress SVN, and an entry mentioning the XSS was noted in the 8.5.0 changelog which cued us into the vulnerability in the first place.

Our standard process is not to disclose vulnerabilities until they’re patched – but in this case it looks like 8.5.0 was rolled back. The bad news is that the patch is publicly available meaning that it’s now trivial for any attackers to find the same vulnerability – it would be public at this point even if we didn’t have our vulnerability entry.

The good news is that it’s Reflected Cross-Site Scripting, which requires user interaction, and all Wordfence users, including Free Wordfence users, as well as users of almost all other WAF products from other providers, should be protected from this type of issue.

While Cross-Site Scripting vulnerabilities can have Critical impacts, the threat posed by this particular vulnerability is fairly low – don’t click on any suspicious links, and make sure you have a firewall like the Wordfence Firewall installed, and you’ll be fine. We’re going to mark it unpatched for the time being and keep an eye out for when a full patch is released.

Here is their follow up:

An update – after further review, the vulnerability was actually patched in version 8.4.0, meaning the current version is not vulnerable. We’ve updated our vulnerability record to reflect this and will be revisiting our processes to ensure this type of issue doesn’t happen again.

Those are obviously contradictory. They first claimed the patch was in version 8.5.0 and then it was in 8.4.0. What is going on there?

The code change they are referencing was actually made in version 8.4.0, which was released in December. The changelog entry was included in 8.5.0. They clearly didn’t test out and confirm there was a vulnerability in 8.4.0, as the relevant code wasn’t in that version.

We also noticed the changelog and actually checked on this before them and noticed the code wasn’t in 8.4.0, so things could be done right, but Wordfence chooses not to do them right and then have their CEO lie about that.

The head of Patchstack, Oliver Sild, was claiming in one of the post on the support forum that they had the “correct details” and that “this vulnerability was already fixed in 8.4.0 (about 5 weeks ago).” Patchstack didn’t actually provide any details, they simply linked to WooCommerce’s information that claimed this was a potential issue.

The issue was in the file /src/Internal/Admin/ProductReviews/ReviewsCommentsOverrides.php and involved this code:

76
77
78
79
80
81
82
83
84

$dismiss_url = wp_nonce_url(
	add_query_arg(
		[
			'wc-hide-notice' => urlencode( static::REVIEWS_MOVED_NOTICE_ID ),
		]
	),
	'woocommerce_hide_notices_nonce',
	'_wc_notice_nonce'
);

93

<button type="button" class="notice-dismiss" onclick="window.location = '<?php echo esc_url( $dismiss_url ); ?>';"><span class="screen-reader-text"><?php esc_html_e( 'Dismiss this notice.', 'woocommerce' ); ?></span></button>

What is at issue is that user input from the variable $dismiss_url is output with escaping for a URL with esc_url(), but not escaped to be in JavaScript code. The original change made to address it was to add a second line of escaping for JavaScript, using esc_js():

93

<button type="button" class="notice-dismiss" onclick="window.location = '<?php echo esc_js( esc_url( $dismiss_url ) ); ?>';"><span class="screen-reader-text"><?php esc_html_e( 'Dismiss this notice.', 'woocommerce' ); ?></span></button>

In our testing ,we didn’t find a way that previous situation was actually exploitable. So as far as we can tell, there wasn’t actually a vulnerability here, but a potential for a vulnerability as WooCommerce said. Patchstack, and anyone else as far as we are aware, hasn’t actually shown that there is a vulnerability and Wordfence clearly didn’t actually confirm that, considering they didn’t actually even know if the code was in the plugin.

Plugin Security Scorecard Grade for Patchstack

See issues causing the plugin to get less than A+ grade

Plugin Security Scorecard Grade for WooCommerce

See issues causing the plugin to get less than A+ grade