Stored XSS in 4 million eCommerce shops

WooCommerce is an eCommerce plugin for WordPress with over 4 million active installations. It's privilege design was flawed, which lead to attackers in control of a user account with Shop manager privileges on the target server being able to inject malicious JavaScript code into the index page of the target WordPress site. The next time an administrator visits the frontpage of the target store, the evil JavaScript code executes in his browser and compromises the store and all customer data.

Proof of concept video

Stored XSS in 4 million WordPress sites

Three plugins, Contact Forms by WP Forms (1 Million active installations), Google Analytics by Monster Insights (2 Million active installations) and WP Mail SMTP by WP Forms (1 Million active installations) all suffered from a critical Stored XSS vulnerability. This is because they all shared vulnerable code that is responsible for displaying notifications in the admin area of WordPress.

The vulnerabilities occurred because lower privileged users were able to create new notifications for other user accounts on the site and inject <script> tags into the rendered HTML markup of the notification. The malicious notifications are then displayed on the index site of the admin dashboard of WordPress. The next time an administrator logs into the admin dashboard, evil JavaScript code executes which compromises the entire server.

Responsible lines of code

Unsanitized post meta is embedded into HTML markup

 1 2 3 4 5 6 7 8 910111213141516171819202122

function display_notifications() {

    // get all posts with the post type amn_notification
    $plugin_notifications = get_posts(
    array(
        'post_type' => 'amn_notification'
    ));


    foreach ( $plugin_notifications as $notification ) {
        $dismissable = get_post_meta( $notification->ID, 'dismissable', true );
        $type        = get_post_meta( $notification->ID, 'type', true );

        $html = "<div class='notice-$type am-notification notice'>";
        $html .= $notification->post_content;
        $html .= "</div>";

        echo $html;

        }

}

Phar Deserialization to RCE in 4 million eCommerce sites

The popular eCommerce plugin WooCommerce suffered from a Phar Deserialization vulnerability that allows attackers in control of a user account with Shop manager privileges on the target website to execute arbitrary code remotely on the underlying server. We have written a blog post explaining Phar Deserializations, a new exploitation technique in PHP. You can read about it here. The vulnerability occurred in the CSV import functionality of WooCommerce.

$_POST['file'] is passed unsanitized to is_file()

Responsible lines of code

 1 2 3 4 5 6 7 8 910111213141516

public function do_ajax_product_import() {

    $file = wc_clean( wp_unslash( $_POST['file'] ) ); // PHPCS: input var ok.

    $importer = WC_Product_CSV_Importer_Controller::get_importer( $file, $params );
    $results = $importer->import();

}

public function import() {
    if ( ! is_file( $this->file ) ) {
        $this->add_error( __( 'The file does not exist, please try again.', 'woocommerce' ) );
        return;
    }

}

Stored XSS in 2 million WordPress sites

All in One SEO pack has over 2 million active installations and suffered from a Stored XSS vulnerability. The vulnerability can be exploited by attackers who gained control over a user account with at least Contributor privileges on the target WordPress site. An attacker is able to inject arbitrary JavaScript code into blog posts he creates and publishes. If an administrator opens a malicious blog post, evil JavaScript code executes which compromises the target server.

Unsanitized post meta values are embedded into HTML markup

Responsible lines of Code

 1 2 3 4 5 6 7 8 910111213141516171819

function get_option_html( $args ) {
    $options = $args['options'];
    $value = $args['value'];
    switch($options['type']) {

        case 'html':
            $buf .= $value;
            break;
        case 'date':
            wp_enqueue_script( 'jquery-ui-datepicker' );

    }

    return $buf;
}

$args = get_post_meta($post->ID, '_aioseop_opengraph');

echo get_option_html($args);

CSRF to RCE in 1 million WP sites

