2004804 - (CVE-2026-8962) Mixed Content blocker bypass via `data:` iframe

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P3)

Description

[Manojkumar Jaganathan]

Attachment: Screenshot 2025-12-09 at 02.11.34.png

Hi Team,

• In Firefox version 145.0.2 on macOS Tahoe 26.1, it is possible to bypass both mixed content protection and popup blockers by using a blob: URL to inject insecure HTTP content (such as an image) within a secure HTTPS context. The content loads automatically without any user interaction, potentially leading to the exposure of malicious or insecure resources.

Proof of Concept:

• I have uploaded the proof of concept video in my drive and turned on the link sharing for your review and reference.

https://drive.google.com/file/d/1Vlyo_0VrtCdT0qdDyoZAraToCkhDj7gr/view?usp=sharing

Impact:

• Mixed Content Bypass: Insecure HTTP resources are loaded within a secure HTTPS page, potentially undermining the security of the site and compromising the user's experience.
• Popup Blocker Evasion: The attack bypasses the popup blocker, automatically opening a malicious popup without user consent.
• Security Risk: This vulnerability could be exploited to load malicious content, such as scripts, ads, or images, which can lead to phishing attacks, malware delivery, or other types of exploits.

Reproduction Steps:

1. On a secure HTTPS site (e.g., apple.com or openai.com or youtube.com), open the browser console.

2. Enter the following JavaScript code:

   document.body.addEventListener("click", () => {
     const html = `<img src="http://hackerbro.net/assets/images/preload-logo.png">`;
     const encoded = "data:text/html," + encodeURIComponent(html);
   
     const blob = new Blob(
       [`<iframe src="${encoded}" style="width:100%;height:100%;border:0;"></iframe>`],
       { type: "text/html" }
     );
   
     const url = URL.createObjectURL(blob);
     window.open(url);
   });
   console.log("Click anywhere on the page to open the window.");
   

3. Click anywhere on the page to trigger the popup.

