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.
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:
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 wordpress.org plugin directory.
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.