Quick Take: 4.7.0/4.7.1 Unauthenticated Content Injection Key Data Points
-Wordpress Security Risk: Severe
-Exploitation Level: Easy/Remote
-Patched Version: 4.7.2
-Vulnerability: Privilege Escalation / Content Injection – can lead to Remote Code Execution

About the WordPress 4.7.0/4.7.1 Vulnerability

A few months ago a severe vulnerability was found in the new WordPress Rest API that was introduced in version 4.7.0, the vulnerability was discovered originally by a security researcher from Securi. You can view their technical analysis over here.

The vulnerability affects versions 4.7.0 to 4.7.1 and is classified as a severe risk. This post will explore how it can be used in order to gain code execution on default installations of WordPress without the need of any third party plugins aside from those that are installed by default.

Exploitation and how Twistlock Responds to the WordPress 4.7.0/4.7.1 Vulnerability

Our journey begins in the new REST API. One of these REST endpoints gives access to view, edit, delete and create posts. Within this particular endpoint, a subtle bug allows visitors to edit any post on the site.
This vulnerability is extremely easy to exploit, all the attacker needs to do is send a POST request to the API such as /wp-json/wp/v2/posts/1?id=5A in order to modify post whose id equals 5.
For example this code will change the post’s title:

WordPress 4.7.0/4.7.1 Unauthenticated Content Injection

But changing the post and defacing the website is not profitable for the attacker, so we need to scale this thing up by finding a valuable entry point

Visual Composer to the rescue!

Visual Composer is an extremely popular plugin for wordpress, with over 2.2 Million sites using it and more than 40% of the themes that are sold on ThemeForest are shipped with it.
Visual Composer allows the website owner to visually compose his wordpress website by simply dragging elements similarly to how Wix works.

One of the blocks that visual composer provides is “Raw JS” which provides a block that can contain your javascript, this block is represented by the [vc_raw_js] shortcode. The javascript that is surrounded by the shortcode should be html and base64 encoded, for example <script>alert(“Enter your js here”)</script> will look like this will look like this:


We can now test our XSS payload by modifying our targeted post to include the above shortcode:

WordPress 4.7.0/4.7.1 Unauthenticated Content Injection

And the result from executing the above code:

WordPress 4.7.0/4.7.1 Unauthenticated Content Injection

We confirmed that our XSS works!

Now we can move forward and own the server completely.

The small javascript below will modify the Visual Composer’s index.php file when executed by a privileged account, in a way that will give us a remote web shell. This modification will not affect the normal behaviour of the plugin as the index.php file is unused and empty.

WordPress 4.7.0/4.7.1 Unauthenticated Content Injection

Now all we need to do is insert this JavaScript in a place that an admin will see it. Then, when the admin will view a page with that JS code, which in our case will happen when admin logins to the admin panel, the code will execute and modify the page, providing the attacker with a remote web shell at /wp-content/plugins/js_composer/index.php?cmd=id

Let’s not forget to encode our payload first to html and then to base64
So from <script src=’‘></script> we will end up with


and our final exploit will be:

WordPress 4.7.0/4.7.1 Unauthenticated Content Injection

After executing the exploit we can see the new title assigned to the post that we picked, together with the new content (including our evil JavaScript). At the moment an admin will view the page – our JS will execute in the admin’s web session, once this is done we will be able to issue shell commands through wp-content/plugins/js_composer/index.php?cmd={CMD}

For example:

From here the web server is practically owned by the attacker and a savvy attacker won’t stop here.He will establish persistence and will propagate through your server to other machines on the network. It would be especially easy in case your WordPress is not isolated, as it usually happens in case of a containerized environment where communication on the default interface is not blocked.

One of Twistlock’s defense layers is Runtime Radar, which is capable of detecting anomalous container behavior based on data feeds and live analysis of system calls, file system activities, networking and active processes.

In this specific example the C&C that hosted the malicious javascript was flagged by our intelligence stream and the pulling of the JS was stopped by Twistlock, preventing the XSS and stopping the attack from going any further.

In Twistlock 2.1, we’ll be announcing another layer of protection against attacks like this, so stay tuned to our blog and Twitter account to get the latest container security and cloud native news.

← Back to All Posts Next Post →