WordPress Security Calendar 2018

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
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

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
 9
10
11
12
13
14
15
16

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
 9
10
11
12
13
14
15
16
17
18
19

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 vulnerability automatically within 2 minutes.

Proof of concept video

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

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 vulnerability 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
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

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.

1
2
3
4
5
6
7

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

1
2
3
4
5

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 vulnerability automatically within 2 minutes.

Unsanitized post meta is passed to file_exists()

Responsible lines of code

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// 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 vulnerability 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
 9
10
11
12
13
14
15

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 vulnerability automatically within 2 minutes.

Unsanitized post meta is embedded into HTML

Responsible lines of Code

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

// 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 vulnerability automatically within 2 minutes.

add_query_arg() returns user input without sanitization

Responsible lines of code

1

<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 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 vulnerability automatically within 2 minutes.

Responsible lines of code

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

$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 vulnerability 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
 9
10

$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

File Delete to RCE in 1 million WordPress sites

Regenerate Thumbnails is a WordPress plugin with over 1 million active installations. It allows site owners to regenerate the thumbnail sizes of already uploaded images. Attackers in the user role of at least an Author on the target site can delete arbitrary files on the underlying server. We have demonstrated in a blog post how an arbitrary file deletion vulnerability in WordPress can lead to Remote Code Execution.
By deleting the main configuration file wp-config.php of the target WordPress site, WordPress will be unable to connect to the database and prompts the next user with the installation prompt. This is because WordPress acts as if it hadn't been installed if the wp-config.php is missing. The attacker could then simply re-install WordPress and then execute arbitrary code on the machine.

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

User controlled get_post_meta is passed to wp_delete_file()

Responsible lines of code

1
2
3
4
5
6
7

$data = get_post_meta( $post->ID, '_wp_attachment_metadata', true );

foreach ( $old_metadata['sizes'] as $old_size => $old_size_data ) {

    wp_delete_file( $wp_upload_dir . $old_size_data['file'] );

}

RCE in 4 million eCommerce sites

This is a bypass for the patch for the Phar Deserialization described on day 3. As a reminder, Phar Deserializations occur if unsanitized user input is passed to functions such as is_file() or file_exists(). You can read up on how exactly this vulnerability type works here.

WooCommerce suffered from a Phar deserialization in the CSV import function. When a CSV file should be used to import products, attackers were able to set the path of the CSV file to be imported. Instead of telling the server to use for example uploads/import.csv, an attacker was able to tell the server to import the file phar://malicious.phar. This would then trigger the Object Injection of the Phar Deserialization.

To prevent this, WooCommerce added the function is_file_valid_csv().

1
2
3
4
5
6
7

public static function is_file_valid_csv( $file) {
    if ( apply_filters( 'woocommerce_product_csv_importer_check_import_file_path', true ) && 0 !== stripos( $file, ABSPATH ) ) {
        return false;
    }

    return true;
}

This function will check if the target file is an absolute path and only then returns true. ABSPATH is the absolute path of the target WordPress installation (e.g. /var/www/html/wordpress/). However, this check is only performed if the call to apply_filters() returns true.

apply_filters() works by calling all functions that were added to this filter with add_filter(). An example of this is given below

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

function exampleFilter($data) {
    if($data == 'yes')
        return true;
    else
        return false;
 }
add_filter('some_filter', 'exampleFilter');


$bool = apply_filters('some_filter', 'yes');

apply_filters() takes two parameters: The filter name and a default value. It will then call all functions that have been added with add_filter() and return their return value. If no filters are added, the default value is returned. In the example of WooCommerce, this would be true and the check will be performed by default. The only way to bypass the check is to add a filter function to the filter woocommerce_product_csv_importer_check_import_file_path that returns false.

Filters are a part of the WordPress Core and allow modification of data by plugins. If a developer wants to write a plugin for WooCommerce and wants to modify the behavior of the import function, he would first have to add a filter to woocommerce_product_csv_importer_check_import_file_path which returns false, so that no check is performed. If such a plugin was installed, the Phar deserializtion would still work because no check would be performed. However, the following bypass allows to add a filter function that returns false without installing another plugin.

