29 Jun

What Happened With WordPress Plugin Vulnerabilities in May 2018

If you want the best information and therefore best protection against vulnerabilities in WordPress plugins we provide you that through our service.

Here is what we did to keep those are already using our service secure from WordPress plugin vulnerabilities during May (and what you have been missing out on if you haven’t signed up yet):

Plugin Vulnerabilities We Discovered and Publicly Disclosed This Month

We don’t just collect data on vulnerabilities in plugins that others have discovered, we also discover vulnerabilities through proactive monitoring of changes made to plugins, monitoring hackers’ activity, reviewing other vulnerabilities, and by doing additional checking on the security of plugins.

The most concerning vulnerability is an arbitrary file upload vulnerability, which is type that is normally highly likely to be exploited, though this one is only exploitable if an admin page has been visited at some point prior to the exploitation attempt.

Plugin Vulnerabilities We Helped Get Fixed This Month

Letting you know that you are using a vulnerable version of plugin is useful, but it is much more useful if you can fully protect yourself by simple updating to a new version. So we work with plugin developers to make sure that vulnerabilities get fixed.

This month we help to get plugins with 155,300 active installations, according to wordpress.org, fixed.

Vulnerabilities Added This Month That Are In The Current Version of the Plugins

Keeping your plugins up to date isn’t enough to keep you secure as these vulnerabilities in the current versions of plugins show:

Additional Vulnerabilities Added This Month

As usual, there were plenty of other vulnerabilities that we added to our data during the month.

03 May

We Wouldn’t Call WP Engine A Good Web Host for Providing Inaccurate Data on WordPress Plugin Vulnerabilities to Their Customers

When it comes to getting information on the security issues in WordPress plugins, developers of plugins are not always the best source. That is the case with a persistent cross-site scripting (XSS) vulnerability discovered by Federico Scalco that was in the plugin Caldera Forms. While that was claimed by the discoverer of the vulnerability, the developer of the plugin, and all of the other data sources of vulnerabilities in WordPress plugins we are aware of, to have been fixed in version 1.6.0 of the plugin, it actually wasn’t, as testing out the claimed vulnerability would have show any of them (the ease of testing that would will be something we will go into in another post). If you were using our service you would have been correctly notified that it hadn’t been fixed.

That has now been fixed in version Here what the developer wrote about that:

This release is an additional fix for CVE-2018-7747 . I was alerted earlier today that there was one remaining problem that did not get fixed. The security issue that we disclosed two weeks ago is called a stored XSS vulnerability. In simpler terms that means that there was a way to use Caldera Forms to store some JavaScript that could be triggered to run later.

In Caldera Forms 1.6.0 I used a function that removes all JavaScript on the output that was previously exploitable. That prevented the stored JavaScript from running. Since exploiting a stored XSS vulnerabilities is a two step processes — store and then retrieve later — this update prevents the issue from being exploited in the future.

Caldera Forms adds the same protection in one more location and prevents the behaviour that was shown to me today.

While we are not mentioned there for some reason, we were the ones that notified the developer of it not being fixed. The reality of the situation is that 1.6.0 had not removed “all JavaScript on the output that was previously exploitable” and the location which was claimed to be shown to them was part of the original advisory on the issue.

While we are not mentioned in that, they did link to one of the data sources, the WPScan Vulnerability Database, that falsely claimed that the vulnerability had been fixed before. That isn’t the only time that the developer of that plugin has recently promoted that data source, despite the developer now knowing that they provide inaccurate data.

The other example we ran across popped up in our monitoring of the wordpress.org Support Forum to keep track of vulnerabilities in WordPress plugins. In response to someone asking about a message from the WPScan Vulnerability Database about the vulnerability the developer wrote this:

Yes, there are security fixes in 1.6.0. I worked with the developer who found and responsibilities disclosed the issues. A part of that process is registering it with the database. That documents the issue.

More importantly, it triggers alerts that plugins need to be updated on good hosts. I got a notice from WPEngine about my own site. That’s the best system available to us for getting the word out about vuldrabilites that are not severe.

