04 Apr

When Full Disclosure of a Claimed WordPress Plugin Vulnerability Leads To A Bigger Problem

When it comes to disclosing security vulnerabilities, a major issue is when the vulnerability should be disclosed. On one side is full disclosure, which involves disclosing it as soon as possible, including before the vulnerability has been fixed. On the other side is responsible disclosure, which involves disclosing a vulnerability in a coordinated manner sometime after it has been fixed. Both have issues worth discussing, but in this post we will focus on one example of what can go wrong when a claimed vulnerability in a WordPress plugin is disclosed without giving the developer prior notification.

On March 28 a report claiming there was a cross-site scripting (XSS) vulnerability in the CloudFlare plugin was released. We say claimed because in normal circumstances this would not be a vulnerability. While the report describes the threat as:

An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and to launch other attacks.

What it doesn’t mention is the fact the attacker would have to be logged in as an admin level user to do what is describe. If an admin wants to do something malicious they would have normally have more effective options and would also normally have the ability to edit a plugin and therefore remove any restrictions on using cross-site scripting. The other relevant issue with calling this a vulnerability is that admin (and editors) are normally allowed to use the equivalent of cross-site scripting due to having the unfiltered_html capability. For those reasons we don’t include this type issue in our data.

While this isn’t something we would consider a vulnerability, it still would be best to make sure this type of issue does not occur.

Later on March 28 CloudFlare released a version of the plugin to fix what they saw as a “zero day vulnerability“. Since it wasn’t actually a vulnerability they wouldn’t have needed to rush out a fix, but if they had been notified ahead of the public disclosure they wouldn’t have needed to rush either.

While CloudFlare claims to be a web security provider, it is clear they don’t have much knowledge when it comes to handling of the security of a WordPress plugin at least. Instead of following the good advice provided in the WordPress documentation on properly handling user input they decided to fix the issue with the following code:

$_GET = array_map("cloudflare_filter_xss", $_GET); 
$_POST = array_map("cloudflare_filter_xss", $_POST); 
function cloudflare_filter_xss($input) { 
 return htmlentities($input, ENT_QUOTES | ENT_HTML5, "UTF-8"); 

That code ran all GET and POST variables through their cross-site scripting filtering function instead of just the variable used in their plugin, which altered many things it shouldn’t and lead to a variety of WordPress functionality being broken.

CloudFlare quickly put out another release that fixed most of the issue, though as of the current version,, the new code they replaced the code that had been added in with was still running several POST variables through their cross-site scripting filtering anytime they are submitted instead of just sanitizing those variables when they are clearly being submitted the plugin’s setting’s page:

$cfPostKeys = array("cloudflare_zone_name", "cf_key", "cf_email", "dev_mode", "protocol_rewrite");

foreach($_POST as $key => $value) {
 if(in_array($key, $cfPostKeys)) {
 $_POST[$key] = cloudflare_filter_xss($_POST[$key]);

function cloudflare_filter_xss($input) {
 return htmlentities($input, ENT_QUOTES | ENT_HTML5, "UTF-8");

This situation does highlight another issue, the difficulty in notifying a developer of a WordPress plugin of a security issue. The address listed as the plugin’s homepage is now a 404 page and from CloudFlare’s homepage we couldn’t find a relevant contact page or address. If you run into a situation like this where you can’t find a way to directly contact the developer you can report the issue directly to Plugin Directory instead.

Leave a Reply

Your email address will not be published. Required fields are marked *