4. A new popup opens with a blob: URL (blob:https://www.youtube.com/...) and automatically loads an insecure HTTP image (http://hackerbro.net/assets/images/preload-logo.png), bypassing mixed content blocking.

Observed Behaviour:

• The insecure image is loaded inside the popup, despite the parent page being served over HTTPS.
• No prompt or warning is shown to the user to allow mixed content.
• The popup opens automatically, bypassing any popup blocker protections.
• The popup loads content from an HTTP URL without requiring any user interaction or consent, resulting in unintended mixed content exposure.

Expected Behaviour:

• The image (http://hackerbro.net/assets/images/preload-logo.png) should be blocked or upgraded to HTTPS, as the parent page is loaded over HTTPS.
• The popup should require user interaction to open, and the popup blocker should prevent automatic opening.

Recommendation:

1. Enforce strict mixed content blocking inside blob: and data: URLs, preventing the loading of insecure HTTP resources.
2. Ensure that popups triggered in secure contexts do not automatically load content from insecure sources without user interaction.
3. Strengthen popup blocker mechanisms to prevent bypass via blob: URLs or similar schemes.

Comment 1

[Manojkumar Jaganathan]

Attachment: Screenshot 2025-12-09 at 01.40.12.png

Comment 2

[Manojkumar Jaganathan]

Attachment: Screenshot 2025-12-09 at 01.39.57.png

Comment 3

[Manojkumar Jaganathan]

This issue is referenced from Chromium Issue 40062462.

Comment 4

[:Gijs (he/him)]

Does the same trick work if the webpage does the window opening and click event listening itself (i.e. without requiring the user to use the devtools console) ?

The popup opens automatically, bypassing any popup blocker protections.

The popup opens because the user clicks on the page. Clicks (and user interaction generally) are allowed to open popups, AFAIK also in other browsers. That isn't a bypass of the popup blocker.

Comment 5

[Manojkumar Jaganathan]

When my HTTPS page https://attacker.hackerbro.net/mixedcontent.html opens a blob: URL in the popup, the blob document inherits the HTTPS origin (blob:https://attacker.hackerbro.net/c955df87-2107-4b2c-b4dd-8044a6cde754). Inside that blob document, I include an <img> tag that loads an HTTP resource (http://hackerbro.net/...). The browser successfully loads this insecure image inside the blob—even though the top-level page and the blob URL both appear to be HTTPS. In other words, the popup shows a blob:https://… URL, but the rendered content inside it is actually pulled from an insecure HTTP source. This demonstrates that passive mixed content is permitted inside a blob document, which may look like content injection because the final rendered page appears to be fully HTTPS although it displays resources from an insecure origin.

Proof of Concept:

• I have uploaded the proof of concept video in my drive and turned on the link sharing for your review and reference.

https://drive.google.com/file/d/1Q4nBdqf690mixZq8aS6yfJmkT1Cbr4Dk/view?usp=sharing

Comment 6

[Manojkumar Jaganathan]

Attachment: Mixed Content Test.html

Comment 7

[Manojkumar Jaganathan]

Another POC: https://shiny-gnome-fc823b.netlify.app/

Video Link: https://drive.google.com/file/d/1G_W7adihPRsc9UJTQcA9FkhiEGikG1RN/view?usp=sharing

Comment 8

[:Gijs (he/him)]

(In reply to Manojkumar Jaganathan from comment #5)

Inside that blob document, I include an <img> tag that loads an HTTP resource (http://hackerbro.net/...).

Except it doesn't because the img url redirects to an https image. This is also different from comment 0 in terms of not involving a data: iframe inside the blob URI?

Also, this is all passive mixed content (images rather than scripts).

It's not clear to me what the current state of the world is supposed to be here. Freddy, can you help? bug 1779757 is closed but https://support.mozilla.org/en-US/kb/mixed-content-blocking-firefox#w_mixed-content-is-not-blocked-not-secure says something different to what I'm reading some of the dupes/deps to suggest there.

Comment 9

[Frederik Braun [:freddy]]

The state of the world is that Mixed Content Is No More. Everything should be upgraded.

Looks like we "forget" we were on an HTTPS page along the way through either the popup or the blob URL.

I wonder if this is a symptom of the same issue underlying bug 1999257...

Comment 10

[Manojkumar Jaganathan]

Hi Team,

Just Checking in to see if there are any further updates available on this report.

Thank you!

Comment 11

[Malte Jürgens [:maltejur]]

Apologies, I think this fell under the radar a bit, as we weren't sure whether this was a duplicate of or fixed by Bug 1999257. But after Bug 1999257 having landed, I can still reproduce this, so it at least doesn't look like the exact same bug.

From what I can tell so far, we have a logic mismatch between the mixed content blocking and upgrading in this case. The mixed content blocker correctly uses the precursor principal of the loadingPrincipal (which is a nullPrincipal) and doesn't block the request because it expects it to be upgraded. But the mixed content upgrading doesn't happen at all for nullPrincipals.

Comment 12

[Malte Jürgens [:maltejur]]

Attachment: Minimal Reproducer

After some further investigation, this does not just seem limited to this special case with a blob URL, but seems to be a problem with mixed passive content in data: URLs in general. A more minimal example to reproduce could be an iframe like this

<!-- <img src="http://http.badssl.com/icons/icon-red.png"> -->
<iframe src="data:text/html,%3Cimg%20src%3D%22http%3A%2F%2Fhttp.badssl.com%2Ficons%2Ficon-red.png%22%3E"></iframe>

Placed on an HTTPS site, this loads http://http.badssl.com/icons/icon-red.png without being blocked or upgraded.

Comment 13

[Manojkumar Jaganathan]

Hi @Malte Jürgens, I was able to reproduce your steps. When an HTTPS site loads an iframe that contains HTTP resources (such as a logo or video), those elements are rendered as mixed content and are not automatically upgraded to HTTPS.

Attaching proof of concept image. You can also view the live PoC here: https://attacker.hackerbro.net/mixedcontenttest.html

Thank you!

Comment 14

[Manojkumar Jaganathan]

Attachment: Screenshot 2026-03-23 at 17.43.33.png

Comment 15

[Malte Jürgens [:maltejur]]

Attachment: (secure)

Comment 16

[Malte Jürgens [:maltejur]]

Attachment: (secure)

Comment 17

[Manojkumar Jaganathan]

Hi Team, just checking if this issue has been resolved. Thank you!

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/4977228f2c7b
https://hg.mozilla.org/integration/autoland/rev/a34356b78654
Also check precursor principal for mBrowserUpgradeInsecureRequests r=simonf,necko-reviewers
https://github.com/mozilla-firefox/firefox/commit/4738e0b9c0b0
https://hg.mozilla.org/integration/autoland/rev/8b987ebba3ba
Test data: iframes in mixed content WPTs r=simonf

Comment 19

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/a34356b78654
https://hg.mozilla.org/mozilla-central/rev/8b987ebba3ba

Comment 20

[Manojkumar Jaganathan]

Hi Team, good to hear the reported issue is resolved. Is this eligible for a CVE and reward? Thank you!

Comment 21

[Donal Meehan [:dmeehan]]

Please add uplift requests for esr140

Comment 22

[Malte Jürgens [:maltejur]]

Attachment: (secure)

When checking if the requesting principal is potentially trustworthy for
deciding whether to upgrade mixed content, check the precursor principal in case
it exists. Otherwise, for data: URLs, the loadingPrincipal will be a
nullPrincipal, resulting in it not being potentially trustworthy, which will
lead to no upgrade happening, despite the principal originally responsible for
loading the data: URL being potentially trustworthy.

This aligns the mixed content upgrade behavior to the mixed content blocking
behavior, which is already correctly checking the precursor principal in
GetPrincipalURIOrPrecursorPrincipalURI.

Original Revision: https://phabricator.services.mozilla.com/D289176

Comment 23

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined/Reason for urgency: ESR 140 would contain a sec-low bug that was fixed in release, which allows websites to bypass certain mixed content protections.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing: n/a
• Risk associated with taking this patch: low
• Explanation of risk level: The fix is just changing mixed content upgrading behavior and should not have any impact outside of that.
• String changes made/needed?: No
• Is Android affected?: yes

Comment 24

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/34966198b0c9

Comment 25

[Manojkumar Jaganathan]

Hi Team,

Thanks for the update and reward. Hope the CVE publication is under process.

I would like to add the following credit information for the advisory:

Manojkumar Jaganathan (https://www.linkedin.com/in/manojkumar-j-7ba35b202/) with HackerBro Technologies.

Comment 26

[Manojkumar Jaganathan]

Hi Team,

Could you please share the current status of the CVE assignment/publication for this issue?

Thank you!