A content injection vulnerability exists in WordPress 4.7 and 4.7.1. If you are running either of these versions of WordPress, you need to update to 4.7.2 as soon as possible. What is the vulnerability, and how do I protect against it? This post aims to answer many of the questions.
What is a content injection vulnerability?
A content injection vulnerability allows unauthorised third parties to create or modify content on your website without logging in. This is the case in the latest vulnerability in WordPress.
My WordPress 4.7 based blog has been compromised. Are my user details safe?
The short answer is yes. With any vulnerability, though, I would recommend changing user account details if you think your site has been compromised.
How do I know if my WordPress 4.7 site is at risk?
If you are running versions of WordPress prior to 4.7 you are not at risk from this vulnerability. Equally, if you’re running WordPress 4.7.2 and higher, you are not at risk from this particular vulnerability. It’s worth double-checking your WordPress version, though.
How to check my WordPress version
Login to WordPress, hover over the WordPress logo in the top left corner of your dashboard and choose ‘About WordPress’.
You will be able to see the version you are running where it says ‘Welcome to WordPress 4.x.x’.
Look out for emails from Google
If you have set up Google Webmasters Tools with your site, Google may email to tell you that your site is at risk. The email looks a little something like the one below.
With any email and vulnerability, there will always be people trying to take advantage of the situation, so make sure any emails you receive are actually from Google and not a phishing attack.
If in doubt, visit Google Webmasters Tools and login instead of clicking through from an email, you will see a message with regards to any sites with this vulnerability.
What specifically is the issue with WordPress 4.7 and 4.7.1
The issue lies in one of the crowning features of 4.7, the Rest API. This was previously a plugin (which appears to still be in beta) but nevertheless, it’s been baked into WordPress core as of 4.7.
The file /wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php has the vulnerability. When passing a ID which is alphanumeric to the endpoint, a check is made to see whether a post exists and if the current user has permission to edit it. When performing this check, the alphanumeric post is cast to an int before being passed to get_post().
If we then also pass a post ID as part of the URL to the rest endpoint with an alphanumeric $_GET[‘id’] parameter the endpoint allows the post to be modified. This is because $_POST has less priority than $_GET, and the get_instance() method already has an instance due to the prioritisation of $_GET over $_POST.
What do I do next?
For the love of God, please please update WordPress to version 4.7.2 (or later if it exists when you read).