1965056 - Cache re-validation request includes duplicated cookies

Status: RESOLVED FIXED

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

Description

[Oleg Zasypkin [:azasypkin]]

Attachment: server_and_demo.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:138.0) Gecko/20100101 Firefox/138.0

Steps to reproduce:

Our web application (Kibana) relies on cookie-based authentication. Certain user activity causes the application to send XHR requests to various server endpoints, and if the session is still valid, it's being extended and the cookie is updated. The response includes a Set-Cookie header with the updated cookie.

We also have some endpoints that leverage HTTP cache (large and expensive to generate responses) with max-age and stale-while-revalidate directives. As a result, responses for such endpoints include both cookie and cache-related headers that look like this: "Set-Cookie": "sid=xxxx; HttpOnly" and "Cache-Control": "private, max-age=5, stale-while-revalidate=31535995".

Since recently (new FF release?), we started receiving complaints about unexpected logouts. After debugging, we figured out that for some reason, Firefox started sending duplicated identical cookies to the endpoints that both refresh the cookie and use HTTP cache. We don't see this behavior in older Firefox versions (MacOS, 137.0.1) or any other browsers. I can reproduce this on the latest Nightly as well (MacOS, 140.0a1 (2025-05-07) (aarch64)). It does feel like a bug to me.

In the attachment, you can find an archive with a simple Node.js HTTP server (once run with node index.js the server will be available at http://localhost:3000/) and a demo video that demonstrate the problem.

It probably can be considered a security-related bug, but I'm not sure, so feel free to make it private.

Actual results:

Firefox sends 2 identical cookies with cache re-validation request.

Expected results:

Firefox shouldn't send duplicated cookies.

Comment 1

[Kershaw Chang [:kershaw]]

Could you try to use mozregression to help us figure out the regression range?
Thanks.

Comment 2

[sidmantri1]

Ran mozregression with the our scenario in kibana.

Pushlog URL generated by mozregression: https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=d4371465982dfa17147909c585a516b7389e0751&tochange=4bbc39703afd169d2a2ff8f052faf2a95bd5f46d

Last known good build: 137
First known bad build: 138

Comment 3

[Oleg Zasypkin [:azasypkin]]

@kershaw, I had a chance to run mozgregression on the mozilla-central/autoland earlier today to further narrow the range:

Push Log: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9ce0a2fa61cd134889e17bdec652767813afce16&tochange=2993c64682bd621e8a0479c1176561bf3a1bd523

And the tool points to this commit, which indeed sounds relevant: https://phabricator.services.mozilla.com/D239726 and https://bugzilla.mozilla.org/show_bug.cgi?id=1893842 (Bug 1893842 - background validation requests should include headers from original requests. r=necko-reviewers,valentin).

Tagging the author to confirm/deny the guess.

Comment 4

[Sunil Mayya]

This is indeed a regression from 1893842

Comment 5

[Oleg Zasypkin [:azasypkin]]

Hey @edgul, I see the bug was triaged as P2 - can you please give us a sense of when (approx.) or what Firefox version the fix will be available in? Unfortunately, we have quite a few Firefox users using older versions of our product (Kibana) that they cannot upgrade to get the temporary workaround from us and will have to wait until the fix is released in Firefox.

Until then, we have to ask them to either switch to a different browser or fully disable Firefox cache (via browser.cache.disk.enable: false and browser.cache.memory.enable) since the product is basically unusable (users are logged out) due to how we handle invalid cookie headers. If there is no way you can address the regression in the current release cycle, do you have any less brutal workarounds we can recommend our users?

Comment 6

[edgul]

I'll defer to Sunil, who is currently assigned to the bug

Comment 7

[Oleg Zasypkin [:azasypkin]]

I'll defer to Sunil, who is currently assigned to the bug

Hey @smayya,

Any chance you can help with https://bugzilla.mozilla.org/show_bug.cgi?id=1965056#c5?

Thanks!

Comment 8

[Sunil Mayya]

Hello Oleg,
Sorry for the delay.
I havent fixed it, will start working on it in the next two weeks.
The fix will be available in version 141/142 version.

Comment 9

[Sunil Mayya]

Oleg, please check if the workaround mentioned in this comment -> https://bugzilla.mozilla.org/show_bug.cgi?id=1967522#c2, helps you.

Comment 11

[Oleg Zasypkin [:azasypkin]]

Oleg, please check if the workaround mentioned in this comment -> https://bugzilla.mozilla.org/show_bug.cgi?id=1967522#c2, helps you.

Thanks for the link. Using a custom browser extension as a workaround might work for some people, but would be quite complicated for the general public. It sounds like we'll have to wait for the proper fix. Until then, we added a workaround for this Firefox behavior in our product (https://github.com/elastic/kibana/pull/220430) that would at least help those who can upgrade.

Comment 12

[Pascal Chevrel (relman team) -> :pascalc]

(In reply to Sunil Mayya from comment #4)

This is indeed a regression from 1893842

If it's a regression, that needs tracking for regression triage

Comment 13

[Pascal Chevrel (relman team) -> :pascalc]

This is a confirmed bug, setting as NEW.
It breaks Kibana, an Elastic Search product frequently deployed in corporate settings, adding the enterprise keyword.
Not a macOS bug but affects all platforms.
Tracking for our affected branches as we already have a dupe and there are also several issues filed about it on the Kibana repo.

Comment 14

[Pascal Chevrel (relman team) -> :pascalc]

(In reply to Sunil Mayya from comment #8)

Hello Oleg,
Sorry for the delay.
I havent fixed it, will start working on it in the next two weeks.
The fix will be available in version 141/142 version.

Sunil, we are in our last week of the 141 beta cycle, do you have an update on this bug? Thanks

Comment 15

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

The bug is marked as tracked for firefox141 (beta) and tracked for firefox142 (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 16

[Sunil Mayya]

(In reply to Pascal Chevrel:pascalc from comment #14)

(In reply to Sunil Mayya from comment #8)

Hello Oleg,
Sorry for the delay.
I havent fixed it, will start working on it in the next two weeks.
The fix will be available in version 141/142 version.

Sunil, we are in our last week of the 141 beta cycle, do you have an update on this bug? Thanks

The fix isn’t ready yet, and I don’t think we’ll be able to complete it this week. I’ll prioritize it and aim to wrap it up by the end of next week.

Comment 17

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

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

Comment 18

[Sunil Mayya]

Attachment: Bug 1965056 - for stale revalidating channel do not copy cookies. r=#necko

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/65d9f285b126
https://hg.mozilla.org/integration/autoland/rev/5d843f8a8ad6
for stale revalidating channel do not copy cookies. r=necko-reviewers,valentin

Comment 20

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/5d843f8a8ad6

Comment 21

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

The patch landed in nightly and beta is affected.
:smayya, 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-firefox142 to wontfix.

For more information, please visit BugBot documentation.

Comment 22

[Sunil Mayya]

Hello Oleg,
This has been fixed. Feel free to test this in latest nightly to confirm and remove the workaround.
Pleaser let us know if you have more issues?

Comment 23

[Oleg Zasypkin [:azasypkin]]

I can confirm it works properly in the current Nightly (144.0a1, 2025-08-19) for me. Thanks for the fix, Sunil!

Comment 24

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for ESR140 uplift when you get a chance.

Comment 25

[Sunil Mayya]

Comment on attachment 9505689 [details]
Bug 1965056 - for stale revalidating channel do not copy cookies. r=#necko

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This effects enterprise networks as it breaks kibana.
• User impact if declined: Authentication will break
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It modifies code path of cache revalidation with cookies. Hence, the impact scope is relatively small.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9505689 [details]
Bug 1965056 - for stale revalidating channel do not copy cookies. r=#necko

Approved for 140.3esr.

Comment 27

[Pulsebot]

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