Hacking 6.5+ million websites => CVE-2022-29455 (Elementor)

Hacking 6.5+ million websites => CVE-2022-29455 (Elementor)

Please upgrade your Elementor websites


7 min read

Announcing CVE-2022-29455

Actions you should take if you have Elementor installed:

  1. Scan yourself with this nuclei plugin
wget https://raw.githubusercontent.com/projectdiscovery/nuclei-templates/3581482df1bfe1aef4e7fff96e183f9ef0e5bf13/cves/2022/CVE-2022-29455.yaml
nuclei -t ./CVE-2022-29455.yaml -u https://...
  1. Verify yourself here - Elementor XSS Tester

It all started during the Hackerone ambassador WorldCup.

While scanning our selected target websites we found an interesting wordpress website. After a quick scan for known plugins we found a wordpress plugin installed named "Elementor".

Elementor is a very popular wordpress plugin that had a few vulnerabilities in the past, see previous vulnerabilities here


Before we begin our story some credits are due:

Gal Nagli from Salesforce - Currently 5th place worldwide at HackerOne.
Tomer Zait from F5- Veteran Security Researcher.
Rotem Bar from Cider Security - Creating the first Appsec Marketplace Elementor Security Team - Amazing security team with awesome response.

History Recap

While searching for known bugs in Elementor we saw an interesting bug (CVE-2021-24891) that was raised in the past which uses a DOM-XSS to attack a user logged in to the system.
Because we already have some knowledge in Javascript and had fun with DOM-XSS together in the past, we decided to deep dive into this CVE.

In CVE-2021-24891, Joel Beleña, a cyber security researcher, found out that injecting a payload into the lightbox settings allowed to inject arbitrary javascript into the website where the plugin is used, see more details here - jbelamor.com/xss-elementor-lightox.html

Dissecting Joel’s vulnerability showed us that the payload used the lightbox settings payload in Elementor to force display the lightbox module and give it custom settings in a base64 payload:


Base64 Decoding the settings payload returns us the following json, which shows that the attack attempts to set the type to “null” and setting an html parameter which injects raw unsafe html code into the page:


Back to our story:

Trying to reproduce the original payload in the website (which had an up to date version) didn’t work, but when reading the code it brought us to the understanding that there are different values which can be put in the parameter “type” shown above which can be investigated.

The original problem happened when the “type” parameter was not catched in the switch case code and as you can see in the code it is setting html received from the user.

Screen Shot 2022-06-12 at 20.20.56.png

Unfortunately the fix for the vulnerability was in place and the javascript deletes the “html” parameter before passing it to the affected function as seen below

Stay a while and research

First a small disclaimer, all screenshots and our research was done on the obfuscated code inside the browser, later we found out the code is open source and can be much more easier to read, but for learning purposes we are posting the research as is on the obfuscated code which will simulate better your future assessments.

Going back to the whiteboard, we looked at the different “type” parameters the lightbox module accepts: image, video and slideshow

The “image” doesn’t do much so we skipped through it, and decided to continue with the “video” parameter:

First obstacle:
When using the "video” parameter it needs also a “url” parameter, There is a check that the “url” parameter has to start with “http” (My guess is that in the past it didn’t have it and someone injected a “javascript://” or something like that)

Dissecting the video function brings in interesting insights. It uses JQuery (t variable) to set the video parameters which are coming from a parameter called “videoParams”:

Screen Shot 2022-06-12 at 20.26.53.png

As you can see in the code, in order to reach the state of using the jQuery (t) variable we need to add another parameter called “videoType”. When “videoType” is equal to “hosted” the function creates a new object which is built dynamically and receives parameters "src" and "autoplay" but can be overridden by “videoParams”.
Because "videoParams is controlled by the user, we can add whatever parameter to the video object.

Better Explained by demo

Creating a new payload to verify this:

  "type": "video",
  "url": "http://",
  "videoType": "hosted",
  "videoParams": {
    "style": "background-color:red"

which when encoded to base64 looks like


The payload successfully added a new style parameter which is rendered into the video: Screen Shot 2022-06-12 at 20.32.10.png Screen Shot 2022-06-12 at 20.32.27.png

We are able now to color any video we want and make users see a red screen (Further playing with the payload we were able also to change it to a picture and create a nice phishing page)

Bug bounty is all about impact!!!

Going through attributes that can accept, we found that “onerror” is also allowed, and accepts javascript, so quickly creating a new payload with “onerror” parameter gave us the full exploit.

    "type": "video",
    "url": "http://",
    "videoType": "hosted",
    "videoParams": {
        "onerror":"alert(document.domain+' '+document.cookie)",
        "style": "background-color:red"

If you want to sneak peek at code you can see the exact area which is vulnerable: github.com/elementor/elementor/blob/release..

Our next steps

Our target website is vulnerable, but can we find more?

Elementor is a mega technology, as it is used by at least 6,441,433 websites on the Internet. - BuiltWith

Luckily for us we have lists of many domains and subdomains we can scan for the technology. Crafting a quick search for the plugin started to give us vulnerable websites:

cat list.txt | \
cut -d"/" -f3 | awk 'NF{print $0 "/wp-content/plugins/elementor/assets/js/frontend.min.js"}' | \
httpx -nc -fr -ms "elementor" -er "elementor - v[^\s]*"

Sample scanning..

Disclosure process

The first thing we did was submit the vulnerability to the vendor, so they could start fixing the issue.

We also submitted the vulnerability to the target we researched, letting them know of the vulnerability as we were initially researching them.

Meantime we wanted to prepare for when a fix is available to let all the programs we can find know about it and disclose it in a safe and private matter to customers who are affected by this threat so they can take proper measures to protect themselves. (As this is a DOM based xss, using a WAF cannot help here, but there are other measures customers can take such as hot-patching, removing the plugin, disabling video support etc.)

The task of reaching affected customers and notifying them in a private matter is not easy. Many questions arise here. If the vendor has not fixed the vulnerability yet, what does it help if we tell them about it? Also we don’t want to shout publicly about the problem as it can fall into the wrong hands.

We went on profiling target customers:
Many of the Elementor users are smb businesses which cannot really do anything if we tell them about it and should wait for a proper fix.

But we do have bigger companies who also use Elementor with mature bug bounty programs and security disclosure programs which we can safely communicate with and privately disclose to them the vulnerability.

Searching for the possible candidates was the hardest part of this job.
We created lists of subdomains of companies that do have VDP/BB programs and do accept 3rd party submissions and scanned them for the found vulnerability, then we started disclosing the problem.

The responses were divided into 3 different types of answers:

  1. They accepted the vulnerability and created the needed measures to secure themselves
  2. They do not accept disclosures of 3rd party vendors which affect them
  3. They are already affected by the previous CVE and did not yet patch their systems

A bit about the impact

When found, this vulnerability affected more than 6.5M websites around the world, Every Elementor based website available on the internet was affected if it was hosted by Elementor or self hosted.

As for the Security Impact, an attacker could do the following:

  • Cookies Exfiltration from the affected origins utilizing the Cross Site Scripting vulnerability, that could even allow in certain scenarios into Account Takeovers.
  • Executing JavaScript on the victim's behalf
  • SOAP Bypass
  • CORS Bypass
  • Defacement


We were able to create an account takeover POC which when clicked created a new user if an admin was logged in to his wordpress account.

Disclosure Timeline

11/02/2022 - Disclosure to Elementor.
23/02/2022 - Public Fix.
12/06/2022 - Full Disclosure - Thanks for the patchstack team for helping disclose the CVE.

Bonus - Please test yourselves


Hope you enjoyed the blog