Redirection is one of the most popular WordPress plugins and has over 1 million active installations. It allows site owners to easily create redirections. For example, a site owner may use the plugin to redirect all users that visit the URL example.com/someurl to example.com/anotherurl. The plugin suffered from a critical CSRF vulnerability that allows remote attackers to create a shell.php on the target server and execute arbitrary code. The only requirement for successful exploitation is that an administrator of the target site visits a malicious website set up by the attacker. The victim does not have to click anything on the malicious website in order to trigger the exploit.

Our leading SAST solution RIPS was able to find the file creation vulnerabilty automatically within 2 minutes.

Proof of concept video

 1 2 3 4 5 6 7 8 910111213

add_action( 'wp_ajax_red_proxy', array( $this, 'red_proxy' ) );

// This ajax callback simulates calls to the REST API
function red_proxy() {
    if ( $this->user_has_access() && isset( $_GET['rest_path'] ) && substr( $_GET['rest_path'], 0, 15 ) === 'redirection/v1/' ) {
        $_SERVER['HTTP_CONTENT_TYPE'] = 'application/json; charset=utf-8';
        $_SERVER['CONTENT_TYPE'] = $_SERVER['HTTP_CONTENT_TYPE'];
        $server = rest_get_server();
        $server->serve_request( rtrim( '/' . $_GET['rest_path'], '/' ) );
        die();
    }
}
                        

Privilege Escalation in 4 million eCommerce sites

WooCommerce, the most popular eCommerce plattform on the internet with over 4 million active installations suffered from an arbitrary file deletion vulnerability that allowed attackers in control of a user account with Shop manager privileges on the target online shop to delete any file on the remote server. This allows an attacker to delete certain files containing security checks. Without these security checks in place, the evil shop manager can then take over any administrator account. Once access to the administrator account is gained, the attacker can execute arbitrary code on the target server, leading to a full compromise of the target store.

Our leading SAST solution RIPS was able to find the vulnerabilty automatically within 2 minutes.

Proof of Concept video:

The vulnerability was fixed in version 3.4.6.

Timeline

  Scan your code for vulnerabilities

Privilege escalation from Subscriber to Admin in 200.000 WordPress Sites

Toolset Types is a plugin that allows site owners to customize their sites functionality by adding new, custom post types and meta fields. It has over 200.000 active installations. Due to a misuse of the WordPress filter API, it was possible for attackers to escalate their privileges from any type of account on the website to administrator privileges with a single request. If the plugin was used in combination with a plugin such as WooCommerce or BuddyPress, unprivileged attackers are able to perform a full site takeover.

The following paragraphs will explain how returning the wrong value from a filter function can lead to severe security issues in WordPress.

  Scan your code for vulnerabilities

Responsible lines of code

 1 2 3 4 5 6 7 8 91011121314151617181920212223242526

function set_screen_options() {

    $user = wp_get_current_user();

    $option = $_POST['wp_screen_options']['option'];
    $value = $_POST['wp_screen_options']['value'];

    switch ( $option ) {

        case 'products_per_page':
        case 'posts_per_page':
        case 'users_per_page':
            $value = (int) $value;
            break;
        default:
                $value = apply_filters( 'set-screen-option', false, $option, $value );

                if ( false === $value )
                    return;
                break;
    }

    update_user_meta($user->ID, $option, $value);

}
                

The function set_screen_options() is a function that gets called when users update screen settings. Screen settings define for example how many posts a user wants to see on each page or how many search results he wants to see on a search result page. This information is stored in the database as user meta information. User meta information is updated with update_user_meta(). The function takes 3 parameters: The user ID of the user who's meta information should be updated, the key of the meta information (e.g. twitter_url, number_of_logins or posts_per_page). The third parameter is the new and desired value of the meta key.

