Elementor is one of the world's most popular WordPress plugins, powering millions of websites with easy, drag-and-drop web design. However, serious vulnerabilities occasionally surface — and in 2022, a security flaw identified as CVE-2022-29455 could have put millions of sites at risk.
In this post, I’ll break down this vulnerability into simple terms, show you how it works, give you a code example, and share links for further reading.
What Is DOM-based XSS?
First, let's get clear on terms. DOM-based XSS (Cross-Site Scripting) is a type of attack where JavaScript code on the page uses data from the user (like what’s in the URL) without checking it, then inserts it into the site’s content — or even directly into a script.
If an attacker can insert their code into the page, they can steal cookies, impersonate users, or launch further attacks.
How the Elementor Plugin Vulnerability Works
Elementor Website Builder versions up to 3.5.5 had a flaw in how they used data from the URL. Specifically, some widget scripts were reading URL parameters and directly inserting them into the page’s DOM (Document Object Model) or even into HTML attributes without proper escaping or sanitization.
This is like letting strangers leave sticky notes on your fridge, and then using whatever’s on those notes to make dinner — a recipe for disaster!
Example: The Dangerous Code
Here’s a simplified sample of the kind of JavaScript vulnerability that made this possible (not the actual Elementor code, but close in principle):
// Fetches a URL parameter called 'data'
const urlParams = new URLSearchParams(window.location.search);
const data = urlParams.get('data');
// Puts the untrusted 'data' directly into the page
document.getElementById('output').innerHTML = data;
If a user visits
https://your-site.com/?data=<script>alert('XSS')</script>;
The code would make the page render
<div id="output"><script>alert('XSS')</script></div>
This triggers the alert, but in a real attack, it could steal cookies or hijack sessions.
The Real Exploit in Elementor
Attackers found a way to pass malicious script code through parameters that Elementor's JavaScript would reflect into the page or into an attribute (like a form field value).
Example malicious URL:
https://example.com/?elementor-data=<svg%20onload=alert(1337)>;
If the script inserted this data into an element’s innerHTML or attribute, the code would execute as soon as the page loaded for anyone who clicked the link.
A researcher demonstrated the issue by reporting a payload such as
http://victim.com/?elementorPageId=<img%20src=x%20onerror=alert('XSS')>;
When run, this would pop up an alert box — but a real attacker could do much more.
Why It Works:
How Bad Was It?
- Anyone who could convince a logged-in user or site visitor to click a crafted link could run JavaScript in the victim’s browser.
Here’s a safer way to handle URL data
// Escapes special HTML characters
function escapeHTML(str) {
return str.replace(/[&<>"'`=\/]/g, function (s) {
return (
{
"&": "&",
"<": "<",
">": ">",
'"': """,
"'": "'",
"/": "/",
"=": "=",
"`": "`"
}[s]
);
});
}
const urlParams = new URLSearchParams(window.location.search);
const data = escapeHTML(urlParams.get('data'));
document.getElementById('output').innerHTML = data;
References & Further Reading
- Elementor Security Changelog
- Wordfence Advisory: DOM-based Reflected XSS in Elementor
- CVE Listing: CVE-2022-29455
- OWASP: DOM-based XSS
Conclusion
CVE-2022-29455 was a powerful example of how even the biggest WordPress plugins can make simple security mistakes. The flaw let hackers launch XSS attacks on millions of sites — but only until Elementor’s team quickly fixed it.
Key takeaway: If you develop or manage websites, always escape data from the user, and keep your plugins up-to-date.
If you want to check your WordPress plugins for vulnerabilities, WPScan is a great starting point.
Timeline
Published on: 06/13/2022 17:15:00 UTC
Last modified on: 06/27/2022 16:18:00 UTC