Protecting your WordPress site against the reset password WordPress vulnerability

WordPress is an open source CMS, first developed back in 2003 as a way to enhance the typography of everyday writing. Since then, it’s grown into the largest self-hosted content management system used by millions of people daily. Our eCommerce development teams have extensive knowledge of the WordPress platform and have years of experience building bespoke websites and plug-ins to suit our clients needs. Get in touch to see how we can design, develop and market your new website today. WordPress vulnerability can be an issue however, but at Xigen we always make sure to be up-to-date with what’s going on.

How the WordPress vulnerability works

This WordPress vulnerability is caused by WordPress using untrusted data when the password reset e-mail functionality is triggered. In the code snippet below you can see where the issue begins.

if ( !isset( $from_email ) ) {
        // Get the site domain and get rid of www.
        $sitename = strtolower( $_SERVER['SERVER_NAME'] );
        if ( substr( $sitename, 0, 4 ) == 'www.' ) {
                $sitename = substr( $sitename, 4 );
        }

        $from_email = 'wordpress@' . $sitename;
}

WordPress uses SERVER_NAME to get the hostname of the server and then build the emails from/return address, in this code snippet we can see how an attacker could exploit the WordPress vulnerability and attempt to gain access to another users account. Major web servers such as Apache are configured to use the hostname supplied by the HOST_HEADER, and because it is set on the client side any user can edit it. Because WordPress doesn’t verify the host is correct, it allows potential attackers to edit the from/return address of the password reset emails.

How an attacker could exploit the WordPress vulnerability

This exploit allows the attacker to use one of three methods to intercept the password reset email. Only one method requires user interaction, and as it could provide an attacker with full control of an admin account it’s listed as a high-risk exploit. An attacker may attempt to access an account using one of the methods listed below…

1. The attacker can perform a DoS attack on the victim’s email server, this could cause the user to exceed their disk quota and prevent the password reset email from reaching the victims email. This would cause it to bounce back to the from address, which the attack has been pointed to their email. This method requires no user interaction.
2. An auto responder (Such as an Out of Office reply) might attach a copy of the email when it replies to the attackers from address, sending the password reset email and the reset link back to the attacker. Again, this method requires no user interaction.
3. Finally, the attacker could send multiple password reset emails to the users account, potentially resulting in the user replying to the email asking for an explanation for the large amount of emails. Replying to the email would return the reset password email back to the attacker’s email address, providing them with the unique reset password link. For this method to work, it requires user interaction.

Is WordPress still safe, and how can I can prevent this happening?

WordPress is still safe to use, but it’s important to ensure you are running the latest version of WordPress and follow their latest news. WordPress continues to be the leading self-hosted content management system and that’s unlikely to change anytime soon. Roughly 28% of all websites online are using WordPress, so it still retains a huge portion of the market. As an open source project, WordPress enjoys regular updates and improvements. There is also a huge community of developers and editors who help to provide support for WordPress.

Unfortunately, at the time of writing this the WordPress vulnerability has not been patched by the WordPress team, so no official solution is available. As a temporary fix, we recommend you enable UseCanonicalName on your server configuration, this will force the SERVER_NAME to use the static value, preventing an attacker from updating it. If you’re using shared hosting you may need to get in touch with your account manager for further guidance.

Read more about UseCanonicalName here.