It would be rather notable if the 200,000+ install WordPress plugin from the security provider Cloudflare contained a vulnerability. And that was just the claim made recently by a couple of WordPress security providers. Here was one of them, Patchstack, describing the claimed vulnerability:

An unknown person discovered and reported this Sensitive Data Exposure vulnerability in WordPress CloudFlare Plugin. This vulnerability has been fixed in version 4.12.3.

An unknown person? What sensitive data is exposed? There is a button you can click to show “technical details”, but it doesn’t show any information.

The changelog for the mentioned version, 4.12.3, doesn’t say that a vulnerability has been fixed, but does suggest a security improvement has been made:

Prevent usage of cloudflare_proxy action on /admin-ajax endpoint for non-Administrator users

Not all security improvements are fixing vulnerabilities, so was a vulnerability fixed?

Another provider, Wordfence, makes a claim that seems in line with the changelog, but different from what Patchstack said:

The Cloudflare plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the ‘initProxy’ function in versions up to and including 4.12.2. This makes it possible for authenticated attackers, with subscriber access and above, to send requests proxied through Cloudflare to arbitrary URLs.

That would be a vulnerability, though not a serious one. But is there a vulnerability?

Looking at the changes being made in the relevant version of the plugin didn’t make anything clear, other than it appears like Cloudflare’s plugin has overly complicated coding. So we took another approach. We started by looking for any AJAX accessible functions, as the changelog seemed to be referencing that. We found one, which is only accessible to those logged in to WordPress:

49

add_action('wp_ajax_cloudflare_proxy', array($cloudflareHooks, 'initProxy'));

That calls a function, initProxy(), which is the same name Wordfence mentioned. All that function does is call another function:

101
102
103

public function initProxy()
{
	$this->proxy->run();

That function, in turn, does the proxy request, but before it does that, it checks for a valid nonce:

54
55
56
57
58
59
60
61
62
63
64

public function run()
{
	header('Content-Type: application/json');
 
	$request = $this->createRequest();
 
	$response = null;
	$body = $request->getBody();
	$csrfToken = isset($body['cfCSRFToken']) ? $body['cfCSRFToken'] : null;
	if ($this->isCloudFlareCSRFTokenValid($request->getMethod(), $csrfToken)) {
		$response = $this->requestRouter->route($request);

Access to that nonce is limited to Administrators, as it is provided on a page only available to those with the manage_options capability:

85

add_options_page(__('Cloudflare Configuration'), __('Cloudflare'), 'manage_options', 'cloudflare', array($this, 'cloudflareIndexPage'));

So only Administrators had access before.

The new version checks if a user is an Administrator before doing anything in the last function we showed:

56
57
58
59
60

public function run()
{
   if (!$this->wordpressAPI->isCurrentUserAdministrator()) {
		return;
	}

That is more secure, as WordPress’ documentation on nonces warns they “should never be relied on for authentication, authorization, or access control.” But there wasn’t a vulnerability, as access was already limited.

It is very common for WordPress plugin vulnerability data providers to not check over things and claim there have been vulnerabilities that haven’t existed. More problematically, they frequently tell people that unfixed vulnerabilities have been fixed.

CVSS Scores Don’t Agree

While the descriptions of the issue are different, there appears to be only one change made in the version mentioned, so it appears both of them are mentioning the same issue. Another thing they don’t agree on is the severity rating of the claimed vulnerability. They both are using the same system CVSS 3.1, but Patchstack claims it has a severity of 5.4:

And Wordfence, 6.4:

The scores should be the same, if it is the same issue. There isn’t much value in this scoring system if the scores are unreliable like that.

It also seems like those scores are rather high in comparison to what could be done with the issue, if it had existed.

Plugin Security Scorecard Grade for Patchstack

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