1965430 - (CVE-2026-8950) Form POST requests do not set Origin header to null after redirect

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P2)

Description

[Jakub Szymsza]

Attachment: exploit.zip

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36

Steps to reproduce:

If a POST form is submitted from origin A to origin B, and the endpoint at origin B uses a 307 redirect to a cross-origin URL C, the Origin header should be set to null. However, URL C receives the Origin header with the value A.

This is similar to the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1649888 with the difference that the bug was about using fetch to request a CORS-enabled server (in which case the Origin header does get correctly erased), whereas the bug I discovered concerns a submitted form.

The security impact is limited, since it only impacts scenarios where A submits a form to malicious B, C validates the Origin header and trusts the A origin, and the simple form request can trigger a CSRF. Nonetheless, the behavior is incorrect, and there could be edge case scenarios where this can lead to an exploit.

To reproduce the issue, go to https://szymsza.cz/exploit/form.html (or see the attached proof of concept) and click on Submit form.

1. szymsza.cz submits a POST form to szymsza.com
2. szymsza.com does a 307 redirect to szymsza.eu
3. szymsza.eu prints out the Origin header it received

Actual results:

Firefox outputs "Received Origin: https://szymsza.cz"

The bug seems to have been present since version 70, when the Origin header was introduced for POST requests, until the latest version

Expected results:

Chromium-based browsers and Safari correctly output "Received Origin: null"

Comment 1

[Kershaw Chang [:kershaw]]

The problem seems to be around here:

  if (IsNewChannelSameOrigin(aNewChannel)) {
    return false;
  }

IsNewChannelSameOrigin returns false to indicate this is a cross origin redirect. However, we ignore the result and use the result from CheckSameOriginURI(mOriginalURI, mURI, false, false) instead.

Sunil, since you touched this code in bug 1817980, could you take a look?
Thanks.

Comment 2

[Daniel Veditz [:dveditz]]

This sounds exactly like the original example in bug 1535795 which was supposedly fixed in bug 1605305, but I don't see anyone say they verified the original testcase was fixed. Also there were several regressions from bug 1605305 so it's possible one of those fixes un-fixed the security bug.

Comment 3

[Sunil Mayya]

Attachment: (secure)

The condition for checking if a new channel is same-origin was inverted.
When the new channel is NOT same-origin to the redirecting channel,
we should taint the origin, not the other way around.

Comment 4

[Sunil Mayya]

Tom, I see that we have added the test cases covering the described scenario here https://phabricator.services.mozilla.com/D147091#change-26UMaFyrwp9M, we expect the origin to be sent for cross-origin redirects. I think these cases need to be updated to ensure that we send null origin header for cross-origin redirects?

Comment 5

[Tom Schuster [PTO]]

I at first glance, I don't think so. Cross-origin URLs should only really be turned to null with a "same-origin" referrer policy, which this doesn't seem to be.

As far as I can tell Chrome also sends the Origin in this case.
Edit: Not sure what I was looking at, but Chrome sends null.

Comment 6

[Tom Schuster [PTO]]

Yes, we should be censoring the Origin for cross-origin redirects, even without the "same-origin" referrer policy. So updating the tests is okay.

The reason for this how serializing a request origin works, which is called (indirectly) by append a request Origin header. Thanks Sunil for pointing me in the right direction, I had totally forgotten that part of this censoring happens there.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/9af8d1dbbfa8
https://hg.mozilla.org/integration/autoland/rev/93d685616997
Update ShouldTaintReplacementChannelOrigin. r=tschuster

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/eae8f8fda0fc
https://hg.mozilla.org/integration/autoland/rev/9cc3b8e1e2ad
Revert "Bug 1965430 - Update ShouldTaintReplacementChannelOrigin. r=tschuster" for causing failures @audioworklet.https.sub.html.

Comment 9

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

Backed out for causing wpt failures @audioworklet.https.sub.html.

• Backout link
• Push with failures
• Failure Log

Comment 10

