Recently the CEO of Wordfence, Mark Maunder, made this very strong claim about the quality of their (and to a lesser degree, competitor’s) data on vulnerabilities in WordPress plugins:

Our data is impeccable. Our competitors do a pretty darn good job too.

Reality continues to dispute that.

Recently a competitor, Patchstack, vaguely claimed that the plugin Auto Affiliate Links contained a cross-site request forgery (CSRF) vulnerability. We do mean vaguely, as they wrote this as the description of the issue:

This could allow a malicious actor to force higher privileged users to execute unwanted actions under their current authentication.

That describes what CSRF is generally,  but tells you nothing about the specific issue.

There is no indication that Patchstack tried to notify the developer of the issue before disclosing it. When a user brought that up with the developer, they responded that the issue had already been addressed:

Thank you for reporting this.

This issue was fixed in version 6.4.1, you can see the update in the readme.txt file.

It seems that the report was not updated on patchstack. I will contact them so they can mark it as resolved.

The changelog for the referenced version didn’t seem to match up, as it suggested that a different type of issue was addressed, “Sanitized exclude post by date field”. Looking at the change made in that version confirmed that the change made was related to cross-site scripting (XSS), not CSRF.

That was the second recent instance we saw a developer responding to a vague claim of CSRF as if it were referring to XSS. As with that previous instance, it wasn’t hard to find the plugin currently contained CSRF issues. As we did with the other plugin, we privately contacted the developer with information on what we found, with links to WordPress’s relevant documentation for dealing with this, and offered to help them address this.

While we haven’t heard back from the developer, they subsequently made a change that seems in line with reading our message, though not closely.

Part of what we wrote to them is this:

As an example of that, on the admin page Exclude Posts/Pages from Auto Affiliate Links, all the actions that can be taken from there, including excluding a post, don’t have a nonce check. The lack of that allows CSRF. The same is true for actions taken from some other admin pages at least.

The changelog for the version released after that reads “Added security nonces in exclude post page”. That references the same admin page we contacted them mentioning as an example of the issue. The keyword there is example. The issue is wider than that. Checking the changes made and the admin pages of the plugin, we found that the developer failed to address this for other pages.

As an example of that, the menu item after Exclude Posts/Pages from Auto Affiliate Links is for the page Exclude Categories and Tags. When clicking the first button on that page, Exclude Category, the request doesn’t include a nonce, which is required as part of preventing CSRF. As the action works despite the missing nonce, unsurprisingly, the code that interacts with, which is in the file /aal_excludecats.php, doesn’t contain a nonce check:

4
5
6
7
8
9

add_action('admin_init', 'aal_exclude_cats_actions');
 
	function aal_exclude_cats_actions() {
		if ( !current_user_can("publish_pages") ) return;
 
		aal_exclude_terms_actions('category','aal_excludecats', 'aal_add_exclude_cat');

19
20
21
22
23
24
25
26
27
28
29
30

 function aal_exclude_terms_actions($taxon, $toption, $tpost) {
	global $wpdb;
 
		if(isset($_POST['aal_add_exclude_'. $taxon .'_check'])) if($_POST['aal_add_exclude_'. $taxon .'_check']=='ok') {
 
 
			$word = filter_input(INPUT_POST, $tpost, FILTER_SANITIZE_SPECIAL_CHARS); // $_POST['id'];
 
 
			if(get_option($toption)) {
				$old = get_option($toption); 
				update_option($toption,$old . ',' . $word);

So the CSRF issue still exists in the plugin. Despite that, Patchstack subsequently claimed the vulnerability had been fixed.

Wordfence later copied that inaccurate claim. They are now claiming that the issue has been fixed and was done so in version 6.4.2.5. That would be the version that we already mentioned fixed some of the issue, but not all of it.

Plugin Security Scorecard Grade for Patchstack

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