The function works by taking two POST parameters: the meta key that should be updated and the value of it. This is a dangerous thing to do for the following reason: The user's role and privileges are also stored as user meta information. The user meta entry with the key wp_capabilities defines which capabilities the user has. In order to prevent users from simply setting $_POST['wp_screen_options']['option'], which is the meta key that will be updated, to wp_capabilities, and giving themselves admin permissions, a switch statement on the meta key (stored in $option) is put in place. The meta information will only be updated if the meta key matches one of the WordPress core screen options, such as posts_per_page. If it matches none of the core options, the default case is reached. Here, the function apply_filters() is called and the meta information will only be updated if the return value of that call is not false.

Filters in WordPress allow plugins to modify the behavior of WordPress. If a plugin developer wants to create new screen option, he adds a filter function to the set-screen-option filter. Plugins can add filter functions to a filter by using the add_filter($filter_name, $function_name);. The first argument to that function is the name of the filter, for example set-screen-option. The second parameter is the name of a function that should be called when the filter is applied via apply_filters().

The following is an example of the correct usage of the set-screen-options filter. If the $option should be allowed, because the plugin wants to use it, it will return the new value. Otherwise, the filter function returns false, which tells the set_screen_options() function to return and not update the user meta.

12345678

function set_screen_option( $status, $option, $value ) {

if ( 'types_field_control_fields_per_page' == $option )
    return $value;
else
    return false;
}
                

If no filter function is added to the set-screen-option filter, false will be returned, thus set_screen_options() will return and the call to update_user_meta() is never reached. This means a plugin that adds a filter to set-screen-option and returns the value unmodified has to be installed in order for this to be exploitable. An example for such a plugin is Toolset Types.

The following code snippets shows the vulnerable filter added by Toolset Types

123456

add_filter('set-screen-option', 'wpcf_table_set_option', 10, 3);
function wpcf_table_set_option($status, $option, $value)
{
    return $value;
}
                

The filter is vulnerable because it simply returns the value unmodified. This allows an attacker to set the target user meta key to wp_capabalities and give himself administrator privileges.

The vulnerability was fixed in version 2.3.4

Timeline

XSS to Object Injection in 1 million sites

Smush Image Compression and Optimization is a plugin for WordPress that compresses uploaded images. It suffers from a Phar deserialization vulnerability that can be exploited by attackers who have control over a user account with at least Author privileges on the target site. Such access could be gained via means of XSS vulnerabilities. RIPS has detected a reflected XSS vulnerability in the same version of WP Smush. The plugin is used in over more than 1 million WordPress sites.
When the two vulnerabilities are combined, an attacker can trick a user of a target WordPress site into clicking a malicious link, which then executes evil JavaScript code that finally exploits the Phar Deserialization.

Our leading SAST solution RIPS was able to find the vulnerabilty automatically within 2 minutes.

Unsanitized post meta is passed to file_exists()

Responsible lines of code

 1 2 3 4 5 6 7 8 91011121314

// Get post meta to check for Upfront images
$upfront_images = get_post_meta( $attachment_id, 'upfront_used_image_sizes', true );