[BugBot [:suhaib / :marco]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 11

[BugBot [:suhaib / :marco]]

The bug is marked as tracked for firefox148 (beta) and tracked for firefox149 (nightly). However, the bug still has low severity.

:ghess, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 12

[Donal Meehan [:dmeehan]]

Received confirmation this won't be fixed for Fx148

Comment 13

[Sunil Mayya]

(In reply to Tom Schuster from comment #6)

Yes, we should be censoring the Origin for cross-origin redirects, even without the "same-origin" referrer policy. So updating the tests is okay.

The reason for this how serializing a request origin works, which is called (indirectly) by append a request Origin header. Thanks Sunil for pointing me in the right direction, I had totally forgotten that part of this censoring happens there.

I checked again. The tests were actually correct in their expectations. The point that we missed what the origin must NOT be tainted if the redirecting page and the page page that initiated the request are same (even if its a cross-origin redirect).

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/fe8b5c724a20
https://hg.mozilla.org/integration/autoland/rev/30415b4af306
Update ShouldTaintReplacementChannelOrigin. r=tschuster

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/2bb8897a439e
https://hg.mozilla.org/integration/autoland/rev/8339afaf0a6b
Revert "Bug 1965430 - Update ShouldTaintReplacementChannelOrigin. r=tschuster" for causing failures at test_origin_header_redirect.html

Comment 16

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

• Push with failures
• Failure log

TEST-UNEXPECTED-TIMEOUT | netwerk/test/mochitests/test_origin_header_redirect.html | application timed out after 370.0 seconds with no output

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/f9fa8fb43924
https://hg.mozilla.org/integration/autoland/rev/c8c850c20a82
Update ShouldTaintReplacementChannelOrigin. r=tschuster

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/98f4baff42a4
https://hg.mozilla.org/integration/autoland/rev/9a64aadd3871
Revert "Bug 1965430 - Update ShouldTaintReplacementChannelOrigin. r=tschuster" for causing mochitest crashes @ test_origin_header_redirect.html

Comment 19

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

• Push with failures
• Failure log

[task 2026-04-14T21:03:37.507+00:00] 21:03:37     INFO - TEST-START | netwerk/test/mochitests/test_origin_header_redirect.html
[task 2026-04-14T21:10:01.590+00:00] 21:10:01     INFO - wait for org.mozilla.geckoview.test_runner complete; top activity=org.mozilla.geckoview.test_runner
[task 2026-04-14T21:10:01.590+00:00] 21:10:01     INFO - org.mozilla.geckoview.test_runner unexpectedly found running. Killing...
[task 2026-04-14T21:10:15.016+00:00] 21:10:15    ERROR - TEST-UNEXPECTED-FAIL | netwerk/test/mochitests/test_origin_header_redirect.html | application timed out after 370 seconds with no output

Comment 20

[Sunil Mayya]

Looks like the linter was changing the url to use https instead of http - http://test1.mochi.test:8888. Added eslint disable

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/01b4d66f66b3
https://hg.mozilla.org/integration/autoland/rev/31e8ea2ffb56
Update ShouldTaintReplacementChannelOrigin.r=tschuster

Comment 22

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

https://hg.mozilla.org/mozilla-central/rev/31e8ea2ffb56

Comment 23

[Donal Meehan [:dmeehan]]

Please add uplift requests for esr140

Comment 24

[Sunil Mayya]

Attachment: (secure)

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

Comment 25

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined/Reason for urgency: This is a security vulnerability, where we might leak the origin info to a third-party site.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: medium
• Explanation of risk level: With this change we will taint origin header for cross-origin redirects for requests. This is the existing behavior for fetch and xhr but was missed for http. There is medium risk to uplift as there might be some edge cases that we might have missed and might encounter them when we deploy this fix.
• String changes made/needed?: No
• Is Android affected?: yes

Comment 26

[Sunil Mayya]

Uplifted request submitted https://lando.moz.tools/uplift/jobs/2039/

Comment 27

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/a8716004c2be