2000218 - (CVE-2025-14331) Logic error in OAuth redirect validation allows cross-window interception with launchWebAuthFlow

Status: RESOLVED FIXED

(WebExtensions :: Request Handling, defect, P1)

Description

[disclosure]

Vulnerability Details
A logic error in the redirect validation guard allows an attacker-controlled tab to prematurely resolve OAuth flows by issuing a fetch() request to the extension's predictable redirect URL. The incorrect AND condition treats channels from any tab as valid if they have a browserElement, allowing cross-window interception.
Impacted code:

// toolkit/components/extensions/parent/ext-identity.js:79-84
if (
  !wrapper.browserElement &&  // Logic error: should be OR, not AND
  wrapper.browserElement !== window.gBrowser.selectedBrowser
) {
  return;
}

Reproduction Steps

1. Install a WebExtension that uses browser.identity.launchWebAuthFlow and initiate OAuth sign-in to open the popup.
2. In an attacker-controlled tab, execute fetch("https://<extension-hash>.extensions.allizom.org/?code=malicious") using the extension's predictable redirect domain.
3. The OAuth popup closes immediately and launchWebAuthFlow resolves with the attacker's URL.

Impact

• Account binding: Extension receives attacker-controlled OAuth code/tokens, binding user session to attacker's account
• Data exfiltration: User data synced after "sign-in" goes to attacker's remote account
• Session fixation: User operates under attacker's account context within the extension

Tested on:

• Mozilla Firefox 144.0.2 (aarch64)
• Mozilla Firefox 146.0a1

Best regards,
Igor Morgenstern
Aisle Research

Comment 1

[:Gijs (he/him)]

https://searchfox.org/firefox-main/rev/1c2b83c1fdb8ba523831bcdb63947f5f7a4cfa5e/toolkit/components/extensions/parent/ext-identity.js#77-84

// Early exit if channel isn't related to the oauth dialog.
let wrapper = ChannelWrapper.get(channel);
if (
  !wrapper.browserElement &&
  wrapper.browserElement !== window.gBrowser.selectedBrowser
) {
  return;
}

Code appears to be from bug 1616596 and also code coverage suggests that we never hit the early return.

Comment 2

[Daniel Veditz [:dveditz]]

I think Gijs meant it was regressed by bug 1616596, not blocks?

In the bigger picture we're calling this "sec-moderate" because it would only affect a very specific subset of Firefox users, and the attack would involve some timing/guessing to make work. But of course the effect on the vulnerable group would be serious.

Luca: could you take a look?

Comment 3

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: (secure)

Comment 4

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: (secure)

Comment 5

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #2)

I think Gijs meant it was regressed by bug 1616596, not blocks?

Sort of - I think the patch added this early return but the early return is never taken (not verified, but that's what comment 0 and the coverage results suggest). To me that also suggests that it's possible that this was broken before 1616596, but I haven't verified. Not sure how important that is, but either way hopefully Luca can take it from here.

Comment 6

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Daniel Veditz [:dveditz] from comment #2)

Luca: could you take a look?

Definitely, I looked into it right away today and I just attached patches to this bug (one includes a new test case and the other one the one line fix for the logic error).

Independently from how much timing and guessing required to leverage the issue, I'd really prefer us to land a fix for this issue sooner rather than later and so I'm also setting its priority to P1 and severity to S2.

Comment 7

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to :Gijs (he/him) from comment #5)

(In reply to Daniel Veditz [:dveditz] from comment #2)

I think Gijs meant it was regressed by bug 1616596, not blocks?

Sort of - I think the patch added this early return but the early return is never taken (not verified, but that's what comment 0 and the coverage results suggest). To me that also suggests that it's possible that this was broken before 1616596, but I haven't verified. Not sure how important that is, but either way hopefully Luca can take it from here.

I took a look if before Bug 1616596 changes the same kind of issue would still be possible, and I got the impression that on that previous version of the logic the trick may also work if the tab controlled is in the same window that launchWebAuthFlow created (because it was registering a progress listener on gBrowser and if I'm not mistaken open a second tab in the same window may have been able to hijack the auth flow).

That is mainly a guess based on how I was interpreting the older version of the logic while looking it from searchfox, I didn't try to go back to that version because it didn't feel worth it confirming that given how far in the past that version was.

Comment 8

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

Set release status flags based on info from the regressing bug 1616596

Comment 9

[Daniel Veditz [:dveditz]]

Comment on attachment 9528126 [details]
(secure)

Doesn't technically need sec-approval as a sec-moderate, but it's borderline and I did discuss this with Luca. sec-approval+

Please wait a full cycle after the release before landing the test, say 2026-01-21 or later. BugBot should give you a reminder at that time

Comment 10

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: (secure)

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

Comment 11

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: An attacker-controlled tab to be able to prematurely resolve OAuth flows by issuing a fetch() request to the extension's predictable redirect URL if triggered at the right time, and get the extension that has initiated the OAuth flow through the identity WebExtensions API to receive the attacker-controlled OAuth tokens (and as a consequence the extension would be tied to the attacker controlled account, and user data exfiltrated when sent through the service account controlled by the attacker).
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Low risk because the fix is a one line change fixing the logic error, no side effect expected besides fixing the issue tracked by this bug.
• String changes made/needed: No
• Is Android affected?: no

Comment 12

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: (secure)

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

Comment 13

[Phabricator Automation]

firefox-esr115 Uplift Approval Request

• User impact if declined: An attacker-controlled tab to be able to prematurely resolve OAuth flows by issuing a fetch() request to the extension's predictable redirect URL if triggered at the right time, and get the extension that has initiated the OAuth flow through the identity WebExtensions API to receive the attacker-controlled OAuth tokens (and as a consequence the extension would be tied to the attacker controlled account, and user data exfiltrated when sent through the service account controlled by the attacker).
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Low risk because the fix is a one line change fixing the logic error, no side effect expected besides fixing the issue tracked by this bug.
• String changes made/needed: No
• Is Android affected?: no

Comment 14

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: An attacker-controlled tab to be able to prematurely resolve OAuth flows by issuing a fetch() request to the extension's predictable redirect URL if triggered at the right time, and get the extension that has initiated the OAuth flow through the identity WebExtensions API to receive the attacker-controlled OAuth tokens (and as a consequence the extension would be tied to the attacker controlled account, and user data exfiltrated when sent through the service account controlled by the attacker).
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Low risk because the fix is a one line change fixing the logic error, no side effect expected besides fixing the issue tracked by this bug.
• String changes made/needed: No
• Is Android affected?: no

Comment 15

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: (secure)

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

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a60437b4b24c
https://hg.mozilla.org/integration/autoland/rev/abd70ef80e40
r=willdurand

Comment 17

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

https://hg.mozilla.org/mozilla-central/rev/abd70ef80e40

Comment 18

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/e7ed19fe810e
https://hg.mozilla.org/releases/mozilla-beta/rev/346465cc0e4b

Comment 19

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/3f50b4261101

Comment 20

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/524e0df6db64