1971140 - (CVE-2025-6430) Ignoring of a Content-Disposition: attachments header leads to XSS flaws

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Zeroday]

Steps to reproduce:

Description:
Product: FireFox
Version: 139.0.1
Researcher: Daniil Satyaev (Positive Technologies)

Research:

1. Upload html/xml/svg file on website.
2. Return it as downloadable file

Content-Type: text/html
Content-Disposition: attachment; filename=test

<script>alert(1)</script>

3. Open it from another page using <object> or <embed> HTML tags.

<embed src=”CD_header_ignored_here”/>
<object data=”CD_header_ignored_here”></object>

Actual results:

Websites often allow users to upload their own content and return it as a downloadable file using the HTTP header Content-Disposition: attachment. Its i well known feature to avoid XSS. I've found that if a page is opened using <embed> or <object>, the Content-Disposition header is ignored, and the files are displayed instead of being downloaded.

Expected results:

Browser will download files. Latest Content-Disposition: attachment XSS issue was widely used with Safari on iOS. This issue patched more then 7 years ago.

Comment 1

[Zeroday]

Hello Team,

Researcher of Positive Technologies have discovered vulnerability in Firefox.

We plan to release a database update for its products and a publication about the discovered vulnerability within the next 90 days from the date of sending this message, so please answer the following questions:

1. When and in what version will you fix the vulnerabilities described in our Report? (date, version)
2. If it is not possible to release a patch in the next 90 days, then please indicate the expected release date of the patch (month).
3. We ask you to provide the CVE-ID for the vulnerability that we submitted to you.

Our coordinated vulnerability disclosure policy - https://global.ptsecurity.com/policies/positive-coordinated-vulnerability-disclosure-policy

Thank you!

Comment 2

[:Gijs (he/him)]

Nika, based on bug 1868001 I'm hoping you know what is going on here.

Comment 3

[Nika Layzell [:nika] (ni? for response)]

As noted in bug 1868001, for at least PDF and image loads, browsers do ignore Content-Disposition: attachment when loading those documents into an object/embed element. Unfortunately it looks like I messed up pretty badly when writing that patch, as I didn't consider the case where a HTML document is loaded in an object/embed element, which it appears should not have been changed to ignore Content-Disposition: attachment.

The post author is correct that in Chrome and Safari, as well as older versions of Firefox, the document hosted with Content-Disposition: attachment would not have been loaded. Interestingly, other browsers appear to also do this for a text/plain document.

I haven't done enough testing to be 100% sure, but I believe the mistake I made was forgetting about some old specifics of how object/embed elements work. Specifically, it used to be that image, and addon loads were handled separately and would bypass Content-Disposition: attachment, and other things handled internally would not. Nowadays everything is handled in the "handled internally" codepath (due to us using PDF.js for PDFs, and image documents for images), which led to me making this mistake.

I think the simplest fix here might be to add a conservative MIME-type allow-list for cases where the load can ignore Content-Disposition: attachment.

Comment 4

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1971140 - Improve Content-Disposition: attachment handling for object/embed, r=smaug!

Comment 5

[Nika Layzell [:nika] (ni? for response)]

Comment on attachment 9493680 [details]
Bug 1971140 - Improve Content-Disposition: attachment handling for object/embed, r=smaug!

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Exploiting this bug would require a website to allow hosting arbitrary untrusted content with a text/html MIME type, by depending on Content-Disposition: attachment header to prevent the HTML from being loaded in a browser.

I tried to make it not immediately obvious what the problem was in this patch, but if someone looked closely they could probably figure it out, and it would unfortunately be pretty straightforward to exploit and get XSS on a target site which meets the above criteria.

• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Yes
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: esr128+
• If not all supported branches, which bug introduced the flaw?: Bug 1868001
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: I expect that this patch should fairly cleanly apply to all affected branches, though I have not tested.
• How likely is this patch to cause regressions; how much testing does it need?: I have not done a try push with this, so there may be other breakage which I am not aware of.

