Stored Cross-Site Scripting Vulnerability in WordPress 4.8.1

WordPress Vulnerablity Disclosre

Security Risk: Medium

Exploitation Level: Medium

DREAD Score: 7.0/10

Vulnerability: Stored XSS

Patched Version: 4.8.2

Update 11/03/2017:

Read all about vulnerabilities and best practices to secure your website in our newly WordPress Security Guide today!

During regular research audits for our Sucuri Firewall (WAF), we discovered a stored source-based Cross-Site Scripting (XSS) vulnerability affecting WordPress 4.8.1.

Are You at Risk?

The vulnerability requires an account on the victim’s site with the Contributor role – or any account in a WordPress installation with bbPress plugin, as long as it has posting capabilities (if anonymous posting is allowed then no account is needed). All WordPress installations are at risk when these conditions are met.

Besides making it possible to hijack the victim’s user account (among other things), if an administrator user is exploited, the entire WordPress installation and underlying server could be fully compromised.

The XSS vector can make a call to an external script that performs a Cross-Site Request Forgery (CSRF) attack. By acting on the behalf of an administrator user, an attacker can send authenticated requests to edit the website’s current PHP code, leading to Remote Command Execution (RCE) and complete takeover.

Technical Details

The vulnerability occurs in the WordPress editor, responsible for the creating and editing all of the WordPress posts, pages, and topics (in bbPress).

A bypass in the native sanitizing functions of the CMS makes it possible to achieve XSS in the following way:

By using a certain feature of the editor, along with a specially crafted XSS payload in a post or topic, once it is submitted for a review (to be done by a user with a higher role), the payload gets stored (sanitized) in the database.

However, when an administrator or another user with approval permissions opens the post and clicks Save, or Preview – or waits long enough to trigger the WordPress auto-save feature – the rogue HTML plus JavaScript gets decoded and executed in the victim’s browser.

As a limited proof of concept (PoC), we can insert an XSS payload directly in Text tab of editor:

When clicking on the Preview button it is immediately executed:

It shows it’s possible to get JavaScript execution if the sanitizing routine is bypassed in the editor.


Update your WordPress installation as soon as possible. If you have automatic updates enabled on your WordPress site, you should already be using the latest version and are now protected from this vulnerability.

This is a serious vulnerability that can be misused in different ways to compromise a vulnerable site.

If you believe your WordPress site is hacked, you can follow our free DIY cleanup guide.

  1. I believe that’s a result of some roles having the “unfiltered_html” permission? It’s “by design” like that. However only the admins and editors have it enabled by default, unless am mistaken..

    1. I think so. But post-content was encoded by html encode when it showed on index page. I have found similar ‘bugs’ but this ‘by design’ thing messed me.

  2. Hi everyone. I am trying to block the execution of tags inside WordPress content editor. is it possible?

Comments are closed.

You May Also Like