Closed Bug 2054384 (CVE-2026-100823) Opened 2 months ago Closed 21 days ago

Download completion notification truncates long filenames from the end, hiding the file extension

Categories

(Firefox for Android :: Downloads, defect)

Firefox 152
All
Android
defect

Tracking

()

RESOLVED FIXED
157 Branch
Tracking Status
firefox157 --- fixed

People

(Reporter: samad1082280, Assigned: giorga)

References

Details

(Keywords: csectype-spoof, reporter-external, sec-low, Whiteboard: [fxdroid][android-core][adv-main157+])

Attachments

(4 files)

Attached video POC.mp4 —

Steps to reproduce:

Summary

When a file with a long name is downloaded, the Android download completion
notification truncates the filename from the end. This causes the file extension
to be completely hidden, making it impossible to identify the file type from the
notification.

Steps to Reproduce

  1. Host a file with a long filename (e.g.,
    "this_is_a_very_long_filename_containing_sample_text_for_the_flask_server.txt")
    on any local or remote HTTP server.
  2. Open Firefox for Android and navigate to the file URL.
  3. Tap the download button and confirm the download dialog.
  4. Observe the Android notification bar after the download completes.

POC

POC video is also attached, POC Code is available below

from flask import Flask, send_file, render_template_string
import io

app = Flask(__name__)

FILENAME = "this_is_a_very_long_filename_containing_sample_text_for_the_flask_server_&_this_is_a_very_long_filename_containing_sample_text_for_the_flask_server.txt"

FILE_CONTENT = """\
Hello, World! This is a sample text file with a very long name.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore
eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt
in culpa qui officia deserunt mollit anim id est laborum.

This file is served by a simple Flask web server.
Visit http://0.0.0.0:5000/ to see this content rendered in the browser.
"""

HTML_TEMPLATE = """
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Text File Server</title>
    <style>
        body { font-family: Arial, sans-serif; max-width: 800px; margin: 60px auto; padding: 0 24px; background: #f5f5f5; }
        .card { background: white; border-radius: 10px; padding: 32px; box-shadow: 0 2px 8px rgba(0,0,0,0.08); }
        h1 { color: #222; margin-top: 0; }
        .filename { background: #f0f0f0; padding: 10px 14px; border-radius: 6px; font-family: monospace; font-size: 13px; word-break: break-all; color: #555; }
        pre { background: #fafafa; border: 1px solid #e0e0e0; padding: 20px; border-radius: 6px; white-space: pre-wrap; line-height: 1.6; }
        .btn { display: inline-block; margin-top: 16px; padding: 12px 24px; background: #0066cc; color: white; text-decoration: none; border-radius: 6px; font-size: 15px; }
        .btn:hover { background: #0052a3; }
    </style>
</head>
<body>
    <div class="card">
        <h1>📄 Text File Server</h1>
        <p><strong>Filename:</strong></p>
        <div class="filename">{{ filename }}</div>
        <h2>Content:</h2>
        <pre>{{ content }}</pre>
        <a class="btn" href="/download">⬇ Download File</a>
    </div>
</body>
</html>
"""

@app.route("/")
def index():
    return render_template_string(HTML_TEMPLATE, filename=FILENAME, content=FILE_CONTENT)

@app.route("/download")
def download():
    return send_file(
        io.BytesIO(FILE_CONTENT.encode("utf-8")),
        as_attachment=True,
        download_name=FILENAME,
        mimetype="text/plain"
    )

if __name__ == "__main__":
    print(f"Server running at http://0.0.0.0:5000/")
    app.run(host="0.0.0.0", debug=True, port=5000)

Suggested Fix

Apply middle-truncation when constructing the notification title, preserving
the file extension suffix — the same strategy Chrome uses.

Actual results:

Actual Result

The notification truncates the filename from the end, completely cutting off
the .txt extension:

this_is_a_very_long_filename_containing_sample_text_for_the_flask_server&_thi...

The word "Download completed" appears below, but no file type is visible.

Expected results:

Expected Result

The notification should show the filename in a way that preserves the file
extension — either by showing the full name, or by truncating from the middle:

this_is_a_very_long_f....txt

Environment Details