This patch change behaviour for the somewhat-infrequently-used object/embed element. Historically we have broken this element's behaviour (especially in this edge case) a few times, and generally haven't gotten bug reports for the breakage until the change made it to release.

I would unfortunately not be too surprised if the new behaviour isn't perfect, and we need to do follow-up fixes, but the new state should be more secure.

• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 6

[Andrew McCreight [:mccr8]]

I guess we mark these kinds of "website security bypasses" as sec-moderate?

Comment 7

[Tom Ritter [:tjr]]

Comment on attachment 9493680 [details]
Bug 1971140 - Improve Content-Disposition: attachment handling for object/embed, r=smaug!

Approved to land. It sounds like unless we know of a specific vulnerable site we could let this ride the trains?

Comment 8

[Nika Layzell [:nika] (ni? for response)]

(In reply to Tom Ritter [:tjr] from comment #7)

Comment on attachment 9493680 [details]
Bug 1971140 - Improve Content-Disposition: attachment handling for object/embed, r=smaug!

Approved to land. It sounds like unless we know of a specific vulnerable site we could let this ride the trains?

Yeah, I'm not currently aware of a vulnerable site, but I'm a bit anxious there is one, and we just won't learn about it, as it's relatively small/unmaintained.

Most sites seem to do some other form of defence, such as also serving X-Frame-Options headers (e.g. googlesource.com), or loading the content from a separate domain (e.g. githubusercontent.com). Not sure how common just depending on Content-Disposition is.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/283226060d9e
https://hg.mozilla.org/integration/autoland/rev/9ac2e2fd7c07
Improve Content-Disposition: attachment handling for object/embed, r=smaug

Comment 10

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

https://hg.mozilla.org/mozilla-central/rev/9ac2e2fd7c07

Comment 11

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

The patch landed in nightly and beta is affected.
:nika, 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 12

[Nika Layzell [:nika] (ni? for response)]

Comment on attachment 9493680 [details]
Bug 1971140 - Improve Content-Disposition: attachment handling for object/embed, r=smaug!

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Could be a source for XSS attacks on some sites, though no potential targets are currently known.
• User impact if declined: Could be a source for XSS attacks on some sites, though no potential targets are currently known.
• Fix Landed on Version: 141
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Change impacts fairly well-understood components in a way which should only lock them down more.
  That being said, changes to object/embed always carry a risk due to them generally being used on less-well-updated sites.

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Could be a source for XSS attacks on some sites, though no potential targets are currently known.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Change impacts fairly well-understood components in a way which should only lock them down more.
  That being said, changes to object/embed always carry a risk due to them generally being used on less-well-updated sites.
• String changes made/needed: none
• Is Android affected?: Yes

Comment 13

[Nika Layzell [:nika] (ni? for response)]

Comment on attachment 9493680 [details]
Bug 1971140 - Improve Content-Disposition: attachment handling for object/embed, r=smaug!

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: See comment 12
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment 12
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): See comment 12
• String changes made/needed:
• Is Android affected?: Yes

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: See comment 12
• User impact if declined: See comment 12
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): See comment 12

Comment 14

[Donal Meehan [:dmeehan]]

Comment on attachment 9493680 [details]
Bug 1971140 - Improve Content-Disposition: attachment handling for object/embed, r=smaug!

Approved for 140.0b9

Comment 15

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/7bfb0e8915f9
https://hg.mozilla.org/releases/mozilla-beta/rev/bc10ee75455f

Comment 16

[Donal Meehan [:dmeehan]]

:nika, this doesn't apply cleanly to ESR128. Could you provide a rebased patch?

Comment 17

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1971140 - (ESR) Improve Content-Disposition: attachment handling for object/embed

Comment 18

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/71840e2d895c

Comment 19

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/a98c75577356

Comment 20

[Zeroday]

Hello Team,