// Loop over all the images in upfront meta
foreach ( $upfront_images as $element_id => $image ) {
    if ( isset( $image['is_smushed'] ) && 1 == $image['is_smushed'] ) {
        continue;
    }
    // Get the image path and smush it
    if ( isset( $image['path'] ) && file_exists( $image['path'] ) ) {
        $res = $this->do_smushit( $image['path'] );

                

Reflected XSS in 1 million WordPress Sites

Contact Forms by WP Forms is a plugin that allows WordPress site owners to easily create contact forms for their site. It has over 1 million active installations. The commercial version of the plugin suffered from a reflected XSS vulnerability. If an attacker can lure a victim administrator to click on a malicious link, a full site takeover can be performed.

Our leading SAST solution RIPS was able to find the vulnerabilty automatically within 2 minutes.

$_GET['date'] is embedded into JavaScript code without sanitization

Responsible lines of code

 1 2 3 4 5 6 7 8 910111213141516

if ( ! empty( $_GET['date'] ) ) {
    $dates = explode( ' - ', $_GET['date'] );
    if ( is_array( $dates ) && count( $dates ) === 2 ) {
        $default_date = 'defaultDate: [ "' . $dates[0] . '", "' . $dates[1] . '" ],';
    }
}


$js_code = '<script>jQuery(".wpforms-filter-date-selector").flatpickr({';
$js_code .= 'altInput: true,';
$js_code .= 'altFormat: "M j, Y",';
$js_code .= 'dateFormat: "Y-m-d",';
$js_code .= 'defaultDate: ' . $default_date . "});";

echo $js_code;
                

Arbitrary File Read in 4 million eCommerce sites

WooCommerce, an eCommerce plugin for WordPress used by over 4 million stores on the web suffered from a vulnerability that allowed attackers to read arbitrary files on the target server, allowing them to compromise the database of the server and take over the target store.

Attackers who gained control over a user account with the Shop manager role on the target server can read arbitrary files on the target server, including the wp-config.php configuration file of WordPress. This file contains the database credentials of the target WordPress installation. Once an attacker gains control over the database, he can steal all data of the target shop and execute arbitrary code on the target server by inserting malicious serialized strings into the database.

Proof of concept video

Stored XSS in 5 million WordPress sites

Jetpack is the fourth most used plugin in the WordPress community and has over 5 million active installations. RIPS detected a Stored XSS vulnerability that affects a module available to premium and professional users of Jetpack. Attackers who gained control over an account on the target site with at least Contributor privileges were able to inject arbitrary JavaScript code into the HTML markup of a blog post. Once the administrator of the target site views the malicious blog post, evil JavaScript code is executed which compromises the target server.

Our leading SAST solution RIPS was able to find the vulnerabilty automatically within 2 minutes.

Unsanitized post meta is embedded into HTML

Responsible lines of Code

 1 2 3 4 5 6 7 8 91011121314151617

// Registers the spay_product shortcode (e.g. [spay_product id="1"])
// The function that will generate the HTML from the shortcode is the parse_shortcode function
add_shortcode('spay_product', 'parse_shortcode');

function parse_shortcode($attributes) {
    $id = $attributes['id'];

    $price = get_post_meta($id, 'spay_formatted_price');

    $html = "<div class='title'><p>{$title}</p></div>";
    $html .= "<div class='description'><p>${description}</p></div>";
    $html .= "<div class='price'><p>{$price}</p></div>";

    echo $html;

}
                

Reflected XSS in 1 million WordPress sites

Mailchimp is a popular service that companies can use to build email lists and launch fully automated email marketing campaigns. They also offer a a plugin called Mailchimp for WordPress which has over 1 million active installations. It suffered from a reflected Cross Site Scripting vulnerability. If an administrator of a target WordPress site running a vulnerable version of Mailchimp triggers the XSS payload, a full site takeover can be achieved.

Our leading SAST solution RIPS was able to find the vulnerabilty automatically within 2 minutes.

add_query_arg() returns user input without sanitization

Responsible lines of code

12

<a href="<?php echo add_query_arg( array( '_mc4wp_action' => 'empty_lists_cache' ) ); ?>" class="button button-primary">
                

Privilege escalation in 4 million eCommerce sites

WooCommerce is the most popular eCommerce plattform on the internet with over 4 million active installations. It suffered from a privilege escalation vulnerability that allows attackers who are in control over an account with Shop manager privileges on the target site to change the password and email of the admin account.
The vulnerability occurs because WooCommerce can be managed in two ways: Via the admin dashboard and a REST API. Shop managers are not able to update the user accounts of administrators in the admin dashboard because security checks are in place. However, these checks were not made in the REST API of WooCommerce.

Once an admin account of a WordPress site is compromised, a full site takeover and in most cases arbitrary remote code execution can be achieved.

Proof of concept video

Phar Deserialization in 700.000 sites

The WordPress security plugin All in One WP Security & Firewall is vulnerable to a Phar Deserialization. Although only administrators can trigger the vulnerability, the Phar deserialization might serve as a bypass for hardened WordPress installations. By default, administrators of a WordPress site can edit plugin files directly and download plugins from the WordPress plugin repository. If an attacker gains control over the admin account of the target site, he can abuse these features and write arbitrary PHP code to the server. It is recommended that administrators disable this functionality to ensure that even if their account gets compromised attackers can't just execute arbitrary PHP code on the server. The Object Injection resulting from the Phar Deserialization might allow attackers to bypass the hardening and still take over the site. Affected are over 700.00 sites.

Our leading SAST solution RIPS was able to find the vulnerabilty automatically within 2 minutes.

Responsible lines of code

 1 2 3 4 5 6 7 8 91011121314

$new_htaccess_file_path = trim($_POST['aiowps_htaccess_file']);
$is_htaccess = AIOWPSecurity_Utility_Htaccess::check_if_htaccess_contents($new_htaccess_file_path);



static function check_if_htaccess_contents($file)
{
   $is_htaccess = false;
   $file_contents = file_get_contents($file);
   if ($file_contents === FALSE || strlen($file_contents) == 0) {
                return -1;
   }

}

Reflected XSS in 1 Million WordPress sites

The caching plugin W3 Total Cache suffered from a reflected XSS vulnerability. The plugin has over 1 million active installation. For the vulnerability to be exploitable, the administrator of the target site must have the Google Analytics functionality of W3 Total Cache enabled. Once an administrator of a WordPress site triggers a XSS payload, arbitrary remote code execution can be achieved in most cases.

Our leading SAST solution RIPS was able to find the vulnerabilty automatically within 2 minutes.

$_GET['extension'] is embedded into JavaScript code without sanitization

Resonsible lines of code

 1 2 3 4 5 6 7 8 910

$page = 'extensions/' . $_GET['extension'];
$google_analytics = "<script type='text/javascript'>";
$google_analytics .= "ga('create', '$profile', 'auto');";
$google_analytics .= "ga('set', {";
$google_analytics .= "'userId': '$current_user->user_email',";
$google_analytics .= "'page': '$page'";
$google_analytics .= "});";
$google_analytics .= "ga('send', 'pageview');";

echo $google_analytics;

Unpatched Privilege Escalation in WooCommerce and WordPress Importer

WooCommerce is the most popular eCommerce plattform on the web and has over 4 million active installations. It suffers from an unpatched Object Injection vulnerability that can be exploited by attackers who are in control of a user account with Shop manager privileges on the target site. The issue occurs because Shop managers have the import capability, which means they can use the native WordPress importer to upload XML files and import posts and pages. The WordPress Importer is a plugin by wordpress.org and has over 4 million active installations. If it is installed, evil Shop managers can simply upload a malicious XML file and import it. The WordPress importer allows users to have serialized PHP strings in the import files and will unserialize them, which leads to PHP Object Injections. This is in itself not a high security risk because only administrators should be allowed to use the importer. However, WooCommerce also allows Shop managers to use the import functionality. Since WooCommerce contains classes that allow building a POP chain that leads to arbitrary code execution, a privilege escalation and full site takeover is possible. Automattic, the company behind WooCommerce did not remove the Shopmanager's capability to use the importer when we reported it.

WordPress Core Post Type privilege escalation

Our security researchers have identified a logic flaw in the way WordPress handles posts that allows for privilege escalation exploits in hundreds of plugins and the WordPress core itself.

  Scan your code for vulnerabilities

Arbitrary File Read in 5 million WordPress sites

Contact Form 7 is the most popular WordPress plugin and is used by over 5 million WordPress sites. The plugin suffered from a vulnerability that allowed attackers in control of a user account with at least Contributor privileges to read arbitrary files on the server, including the WordPress configuration file wp-config.php, which stores the database credentials of the WordPress installation of the target site. With this information, an attacker can perform a full site takeover and in most cases execute arbitrary code on the target machine.

  Get Your Free Trail

Proof of concept video