We don’t think a good web host would be spreading WPScan’s inaccurate data without at least having a disclaimer that the data has serious quality issues, which might have been a reminder to the developer that they shouldn’t be promoting it. By promoting data sources that are not responsible with their data, developers are actually hurting users of their plugins, since if we didn’t exist then the vulnerability likely would have remained in the plugin for the foreseeable future. If more people knew the truth about what different data sources provided it would likely mean more customers for our service, which would mean we could be doing even more to improve the security of WordPress plugins (and therefore WordPress in general), which is already probably more than every other security company out there.

Something else we noticed that seems worth noting it terms of improving the security of plugins was something mentioned in the post announcing the release of version 1.6.0 of the plugin:

In order to ensure that this fix does prevent these potential XSS vulnerabilities, and also that we do not re-introduce the vulnerability, we have created new automated tests. These tests, which are in a private git repository, will be run on future releases and we will add additional security checks in the future.

Clearly those automated tests didn’t actually accomplish that. Just in general, our experience is that automated testing is useful as additional tool for knowledgeable professionals when checking over the security of a WordPress plugin or other software, but they have some serious limitations and their abilities are often overstated.

07 Oct

Vulnerability Details: Flash Cross-Site Scripting (XSS) Vulnerability in Caldera Forms

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

Recently the web scanner service Detectify has been vaguely disclosing minor vulnerabilities in a number of WordPress plugins. It seems ...

Our Vulnerability Details posts provide the details of vulnerabilities we didn't discover and access to them is limited to customers of our service due to other security companies trying to sponge off the work needed to create those instead of doing their own work.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, you can try the service for free for the first month (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a WordPress plugin security researcher please contact us to get free access to all of our Vulnerability Details posts.

31 Jul

Planet Zuda’s False Claim of a Cross-Site Request Forgery (CSRF) Vulnerability in Caldera Forms

If you have read either of our previous posts about the security company Planet Zuda you won’t be surprised to hear that they are selling a “fixed” version of another WordPress plugin where the vulnerability they claim to have fixed doesn’t exist. This time it is with the plugin Caldera Forms, which has 90,000+ active installs, and for which they want 29.99 for the “fixed” version.

In reading the first part of their post with the claim about this plugin it really seems that people behind this company are not all together with it, which makes deciphering what the vulnerability is supposed to be harder. Here is the main portion of the claim about the vulnerability:

It saddens us that the developer misunderstood the wp_create_nonce as a way to actually create a secure nonce. You can just maliciously remove this from the form creating  csrf where you can add new forms on a site you don’t own  . Unfortunately, the forms suffer from stored XSS, which means we can put in malicious code if an admin clicks on a link, looks at a picture that is malicious online, etc thus exploiting the CSRF issue.

The function wp_create_nonce() is in fact exactly the way to create a secure nonce in WordPress, so it seems like Planet Zuda doesn’t understand what they are talking about at all. Amazingly in the post they mention the following:

Our advisor told us that Caldera forms would be a great candidate for our Help A Code Author program, where we contact a developer who needs help and offer our services free of charge.

If you remove the nonce from a request then the other half of the cross-site request forgery (CSRF) protection should prevent the request from being successful. Planet Zuda’s post doesn’t even mention that part of the code, instead the next paragraph in the post is this:

Here is the code that is flawed that leads to the CSRF

Then it shows this image :

The post them moves on without showing the code that should be checking for a valid nonce.

When requesting to create a new form the function create_form() in the file /classes/admin.php is run. The first part of it checks for a valid nonce and here is how it looks in the current version of the pluign, (and how it has looked for some time):

public static function create_form(){
	$nonce_validated = false;
	if(  isset( $_POST[ 'nonce' ] ) &&  wp_verify_nonce( $_POST[ 'nonce'], 'cf_create_form' ) ){
		$nonce_validated = true;
	parse_str( $_POST['data'], $newform );
	if( ! $nonce_validated ){
		if( isset( $newform, $newform[ 'nonce' ] ) ) {
			if( wp_verify_nonce( $newform[ 'nonce' ], 'cf_create_form' ) ){
				$nonce_validated = true;
	if( ! $nonce_validated ){
		wp_send_json_error( );

The code uses wp_verify_nonce() correctly to check if a valid nonce is included with the request. Just to double check that we didn’t misread the code, we tried creating a new form using a request that include an invalid or no nonce and they both failed. So the plugins actual does include valid protection against CSRF.

What looks to have happen is that Planet Zuda confused an unneeded nonce generated in the line shown in code in the image show above, with the line where the actual nonce used when creating a new form is generated, which occurs on line 374 of the file /classes/admin.php in version

data-nonce=<?php echo wp_create_nonce( 'cf_create_form' ); ?>

Either proper testing and properly reviewing the code would have avoided improperly identifying that there was a vulnerability here.

Without the CSRF there isn’t a vulnerability here, as creating a new form is usually limited to Administrator level users who have normally the ability to use the equivalent of cross-site scripting (XSS) through the unfiltered_html capability. Though it looks like the form name doesn’t need to include HTML, so it would probably be best to sanitize the value. It would also be best to do a capabilities check along with checking for a valid nonce. (Update 8/1/2017: The developer pointed out to us that the capabilities check is already in place, it just occurs when before registering the AJAX function for creating a form.) We have contacted the developer to let them know of Planet’s Zuda claims and suggest those improvements to the plugin.

25 May

Protecting You Against Wordfence’s Bad Practices: Sensitive Data Exposure Vulnerability in Caldera Forms

Wordfence is putting WordPress website at risk by disclosing vulnerabilities in plugins with critical details needed to double check their work missing, in what appears to be an attempt to profit off of these vulnerabilities. We are releasing those details so that others can review the vulnerabilities to try to limit the damage Wordfence’s practice could cause.

Wordfence describes the vulnerability in Caldera Forms version as “This vulnerability allows an attacker to gain access to potentially sensitive data that has been captured by a Caldera Form.”

The relevant change in the next version was to restrict certain AJAX functions to Administrator level users in the file /classes/admin.php.

Code in

add_action("wp_ajax_toggle_form_state", array( $this, 'toggle_form_state') );
add_action("wp_ajax_browse_entries", array( $this, 'browse_entries') );		
add_action("wp_ajax_save_cf_setting", array( $this, 'save_cf_setting') );
add_action("wp_ajax_cf_dismiss_pointer", array( $this, 'update_pointer') );
add_action("wp_ajax_cf_bulk_action", array( $this, 'bulk_action') );

Code in

if( current_user_can( Caldera_Forms::get_manage_cap( 'admin' ) ) ) {
	add_action( "wp_ajax_toggle_form_state", array( $this, 'toggle_form_state' ) );
	add_action( "wp_ajax_browse_entries", array( $this, 'browse_entries' ) );
	add_action( "wp_ajax_save_cf_setting", array( $this, 'save_cf_setting' ) );
	add_action( "wp_ajax_cf_dismiss_pointer", array( $this, 'update_pointer' ) );
	add_action( "wp_ajax_cf_bulk_action", array( $this, 'bulk_action' ) );

Wordfence’s description notably doesn’t mention that the attacker needs to be logged in to WordPress to exploit this, which severely limits the severity of the vulnerability.

The plugin developer also added the following code to check nonce’s to the functions update_pointer(), save_cf_setting(), and browse_entries():


Proof of Concept

The following proof of concept will show the entries for a form.

Make sure you are logged in to WordPress, ideally as a subscriber since they have the least capabilities. Also, make sure to replace “[path to WordPress]” with the location of WordPress and “[form id]” with the ID of the gallery you want to view the entries for (the form id can be found on the form’s page on the frontend).

 <form action="http://[path to WordPress]/wp-admin/admin-ajax.php"; method="POST">
 <input type="hidden" name="action" value="browse_entries" />
 <input type="hidden" name="form" value="[form id]" />
 <input type="submit" value="Submit" />