All-in-One WP Migration 7.0 Patches XSS Vulnerability

Those who use the All-in-One WP Migration plugin are encouraged to update to version 7.0 as soon as possible as 6.97 contains an admin backend cross-site-scripting vulnerability.

An attacker would already have to be able to either compromise the database or gain access to a user account with high enough privileges to view the backup history, so some damage has already been done, but such an attacker could then also insert some XSS in order to compromise other admin users.

When double-clicking the backup description on the backup history overview page, in order to edit the description text, the text is not sanitized/escaped via html entities when generating the input field.

Vulnerability Report

Version 7.0 was released on the plugin directory about a day ago and patches the vulnerability. According to the stats on the WordPress plugin directory, All-in-One WP Migration is actively installed on more than two million sites.

A proof of concept will be published on July 24th which gives site owners about a week to update. Unfortunately, users who view the changelog prior to updating will not be able to determine it patches a security issue due to the patch being labeled as a general fix.

Updated July 19th

All-in-One WP Migration has released a new update that addresses a different security issue that was introduced in 7.0. Users are strongly encouraged to update to 7.1 as soon as possible.

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

5 Comments


  1. This is a real problem with vulnerability reporting and how plugin authors handle things. The changelog in its current state says;

    Escape backup labels. (Thanks to Connum for reporting)

    It doesn’t actually state that you must update to 7.0 because of a security issue, many will be blissfully unaware of the potential dangers.

    Plugin authors need to stop worrying about ‘saving face’ and tell people they messed up.

    I’ve had plugins with security issues in them and it is a balancing act, you do have to be mindful of attracting exploits against older versions but sometimes you need label these issues for what they are.

    Report


    1. Which is why I said the labelling was unfortunate as I think most users now adays will update quicker if the changlog notes a security fix. On the one hand, you don’t want to notify the world that an exploit exists. On the other, plenty of other people and organizations will or are already doing so, so the responsibility is on the plugin author to educate and inform their users.

      Report


  2. Note that users will actually want to avoid using version 7.0 of this plugin, as it contains another (fairly serious) security vulnerability. Version 7.1 was just released as a fix for this. (Of course, it is generally best for users to keep all plugins updated to the latest version at all times.)

    Report


    1. Thanks for the update, I’ve added this information to the bottom of the post. It has been a rough few weeks for this plugin.

      Report


    2. While looking into the details of the vulnerability you discovered we found a couple of very minor vulnerabilities still present in version 7.1.

      The security design of the plugin is out of line with how plugins are usually secured and might be unnecessarily less secure, so people may want to consider other plugins.

      Report

Comments are closed.