Could you please clarify when you plan to release a patch for this vulnerability? If additional information is required, please let me know.

I would also appreciate it if you could inform me about your plans regarding CVE-ID registration.

Thank you.

Best regards,
Diana

Comment 21

[Andrew McCreight [:mccr8]]

The tag [adv-main140+] means there will be an advisory for this issue released alongside Firefox 140, which is being released on June 24. I'd expect there will be a CVE assigned to this bug at some point before that.

Comment 22

[Tom Ritter [:tjr]]

Attachment: advisory.txt

Comment 23

[Giorgio Maone [:ma1]]

Related/conflicting: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42220

Comment 24

[Giorgio Maone [:ma1]]

Tor's take on mitigating both unwanted downloads and XSS risks (WIP): https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/43211

Comment 25

[Zeroday]

Hello,
Could you please clarify why firefox139 has a status of wontfix?
Our researcher has tested the exploitation of the vulnerability on firefox139 - successfully. Below is a screenshot confirming the exploitation of the vulnerability:

Comment 26

[Zeroday]

Attachment: test-demo-xss-for-v139.0.1.jpg

Comment 27

[Andrew McCreight [:mccr8]]

(In reply to Zeroday from comment #25)

Could you please clarify why firefox139 has a status of wontfix?
Our researcher has tested the exploitation of the vulnerability on firefox139 - successfully. Below is a screenshot confirming the exploitation of the vulnerability:

Firefox 140 is being released tomorrow. We don't update old versions indefinitely. 139 is marked "wontfix" and not "unaffected" because we realize it is affected, but we aren't going to fix an old version we aren't releasing new updates for.

Comment 28

[Zeroday]

Hello!

Thank you for resolving the vulnerability.

I'd like to ask another question and would appreciate a comment.

Is this research (XSS) eligible for a bounty? Or does this vulnerability fall outside the scope of the bug bounty program?

Thanks.

Comment 29

[:Gijs (he/him)]

(In reply to Zeroday from comment #28)

Is this research (XSS) eligible for a bounty? Or does this vulnerability fall outside the scope of the bug bounty program?

I've set the bounty request flag for you.

Comment 30

[Zeroday]

Hello,

I would like to inform you that our team has prepared a draft press release regarding the identified vulnerability (attached for your review). The publication is scheduled for August 29, 2025. We would appreciate your feedback within the specified timeline.

Thank you for your cooperation.

Comment 31

[Zeroday]

Attachment: Mozilla Patches Vulnerability in Firefox Browser Discovered by Positive Technologies Expert.pdf

Comment 32

[Andrew McCreight [:mccr8]]

(In reply to Zeroday from comment #30)

Hello,

I would like to inform you that our team has prepared a draft press release regarding the identified vulnerability (attached for your review). The publication is scheduled for August 29, 2025. We would appreciate your feedback within the specified timeline.

This request for feedback is more likely to be seen if you email about it to [e-mail]

Comment 33

[Daniel Veditz [:dveditz] back 2026-04-08]

Thanks for the notice. My main concern is the line...

To prevent dangerous consequences, it is necessary to update Firefox to version 140.0 and Firefox ESR
to version 128.12 as soon as possible

... since those are not the most recent versions. If you don't mind, please edit that to "... update Firefox to version 140.0 or higher and Firefox ESR to version 128.12 or higher ... " or some equivalent that you prefer.

At the top the "Firefox ESR" link uses the wrong CVE anchor (-6424 instead of -6430) which may confuse people. The "Firefox" link is to the base mfsa2025-51 advisory page which is not wrong, but people will have to scroll a lot and look for your name to find the right entry. You probably want to update both links to use #CVE-2025-6430.

Comment 34

[Zeroday]

Hello,
Thank you for your prompt feedback.

We will incorporate your suggestions into the news publication.

The article will be published here: https://global.ptsecurity.com/en/about/news/.

Should you require any further adjustments, please let us know at your earliest convenience.