WooCommerce offers users a feature called Webhooks. The purpose of Webhooks are to send the administrator of the shop running WooCommerce email notifications when selected events happen. For example, a Shop manager might specify that he recieves an email every time a customer buys a product with a specific product ID. This is implemented internally by adding a filter function to the event. When for example the site should send an email notification each time the product with the ID 5 is bought, it will add a filter function to the filter purchase-product-5, which is executed every time that specific product is bought. Within the filter function all the email processing happens.

Shop managers can specify the filter name they want to hook in. This allows evil Shop managers to add a filter function to the woocommerce_product_csv_importer_check_import_file_pathfilter. This means that the return value of the Webhook filter function is used instead of the default value true. The Webhook function returns NULL, which is casted to false so the call to apply_filters() returns false and therefor the check is never executed.

SQL Injection in 700.000 WordPress sites

WP Fastest Cache is a caching plugin for WordPress with over 700.000 active installations. It was vulnerable to a SQL Injection. The vulnerability was exploitable by attackers who had any type of account on the target website running WP Fastest Cache, including customers of a store or forum users.
By exploiting the vulnerability, an attacker could steal all data of the target WordPress site and take over the administrator account, which would then lead to a full site takeover.

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

User input is embedded into a SQL query and is sanitized with the wrong function

Responsible lines of code

1
2

global $wpdb;
$terms = $wpdb->get_results("SELECT * FROM `".$wpdb->prefix."term_relationships` WHERE `object_id`=".esc_sql($_GET['id']), ARRAY_A);

Unprivileged Phar Deserialization in 100.000 WordPress Sites

WP Job Manager is a plugin by Automattic with over 100.000 active installations. It allows site owners to easily create job listings on their WordPress site. Attackers were able to sign up and upload a company logo for their listing. This upload functionality was vulnerable to a Phar Deserialization, which left over 100.000 sites vulnerable to a PHP Object Injection that results from Phar Deserializations. If other plugins are installed that make the Object Injection exploitable, a full takeover by unauthenticated remote attackers was possible.

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

The user controlled $attachment_url is passed to the vulnerable function wp_generate_attachment_metadata()

Responsible lines of code

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// $attachment_url is under full control of an attacker
protected function create_attachment( $attachment_url ) {

$attachment = array(
    'post_title'   => wpjm_get_the_job_title( $this->job_id ),
    'post_content' => '',
    'post_status'  => 'inherit',
    'post_parent'  => $this->job_id,
    'guid'         => $attachment_url,
    );

    $attachment_id = wp_insert_attachment( $attachment, $attachment_url, $this->job_id );

    // this function will call getimagesize() on $attachment_url, which is vulnerable to Phar Deserialization
    $meta_data = wp_generate_attachment_metadata( $attachment_id, $attachment_url )
    wp_update_attachment_metadata( $attachment_id,  $meta_data);
    return $attachment_id;
}

Stored XSS in 4 million WordPress sites

WooCommerce suffered from a Stored XSS vulnerability that allows attackers who took control over an accout with Shop manager privileges on the target site to hijack the session of the admin user and perform a full site takeover.

The vulnerability occurs because of a common design flaw in application security. When data is stored in the database, it is sanitized correctly and secure. The application then trusts the data, since it was sanitized when it was initially stored, and then uses it without any further security checks when pulling it from the database. However, sometimes data can be modified that is already stored in the database. This happened in WooCommerce. When an evil Shop manager wants to create a new Order from within the Admin dashboard, all input is sanitized and stored safely. If the Shopmanager creates the order via the REST API of WordPress, the data will not be sanitized. Since WooCommerce trusts all data in the database, the Stored XSS occurs.

Wormable Stored XSS on WordPress.org website

Our security researchers have identified a critical stored XSS vulnerability on the plugin repository on WordPress.org. In wrong hands, the vulnerability could have been exploited to infect all WordPress plugins with malicious code.