1981502 - (CVE-2025-10536) Cache-Control: no-store does not prevent disk cache entry when multiple headers are sent

Status: VERIFIED FIXED

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

Description

[Ibuki Sato]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36

Steps to reproduce:

1.Start a local HTTP server using the attached server.py (Flask).

2.Navigate to http://localhost:8082/test7 in Firefox.

3.This endpoint responds with three separate Cache-Control headers:

・Cache-Control: no-store
・Cache-Control: public
・Cache-Control: no-cache

4.Open about:cache.

5.Observe that an entry for /test7 appears in the disk cache.

6.This occurs despite no-store being present.

7.The response also includes a Set-Cookie: sessionid=test_token header.

firefox 141.0.2(64bit) Windows 11
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:141.0) Gecko/20100101 Firefox/141.0

Actual results:

Firefox appears to honor only the last Cache-Control header.

If no-cache follows no-store, no-store is ignored.

The response ends up being cached.

The cache entry persists across browser restarts.

Expected results:

According to [RFC 9111 (Section 5.2.2.5)]the no-store directive prohibits intentional storage in non-volatile storage (e.g., disk), and instructs caches to make a best-effort attempt to avoid retaining the information even in volatile memory (e.g., RAM).

Thus, when a server sends Cache-Control: no-store, the browser:

• MUST NOT store the response in disk cache (non-volatile).
• SHOULD avoid memory caching, or at least remove the response from memory promptly.
• MUST correctly process multiple Cache-Control headers and not ignore no-store even when combined with other directives.

Therefore, when multiple Cache-Control headers are present (e.g., no-store and no-cache), the browser should combine them appropriately and enforce the most restrictive directive — which is no-store in this case.

Even when multiple Cache-Control headers are sent separately, the browser should merge them and respect the most restrictive directive, i.e., no-store.

Comment 1

[Ibuki Sato]

Attachment: disk_cache

Comment 2

[Ibuki Sato]

Attachment: disk_cache_test7

Comment 3

[Ibuki Sato]

Attachment: server.py

Comment 4

[Kershaw Chang [:kershaw]]

I believe this behavior is by design.
Regardless of whether the header includes no-store or no-cache, Firefox may still write the data to the cache, but it won’t use the cached data when those directives are present.

Valentin, please correct me if I’m wrong. Thanks.

Comment 5

[Valentin Gosu [:valentin]]

Attachment: (secure)

nsHttpResponseHead::ParseHeaderLine_locked parses each header as it comes in.
It then updates its own member variables based on that header.
For cache-control, it's important to reparse the merged version of the header
instead of the most recent one, otherwise we'll miss directives present in
previous headers.

Comment 6

[Valentin Gosu [:valentin]]

Actually, if no-store is present we should not save the cache entry to disk (memory is fine).
We don't end up using it later though, but the fact that we save it to disk is still slightly problematic for privacy.
Not sure if I'd consider this a security issue though.

Comment 7

[Daniel Veditz [:dveditz]]

Regardless of whether the header includes no-store or no-cache, Firefox may still write the data to the cache, but it won’t use the cached data when those directives are present.

That is wrong. no-store was created to be explicit because browsers and middle-boxes were "caching and not using" the no-cache ones. It's used for sensitive data that should never be written to disk or any permanent place

Local file-system disclosure is not super high on our threat model (except in Private Browsing) so the severity is low.

Comment 8

[Valentin Gosu [:valentin]]

https://treeherder.mozilla.org/jobs?repo=try&revision=d51550c0236758a6aa757170df2857f2658c5149

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a664230b4e2d
https://hg.mozilla.org/integration/autoland/rev/e214aeee4733
Parse merged version of cache-control instead of just the latest header r=necko-reviewers,jesup

Comment 10

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

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

Comment 11

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

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

For more information, please visit BugBot documentation.

Comment 12

[Valentin Gosu [:valentin]]

Attachment: (secure)

nsHttpResponseHead::ParseHeaderLine_locked parses each header as it comes in.
It then updates its own member variables based on that header.
For cache-control, it's important to reparse the merged version of the header
instead of the most recent one, otherwise we'll miss directives present in
previous headers.

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

Comment 13

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Cache-control: no-store would not be respected if it followed by other cache-control headers (probably rare in practice)
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Manual testing is optional, but see comment 3 for a test server
• Risk associated with taking this patch: low
• Explanation of risk level: This patch makes sure that the cache control parses the merged header, not just the most recent received cache-control header.
• String changes made/needed: none
• Is Android affected?: yes

Comment 14

[Valentin Gosu [:valentin]]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #11)

:valentin, is this bug important enough to require an uplift?

The impact on users is probably small, but I've requested uplift anyway for corectness.

Comment 15

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/ec56386da36e
https://hg.mozilla.org/releases/mozilla-beta/rev/16b36b1b50cd

Comment 16

[Bogdan Maris, Desktop Test Engineering]

Reproduced the issue described in comment 0 using an old Nightly build from 2025-08-06.
Verified that:

• using latest Nightly 144.0a1 http://localhost:8082/test7 is not even in the list in about:cache?storage=disk
• using latest Beta 143 build from treeherder http://localhost:8082/test7 is listed in about:cache?storage=disk` but it has 0 date in it also there are two other entries (see bellow). The favicon.ico one is the only one displayed in Nightly as well.

http://localhost:8082/test7 | 0 bytes | 0 bytes | 0 | 2025-08-28 16:38:37 | No expiration time

http://localhost:8082/favicon.ico O^partitionKey=%28http%2Clocalhost%29, | 207 bytes | 0 bytes | 1 | 2025-08-28 16:38:09 | Expired Immediately

predictor-origin:http://localhost:8082/ | 0 bytes | 0 bytes | 2 | 2025-08-28 16:38:09 | No expiration time

I verified across platforms (Windows 11, macOS 13 and Ubuntu 22.04).
Not sure if the above entries are to be displayed in the Beta build or not even though except the favico one they have 0 data in it. Nightly only displays the favicon.ico one.

Comment 17

[Valentin Gosu [:valentin]]

The icon entry doesn't matter for this bug.
I think both the predictor and /test7 entry should go away if you set network.predictor.enabled to false
This is already the default for release and was changed to false in Bug 1979415.

Comment 18

[Bogdan Maris, Desktop Test Engineering]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #17)

I think both the predictor and /test7 entry should go away if you set network.predictor.enabled to false
This is already the default for release and was changed to false in Bug 1979415.

Indeed the entries are gone if setting network.predictor.enabled to false, thanks for the extra info.
Closing this as verified fixed for 144 and 143. Will also come back and verify once/if the fix goes into 140esr.

Comment 19

[Valentin Gosu [:valentin]]

Attachment: (secure)

nsHttpResponseHead::ParseHeaderLine_locked parses each header as it comes in.
It then updates its own member variables based on that header.
For cache-control, it's important to reparse the merged version of the header
instead of the most recent one, otherwise we'll miss directives present in
previous headers.

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

Comment 20

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Cache-control: no-store would not be respected if it followed by other cache-control headers (probably rare in practice)
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Manual testing is optional, but see comment 3 for a test server and comment 17 for testing context
• Risk associated with taking this patch: low
• Explanation of risk level: This patch makes sure that the cache control parses the merged header, not just the most recent received cache-control header.
• String changes made/needed: none
• Is Android affected?: yes

Comment 21

[Pulsebot]

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

Comment 22

[Bogdan Maris, Desktop Test Engineering]

Also verified as fixed using latest esr140 build from treeherder across platforms (Windows 11, macOS 13 and Ubuntu 22.04).