Cross-Site Scripting Vulnerabilities in Elementor Impact Over 7 Million Sites

On February 23, 2021, the Wordfence Threat Intelligence team responsibly disclosed a set of stored Cross-Site Scripting vulnerabilities in Elementor, a WordPress plugin which “is now actively installed and used on more than 7M websites” according to a recent announcement on the Elementor blog. These vulnerabilities allowed any user able to access the Elementor editor, including contributors, to add JavaScript to posts. This JavaScript would be executed if the post was viewed, edited, or previewed by any other site user, and could be used to take over a site if the victim was an administrator.

As Elementor has a contact method specifically for security reports, we were able to provide the full disclosure immediately. Elementor acknowledged the vulnerability the next day, on February 24, 2021. An initial patch was made available in version 3.1.2 on March 2, 2021. However, we recommend updating to at least Elementor version 3.1.4, the latest available at the time of this writing, as it contains additional fixes for the issue.

Wordfence Premium users received a firewall rule protecting against these vulnerabilities on February 23, 2021. Sites still running the free version of Wordfence will receive the same protection after 30 days, on March 25, 2021.

Elementor is a wildly popular editor plugin that allows content creators, including contributors, the ability to visually design websites using “elements” that can be added to any location on the page being built.

Many of these elements offer the option to set an HTML tag for the content within. For example, the “Heading” element can be set to use H1, H2, H3, etc. tags in order to apply different heading sizes via the header_size parameter. Unfortunately, for six of these elements, the HTML tags were not validated on the server side, so it was possible for any user able to access the Elementor editor, including contributors, to use this option to add executable JavaScript to a post or page via a crafted request.

Since posts created by contributors are typically reviewed by editors or administrators before publishing, any JavaScript added to one of these posts would be executed in the reviewer’s browser. If an administrator reviewed a post containing malicious JavaScript, their authenticated session with high-level privileges could be used to create a new malicious administrator, or to add a backdoor to the site. An attack on this vulnerability could lead to site takeover.

Depending on the element, the executable JavaScript could be added in multiple ways.

For instance, the “Column” element, one of the most basic Elementor components, accepts an html_tag parameter. This parameter was output without escaping, and could be set to an inline script, a script with a remote source, or could even be attacked using attribute-based XSS.

The Accordion, Icon Box, and Image Box elements were all vulnerable to this type of attack as well, though the vulnerable parameter names varied depending on the component.

Escaping output isn’t always enough

Escaping the output of the chosen HTML tag might have been sufficient to prevent some of these components from being exploitable, and indeed, the “Section” element and the “Toggle” element suffered from similar flaws but could not be exploited because they escaped their chosen HTML tags, and because any additional content was wrapped inside several other levels of tags.

Unfortunately, however, escaping output is not always sufficient to prevent exploits from occurring. For instance, for the “Heading” element, escaping the output of the header_size parameter would not have been sufficient to prevent Cross-Site Scripting because the heading text was nested immediately inside the header_size tags. As such it was possible to set the header_size parameter to script and add the actual JavaScript to be executed to the heading text. The “Divider” element was also vulnerable to this type of attack via the html_tag parameter because the inner text was nested immediately inside the chosen html_tag.

This is an excellent example of why it is important to validate input in addition to escaping output. Enforcing a list of allowed HTML tags on the server side rather than only on the client side would prevent  exploitation of this type of vulnerability. Indeed, this is the approach the patched version uses to correct the issue.

Timeline

February 23, 2021 – Wordfence Threat Intelligence releases a firewall rule to Premium users and provides full disclosure to the Elementor security contact.
February 24, 2021 – Elementor acknowledges the disclosure and begins to work on a fix.
March 2, 2021 – An initial patch becomes available in version 3.1.2.
March 8, 2021 – Additional fixes are put in place in version 3.1.4.
March 25, 2021 – The firewall rule becomes available to free users.

Conclusion

In today’s article, we detailed stored Cross-Site Scripting(XSS) vulnerabilities present in Elementor, which could be exploited via the Column element as well as the Accordion, Icon Box, Image Box, Heading, and Divider components. These vulnerabilities have been patched in version 3.1.4, and we strongly recommend that all users of Elementor update to the latest version available, which is 3.1.4 at the time of publication.

Wordfence Premium users have been protected against these vulnerabilities since February 23, 2021. Sites still running the free version of Wordfence will receive the same protection 30 days later, on March 25, 2021.

If you know a friend or colleague who is using Elementor, we recommend forwarding this advisory to them, as these vulnerabilities can be used for site takeover. While these vulnerabilities require contributor-level permissions to exploit, the immense popularity of Elementor means that there are likely to be many vulnerable configurations in the wild. As such, we recommend treating these vulnerabilities with greater than normal urgency.

This article was written by Ramuel Gall, a former Wordfence Senior Security Researcher.