31 Mar

Information Disclosure Vulnerability in Easy Digital Downloads

One of the features of our service is that our customers get to suggest and vote for plugins to get a security review done by us. Last month we did a review of the plugin Easy Digital Downloads and one of the issues we found through that was an information disclosure vulnerability.

The function edd_ajax_get_download_title in the file /includes/ajax-functions.php is accessible via AJAX by those logged in and out, despite stating that it is “used only in WordPress Admin”. The function is intended to return the title of the plugin’s downloads, but as can be seen below it lacks any restriction as to what it will return the tile of:

function edd_ajax_get_download_title() {
	if ( isset( $_POST['download_id'] ) ) {
		$title = get_the_title( $_POST['download_id'] );
		if ( $title ) {
			echo $title;
		} else {
			echo 'fail';

Since the function will return the title of any post (not just downloads), there is the possibility that the title of unpublished posts, private posts, or other private content stored in a post could be exposed through that.

It looks like that function isn’t actually used anymore, at least we couldn’t find where it was used in the plugin.

We notified the developer of the issue on February 27 and they responded, but the issue has not been resolved as of our posting this.

Proof of Concept

The following proof of concept will return the title of the post specified.

Make sure to replace “[path to WordPress]” with the location of WordPress and “[post ID]” with the ID of the post.

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


  • February 27, 2017 – Developer notified.
  • February 27, 2017 – Developer responds.
19 Jan

Vulnerability Details: Information Disclosure Vulnerability in W3 Total Cache

To provide our customers with the best information possible on vulnerabilities that have been in WordPress plugins they use, we create posts, like this one, which include the details of vulnerabilities for which the discoverer has not released a report with those details already. That allows our customers to better understand how the vulnerability had or could have impacted their website.

For existing customers, please log in to your account to view the details of this vulnerability.

If you are not currently a customer, when you sign up now 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 security researcher please contact us to get free access to all of our Vulnerability Details posts.

02 Jan

Information Disclosure Vulnerability in Pike Firewall

In our testing of WordPress security plugins to see what, if any, protection they provide against the exploitation of actual vulnerabilities in other plugins the results haven’t been good so far. Most of the plugins tested haven’t provided any protection against those vulnerabilities. That hasn’t really surprised us, as much of what these plugins do doesn’t have any impact on what hackers actually try to do. One example is that many of these plugins check if you have change the database prefix to something other than the default “wp_”, but knowing the database prefix is rarely needed for vulnerabilities we see being exploited. If knowing the database prefix was a big deal then the vulnerability we recently found in a security plugin would be a big deal, as the vulnerability exposes that.

While doing a few quick security checks over the plugin Pike Firewall we noticed that it has the capability to log login attempts. We and others have found that capability in plugins has introduced security vulnerabilities into plugins due to improper handling of user input that comes through that. One of things that has been an issue with other plugins is that malicious JavaScript code placed in the HTTP header field X-Forwarded-For will get displayed on the plugin’s pages unsanitized or unescaped leading to cross-site scripting (XSS). In this case we found it caused another issue when tried logging in with it set to malicious code we got this error:

WordPress database error: []
SHOW FULL COLUMNS FROM `wp_pike_firewall_login`

The database prefix is being shown in that error message.

In looking at the underling code the cause of this is (in the file /pikefirewall.php):

if ( !$wpdb->insert($pike_tables['login'], array('username' => $username, 'user_address' =>; $pike_ip, 'user_agent' => $pike_agent, 'type' => $type, 'success' =&gt; $success), array('%s', '%s', '%s'))) {

You can see that error reporting is enabled and if there is an error it gets printed, which shouldn’t be happening in a non-development environment since as our example shows it is disclosing non-public information.

We contacted the developer about the issue on December 19, but we have not heard back from them and the vulnerability has not been fixed.

Proof of Concept

With login attempt logging turned on, set the X-Forwarded-For HTTP header to


and attempt to log in to WordPress (the username/password doesn’t matter).


  • December 19, 2016 – Developer notified.
11 May

Information Disclosure Vulnerability in Yoast SEO

Recently the security company Wordfence released an advisory for the Yoast SEO plugin for what seems to be a rather minor issue. Logged in users could access several functions of Yoast SEO that they were not normally intended to have access to, including exporting the plugin’s settings. While reviewing that to include in to our service’s data we noticed that the related to this there was also a problem with cross-site request forgery (CSRF) protection in the export function of the plugin.

The fact the plugin now restricts the export function to Administrator level users (by restricting it to user who can manage_options) and there was supposed to be CSRF protection for it would indicate the result of that export should not be available to public. Though in normal circumstances it doesn’t look like sensitive data so the publics access to it seems to not to be a major issue at this point, but that could change, so making sure it is not easily accessible to the public seems like a good idea. Currently that isn’t the case.

When doing an export of the settings this month the file saved at:


Last month it was saved at:


Not only are files in that location normally accessible by the public, it would very easy for someone to request all of the possible file locations by making requests for all of the possible year and month combinations.

We notified the developer about this issue along side the CSRF issue on Friday, yesterday the indicated that it would be a month before they fixed the CSRF issue, but made no mention of this issue, so who knows if they are interested in fixing it. That would be fairly easy to do by simply adding a unique value to the name of the file.


  • 5/6/2016 – Developer notified.
  • 5/10/2016 – Response from developer with no reply on this issue.
  • 6/21/2016 – Version 3.3.2 released, which fixes vulnerability.
04 Mar

Information Disclosure Vulnerability in WP Ultimate Exporter

There are certain kind of plugins you would hope that anyone developing one would be very careful when doing so, one of those being a plugin that allows you to export non-public data from WordPress. That unfortunately isn’t always case, as the following vulnerability shows (and another vulnerability we will release the details of on a later date).

WP Ultimate Exporter is a plugin that allows you to export posts, pages, and custom posts as CSV files. While reviewing a report of a SQL injection vulnerability in the plugin we noticed that there was another connected issue, the plugin allows anyone to perform an export operation and get the resulting file. That clearly is not the intent as the plugin’s page in the WordPress admin area is only available to users with the Admin role. Unfortunately none of the code run when the actual request for an export is made actually checks to make sure that the request comes from an admin user.

For a lot of sites this probably wouldn’t be a big deal since all of their pages and post are public. But for those were it isn’t the case this would be a big issue. The plugin even allows you select the type of content you want to export, so for example you could just export the password protected posts:


Proof Of Concept

The following proof of concept page will cause all posts to be exported.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<form method="post" enctype="multipart/form-data" action="http://[path to WordPress]/wp-admin/admin.php?page=wp_ultimate_exporter&step=exportposttype">
 <input type="hidden" value="post" name="export_type_name">
 <input type="hidden" name="post_withdelimiter" value="," >
 <input type="submit" name="proceed_to_exclusion" value="Export">


  • 2/29/2016 – Notified Developer
  • 3/4/2016 – Notified WordPress.org Plugin Directory
  • 3/7/2016 – Plugin Removed from WordPress.org Plugin Directory