1969937 - [Android] URL Bar Spoof (long blob: urls can truncate real domain, bypass fix for CVE-2025-8041)

Status: RESOLVED FIXED

(Firefox for Android :: Toolbar, defect)

Description

[Ameen Basha M K]

Attachment: test.html

HI Team, Firefox nightly latest on android is vulnerable for url bar spoof which allow the attacker to trick the victim with fake url and rending spoofing page

I have already reported longsubdomain urlspoof case but marked as duplicated of below bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1670725 (Now this issue was fixed in firefox nightly on android)

I have found a way to spoof again with below 2 methods

Vulnerable Cases

1. Blob with longer subdomain
2. blob with subdomain renders google.com but shows evil.com in url bar

Steps to reproduce (Case 1)

1. Open the attached html page
2. click the open blob page url
3. you can see the domain is starting from front and shows the front part of the domain
   Note: same was already handled in chrome: https://issues.chromium.org/issues/40052250

Steps to reproduce (Case 2):

1. Open the url bar
2. type blob:/http://jshshshshhs.evil.com
3. you can see google is opened but url bar shows the above one
   Note: Kindly see the poc video for reference

I have attached the poc video, html file, nightly version for reference

Comment 1

[Ameen Basha M K]

Attachment: [Android] Firefox - URL Bar Spoof Blob.mp4

Comment 2

[Ameen Basha M K]

Attachment: Screenshot_2025-06-02-21-27-55-56_984e1414ae90666a90f12ff17ec14a7f.jpg

Comment 3

[Michel Le Bihan]

Hello,
I don't understand this vulnerability report. In the second case the blob URI is treated as a search term. When you enter a search term in the omnibox and proceed to search, the search terms are shown there (not the Google URL). That's the expected behavior. Why do you think that it is an issue?

In the first case, what do you believe that should be shown in the address bar?

Comment 4

[Ameen Basha M K]

HI Michel,

Regarding case2, i tested the case on chromium browser and when i back to firefox it shows the blob search url in the omni box instead of google.com which is confusing whether im actually in google search or above blob url page loaded. (so i though of loading the full url here will be right solution to avoid any user confusion)

Regarding case 1, similar to your long subdomain fix. (we can show the same here)
As per my understanding bob urls can render only on the particular site

so attacker do the below scenario

1. create and host a malicious page in long subdomain eg: https://google.com.safe.somerandom.longdomain.com
2. when user click it shows the url as per your fix
3. but as soon as the page is loaded (or) when the user click the age we can load the blob from it
4. which now shows blob:/http://google.com..... in url

Chrome implemented similar fix.

Kindly check the attached reference link

Comment 5

[:Gijs (out until Jan 5th; he/him)]

For case 2, it's maybe worth noting that we deliberately avoid this scenario on desktop, cf. https://searchfox.org/mozilla-central/rev/8acb5f362849305467afc045e3c0f84625a03ebc/browser/components/urlbar/UrlbarSearchTermsPersistence.sys.mjs#156-183 .

Comment 6

[Michel Le Bihan]

For case 2, it's maybe worth noting that we deliberately avoid this scenario on desktop

I believe that it is actually https://bugzilla.mozilla.org/show_bug.cgi?id=1964736 that should be fixed.

Comment 7

[Michel Le Bihan]

Attachment: Bug 1969937 - Add handling of blob URIs in Android toolbar URLRenderer. r=petru

Comment 8

[Petru-Mugurel Lingurar [:petru]]

Attachment: Firefox desktop and Fenix displaying a blob url .png

Regarding the "Case 1" I think an important clue for users that "this is not the page they want" is that the url starts with blob and the security lock is crossed out (at least on mobile).
So the spoofing attack is limited in my opinion.

Comparing Firefox desktop with Fenix I see the same behavior.
Testing v Chrome I do indeed see them highlighting the domain, looks like we should do the same.
We can probably target this particular blob protocol.

Comment 9

[Michel Le Bihan]

is that the url starts with blob

This assumes that users know what blob: URLs are and I bet that most users don't have a clue. I think that it's better to emphasize the domain.

I proposed a change for handling those blob URLs: https://phabricator.services.mozilla.com/D252879

Comment 10

[Petru-Mugurel Lingurar [:petru]]

Attachment: Firefox desktop not searching with a blob protocol.png

@Gijs Testing "Case 2" on desktop I see that Firefox tries to load blob:/http://jshshshshhs.evil.com as an URL and fails. Not sure if this is per design or not.

Looking at the getFixupURIInfo method used on desktop I see quite a bit of code that we might want to take in (thanks!) and importantly in this case we should not focus on the particular "blob" scheme.

Comment 11

[:Gijs (out until Jan 5th; he/him)]

(In reply to Petru-Mugurel Lingurar [:petru] from comment #10)

Created attachment 9493618 [details]
Firefox desktop not searching with a blob protocol.png

@Gijs Testing "Case 2" on desktop I see that Firefox tries to load blob:/http://jshshshshhs.evil.com as an URL and fails. Not sure if this is per design or not.

We avoid doing a search (because it looks like a URL, so we don't want to give it all to the default search engine and leak what the user typed, even if they typo'd a valid URL). So we show an error page instead.

If you do an explicit search, using the question mark operator (so type ? followed by the blob URL), then the address bar shows a full URL (if using google as default search, https://www.google.com/search?...), to avoid confusion for the user. If you compare with doing a search for "foo", you will see that the address bar in that case only shows "foo" to make it easier to edit the web search, as there can be no confusion that it's a URL, it's clearly a search term.

Hopefully that helps?

Looking at the getFixupURIInfo method used on desktop I see quite a bit of code that we might want to take in (thanks!) and importantly in this case we should not focus on the particular "blob" scheme.

Yeah, if Android could reply on Services.uriFixup (which is that implementation) in JS, that would share a lot of the implementation and would improve things, instead of having to reimplement things in two places. I don't know how feasible that is.

Comment 12

[Petru-Mugurel Lingurar [:petru]]

Thank you for all the details!
Seems like then having Fenix match the behavior from desktop is a bit more work that I think can be split to a separate ticket with the patch posted by Michel avoiding the spoofing from case 1.

Comment 13

[Petru-Mugurel Lingurar [:petru]]

@Michel The patch looks good to me but we'll have to also get a security approval before landing.
Some details about this process are here and here.

@sec-team I'm a bit worried about including tests also (though they may not indicate a security issue) and I think the commit message should not include the bug number?

Comment 14

[Petru-Mugurel Lingurar [:petru]]

Comment on attachment 9493347 [details]
Bug 1969937 - Add handling of blob URIs in Android toolbar URLRenderer. r=petru

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Medium complexity.
  The patch shows the scenario of having an URL that starts with blob but does not indicate what security implications could this have.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: All branches.
• If not all supported branches, which bug introduced the flaw?: None
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: The patch builds on top of a recent change in Nightly bug 1812898 - relatively risky and with a new UX that we'd not want to uplift.
• How likely is this patch to cause regressions; how much testing does it need?: Small targetted change with low risk or regressions.
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 15

[Michel Le Bihan]

Why would this be a security consideration? It's already possible to use a long subdomain to get the real domain out of view in stable. That's a well known issue. How are blob URLs different in that regard? The only issue is that I was not handling them in my previous commit.

Comment 16

[Petru-Mugurel Lingurar [:petru]]

The ticket is marked as a "security issue".

Comment 17

[Andrew McCreight (out until 2026) [:mccr8]]

(In reply to Michel Le Bihan from comment #15)

Why would this be a security consideration? It's already possible to use a long subdomain to get the real domain out of view in stable. That's a well known issue. How are blob URLs different in that regard? The only issue is that I was not handling them in my previous commit.

I agree that this isn't really a new problem on release, but it is a (minor) security issue on Nightly, where the other patch to handle long subdomains did land.

Comment 18

[Ameen Basha M K]

(In reply to Andrew McCreight [:mccr8] from comment #17)

(In reply to Michel Le Bihan from comment #15)

Why would this be a security consideration?

I agree that this isn't really a new problem on release, but it is a (minor) security issue on Nightly, where the other patch to handle long subdomains did land.

Adding a point, The long subdomain issue is applicable in stable yes, if this was not reported then it will affect the fix landed on stable later and still affect users, The scenario here is same vulnerability with 2 different method was report in which one doesnt fix the other one. The url bar is above line of death which is trusted by user, usually it will be higher focusing area on browser. And this issue affects that. so this will be considered as a security issue with same severity.

Comment 19

[Andrew McCreight (out until 2026) [:mccr8]]

Comment on attachment 9493347 [details]
Bug 1969937 - Add handling of blob URIs in Android toolbar URLRenderer. r=petru

Thank you for your caution, but this is a sec-low and is Nightly-only so it doesn't need security approval. Feel free to land the tests at the same time, too.

I think the commit message should not include the bug number?

The commit message should always include the bug number. The only situation where you might want to skip it would be is if you were doing a try push or something.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a88f677c3768
https://hg.mozilla.org/integration/autoland/rev/53460d5fde1d
Add handling of blob URIs in Android toolbar URLRenderer. r=petru,android-reviewers

Comment 21

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

https://hg.mozilla.org/mozilla-central/rev/53460d5fde1d

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:michel, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox140 to wontfix.

For more information, please visit BugBot documentation.

Comment 23

[Daniel Veditz [:dveditz] back January 5, 2026]

Ameen: what is the danger here? the user will get a page from their default search engine (set by them, not their attacker) with a weird-looking "URL" that's echoed in the search page. Confusing, but how do you who are not Google exploit this?

Comment 24

[Ameen Basha M K]

Hi daniel

I hope your query is regarding my attacker vector case 2(which is confusing for the user but still there will be a user interactions involved in this case, i have mentioned this to avoid any future attacks of chains)

the actual issue here is blob url was displayed from start, instead of showing actual domain. (Case 1)

I have attached the chromium reference too, which is what exactly vulnerable here and i hope the same was fixed here.

If we fix the case 2 it will be more like a good to go case because it actually confusing whether im in search engine or in actual search. since we cant control the data showed in search engine pages unless a xss it is a low level bug (also a xss in search engine is out of our firefox scope).

Comment 25

[Michel Le Bihan]

Since this issue is now fixed in Nightly, could this issue be made public?

Comment 26

[Ameen Basha M K]

(In reply to Michel Le Bihan from comment #25)

Since this issue is now fixed in Nightly, could this issue be made public?

Still the stable is vulnerable, so can we make it public post release of stable?

Comment 27

[Ameen Basha M K]

Team for this attack there is no much user interaction needed so can i get to know why it is marked as sec-bounty-.

kindly check on this

Comment 28

[Andrew McCreight (out until 2026) [:mccr8]]

It doesn't look like a very convincing spoof, because the blob in the front looks weird, so we marked it sec-low, and sec-low spoofs no longer qualify for bounties. Bug 1670725 was marked as a sec-moderate, but our rating policy for these spoofs has changed since that was filed.

Comment 29

[Ameen Basha M K]

Yeah i understood with the policy change but still it is result in spoof. Agree with the point Blob: in the front but still peoples might falls for the cases (possibly) and it is affecting the users major trusted area (which is by default categorized as high in line of death- since we can break user trust here)

So I request to keep the issue in moderate and award bounty respectively

waiting to know your team points.

Comment 30

[Andrew McCreight (out until 2026) [:mccr8]]

We no longer award bounties for spoofs unless they are sec-high address bar spoofs, so whether it is sec-moderate or sec-low does not affect whether it qualifies for a bounty. If you have any further questions about our recent changes to our bounty for spoofs, please email [e-mail] rather than continuing to discuss it in this bug.

Comment 31

[Simon Friedberger [:simonf]]

Attachment: advisory.txt

Comment 32

[Simon Friedberger [:simonf]]

Comment on attachment 9500520 [details]
advisory.txt

This part of the bug was actually a dupe.

Comment 33

[Ameen Basha M K]

Hi team, hope CVE will be assigned for this case, This issue is actually a bypass for long subdomain url spoof.

I have raised this after verifying the issue fix of the long domain where this issue wasnot fixed

hope only the bounty restriction is there for spoof bugs and CVE will be assigned as usual

FYI: Medium level spoof bug

Comment 34

[Michel Le Bihan]

Hi team, hope CVE will be assigned for this case, This issue is actually a bypass for long subdomain url spoof.

I have raised this after verifying the issue fix of the long domain where this issue wasnot fixed

Could you please provide more details that would help me reproduce the issue?

Comment 35

[Ameen Basha M K]

Hi Michel, there is no new bypass, i was mentioned it as bypass during it was raised from my end.

Last comment shows advisory was obselete so wasnt sure CVE will be awarded for this case or not

Kindly confirm this with above points for CVE assigning (since it was a separate bug and not a duplicate of long subdomain url spoof bug)

Comment 36

[Simon Friedberger [:simonf]]

There will be no CVE assigned for this issue. The first part of this bug was a duplicate and the second part is too contrived.

Comment 37

[Ameen Basha M K]

(In reply to Simon Friedberger (:simonf) from comment #36)

There will be no CVE assigned for this issue. The first part of this bug was a duplicate and the second part is too contrived.

This one is not a duplicate, the first case was a edge case missed in another report. also you can see the bounty discussion in comment 30, if it was duplicate there will not be a need for bounty discussion in place but here it was declined due to the recent policy change for spoof bugs

first part is a separate issue and the fix is also implemented for the same with blob handling, requesting for CVE in this case

Comment 38

[Simon Friedberger [:simonf]]

The first case is an exact duplicate of bug 1909609.

Comment 39

[Daniel Veditz [:dveditz] back January 5, 2026]

I assumed the patch in this bug was for the second issue because bug 1909609 comment 17 claimed that one was fixed, and neither the reporter nor QA folks disagreed. Instead, it looks like THIS is the home of the actual blob: url truncation fix. That means

• bug 1909609 was not, in fact, "the same thing" as bug 1670725 / bug 1812898
• the "blob" variant therefore does rate a separate CVE
• as the earlier report the CVE should go to 1909609
• we need to add an advisory to the 141 release
• the advisory should credit both Rifa'i and Ameen, and reference both bug 1909609 and this bug 1969937

The second case of pasting a "blob-looking" thing is not fixed, but "blob:" is just incidental. xx:/https://www.google.com behaves exactly the same because our algorithm is apparently "It's not a valid URL so it must be a search term, even if it's clearly nonsense garbage as a search term". We already have complaints about showing search terms, but if we want to pursue it at this point we should split that into a separate bug.

Comment 40

[Daniel Veditz [:dveditz] back January 5, 2026]

We already have complaints about showing search terms, but if we want to pursue it at this point we should split that into a separate bug.

Ah, that's what the see-also bug 1964736 and bug 1978517 are about (generally, not this specifically)

Comment 41

[Michel Le Bihan]

The second case of pasting a "blob-looking" thing is not fixed, but "blob:" is just incidental. xx:/https://www.google.com behaves exactly the same because our algorithm is apparently "It's not a valid URL so it must be a search term, even if it's clearly nonsense garbage as a search term".

Why would that be a security issue? Those URIs should redolve to any actual resource.

Comment 42

[Ameen Basha M K]

Hi team, its been 3 days since the advisory published, could your team please check and update my name acknowledgement in the CVE.

Thanks

Comment 43

[:Gijs (out until Jan 5th; he/him)]

(In reply to Ameen Basha M K from comment #42)

Hi team, its been 3 days since the advisory published, could your team please check and update my name acknowledgement in the CVE.

Thanks

--> Tom

Comment 44

[Ameen Basha M K]

Hi Tom, can you update on this?

Comment 45

[Tom Ritter [:tjr] (OOTO until April)]

https://github.com/mozilla/foundation-security-advisories/commit/9552138dc3344d2275b616d77d586edf6037875b