Our security partner has discovered a vulnerability in the WPBakery plugin for WordPress.  This flaw made it possible for authenticated attackers with contributor-level or above permissions to inject malicious JavaScript in posts…

In the first instance, we highly recommend updating to the latest version, 6.4.1 as of today (8 October 2020), immediately.  While doing so, we also recommend verifying that you do not have any untrusted contributor or author user accounts on your WordPress site.


What is WPBakery?

WPBakery Page Builder is the most popular page builder for WordPress.  It is a very easy to use tool that allows site owners to create custom pages using drag-and-drop tools.  It is commonly packaged up with pre-built themes too, so you may not be aware that you use it.


What is the flaw?

The plugin was designed with a flaw that could give users with contributor and author level roles the ability to inject malicious JavaScript into pages and posts.  This flaw also gave these users the ability to edit other users’ posts.  The plugin explicitly disabled any default post HTML filtering checks in the saveAjaxFe function using kses_remove_filters();.  This meant that any user with access to the WPBakery builder could inject HTML and JavaScript anywhere in a post using the page builder.

Furthermore, while WPBakery only intended pages that were built with the WPBakery page builder to be editable via the builder, users could access the editor by supplying the correct parameters and values for any post.  This could be classified as a general bug as well as a security issue, and is what made it possible for contributors and editors to use the wp_ajax_vc_save AJAX action and corresponding saveAjaxFe function to inject malicious JavaScript on their own posts as well as other users’ posts.

The plugin also had custom onclick functionality for buttons.  This made it possible for an attacker to inject malicious JavaScript in a button that would execute on a click of the button.  Contributor and author level users were also able to use the vc_raw_js, vc_raw_html, and button using custom_onclick shortcodes to add malicious JavaScript to posts.

All of these meant that a user with contributor-level access could inject scripts in posts that would later execute once someone accessed the page or clicked a button, using various different methods.  As contributor-level users require approval before publishing, it is highly likely that an administrator would view a page containing malicious JavaScript created by an attacker with contributor-level access.  By executing malicious JavaScript in the administrator’s browser, it would be possible for an attacker to create a new malicious administrative user or inject a backdoor, among many other things.


How can I protect myself from this in the future?

We recommend using dual account control.  Dual account control uses two accounts for any user that may require administrative capability.  This can be done by using one user account with administrative capabilities for admin-related tasks like adding new users and plugins and another user account with editor capabilities used to review and approve author and contributor posts.

Doing so will limit the impact that a Cross-Site Scripting vulnerability may have.  When you access a page as a site administrator, any malicious JavaScript that an attacker injects can use administrative only functions like adding a new user or editing a theme file to further infect the site.  By using a user account with only editor capabilities while editing, creating, and checking on posts created by lower-level users, an XSS exploitation attempt could be limited, as an attacker can’t successfully add new admin accounts or edit themes through an Editor account.


I need more help…

If you’re hosted with us, we manage your web site and you had the plugin – we will have already updated your site to protect it.  If you’re not with us and would like us to resolve your concerns, please contact us.