152.0.4 (Build #2016169815), e39c605adc0fc049a165d7fe4a3f6517b761edf7
GV: 152.0.4-20260629141727
AS: 152.0.1
OS: Android 16
Device: Xiaomi 15T

Attached image POC - Firefox.png —

POC image of Download Notification of Firefox

Attached image POC - Chrome.jpeg —

POC image of Download Notification of Chrome

Severity: -- → S3
Whiteboard: [fxdroid][group4]

Hi Team,
Any update?

Hi Team,

Apologies for the multiple follow-ups. However, it has been around a month, and I have not yet received any update regarding this bug.

Could you please provide me with an update on the current status and let me know if any further information is required from our side?

Looking forward to your response.

Flags: needinfo?(calu)

Is this something we can work on fixing? I have labelled it as android-core. Feel free to pull it into the JIRA sprint.

Flags: needinfo?(calu) → needinfo?(giorga)
Whiteboard: [fxdroid][group4] → [fxdroid][android-core]
Assignee: nobody → giorga
Flags: needinfo?(giorga)
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Pushed by giorga@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/37969182a870 https://hg.mozilla.org/integration/autoland/rev/d8de459a2e39 Download notifications should truncate long filenames in the middle. r=android-reviewers,tthibaud
Status: ASSIGNED → RESOLVED
Closed: 27 days ago
Resolution: --- → FIXED
Target Milestone: --- → 157 Branch

Hi, could you please provide an update on the bounty review/status for this report? The issue has been fixed and closed, but I haven’t received any information regarding bounty eligibility or evaluation. Thank you!

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Hey thanks for the follow ups, can you elaborate what you mean by the bounty review/status? This should be landed and fixed in version 157.

Flags: needinfo?(calu)

Thanks for clarifying. By bounty review/status, I mean whether this report qualifies for a bounty payment to the researcher under Mozilla’s Client Bug Bounty Program, as Mozilla provides bounty amounts for eligible security vulnerabilities reported by researchers.

I just wanted to confirm whether Bug 2054384 has been reviewed for bounty eligibility and whether any bounty payment will be awarded for this report. Thanks!

This bug is now flagged for consideration. We are processing a backlog of bounty requests, but it is in the queue and updates will be communicated via email. Bugzilla should not be used for followups.

Flags: sec-bounty?

Thanks. Team.

I will do follow up on Emails
You can mark this as fixed, as the vulnerability no longer exist.

Flags: needinfo?(giorga)
Status: REOPENED → RESOLVED
Closed: 27 days ago → 21 days ago
Resolution: --- → FIXED

(In reply to Abdul Samad from comment #12)

Hi, could you please provide an update on the bounty review/status for this report? The issue has been fixed and closed, but I haven’t received any information regarding bounty eligibility or evaluation. Thank you!

You have not received any information about the bounty status because you did not submit this bug to the bounty program. It wasn't even filed as a security bug, so neither the bug bounty team nor the security team knew anything about this bug until Tom noticed and flagged it in comment 18.

You should go to https://www.mozilla.org/security/ and read the rules and instructions for our bounty program.

Thank you for clarifying this and for pointing me to the bounty guidelines. I understand now that the report was not originally submitted through the bounty program and that it was identified as a security issue later in the discussion.

Could you please advise me on the appropriate way to request an update regarding the bounty status of this bug?

Should I contact security@mozilla.org directly? If so, is there an expected time-frame for receiving a response?

Alternatively, should I ask about the bounty status here, or would it be more appropriate to submit the issue through the bounty submission form at https://bugzilla.mozilla.org/form.client.bounty, including all the details from my previous report and mentioning that the issue has already been fixed and closed?

I just want to make sure I follow the correct process from now on before taking any further action.

Thank you for your guidance.

Also, could you kindly let me know whether I am allowed to disclose this issue publicly now that it has been fixed and closed, or if I should wait for any further confirmation from Mozilla?

Should I contact security@mozilla.org directly? If so, is there an expected time-frame for receiving a response?

I linked to the page where you can find our policy, where exactly this question is answered.

Flags: needinfo?(calu)
Duplicate of this bug: 2070661
See Also: → 1948536
Flags: needinfo?(dveditz)

I believe [this and bug 1948536] are different UI components and different manifestations of the issue

If we thought they were the same we would have made one a duplicate of the other. "See Also" is the most nebulous of relations

Also, could you please let me know ...

Tom added the sec-bounty? flag to the bug: it will be considered. Beyond that developers don't know the answers so please stop asking in the bugs. There's an address in the bounty program documents where you can ask question of the security team.

Flags: needinfo?(dveditz)
Whiteboard: [fxdroid][android-core] → [fxdroid][android-core][adv-main157+]
Alias: CVE-2026-100823
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: