Clickjacking vulnerability in Mozilla Firefox (CVE-2026-12322)

CVE-2026-12322 · Mozilla Foundation Security Advisory MFSA 2026-57

During independent security research, one of our penetration testers at Sawah Cyber Security discovered a clickjacking (UI redress) vulnerability in the file picker of Mozilla Firefox on Linux. The issue was reported to Mozilla through coordinated disclosure, assigned CVE-2026-12322, and fixed in Firefox 152, released on 16 June 2026. Mozilla rated the issue as low severity.

Mozilla Firefox is one of the most widely used web browsers, with a substantial install base on Linux desktops. On Linux, Firefox renders its file selection dialog using the GTK toolkit. This research concerns the behaviour of that dialog when a web page opens it programmatically.

After being notified, Mozilla released a security update (Firefox 152) to address the finding. This post documents the root cause and the process used to confirm it. It intentionally omits any working exploitation code.

Background

On Linux, Firefox has two file-picker code paths:

• A portal path (xdg-desktop-portal over DBus), used on modern desktop environments, which runs the dialog out of process.
• A legacy GTK path (OpenNonPortal), used on older GTK setups or when the portal is explicitly disabled.

This vulnerability affects the legacy GTK path only. Part of the analysis below is dedicated to proving that this path — rather than the portal — was the one actually exercised.

Vulnerability description

When a web page opens a file picker through <input type="file">, the expected interaction is that the user deliberately selects a file and clicks Open. The click is the user's intent.

This issue removes that intent. If the user is holding the Enter key at the moment the dialog appears, the dialog confirms itself immediately — with no click and no deliberate selection. The web page then receives a result from a dialog the user never intended to confirm.

This is why the issue is best characterised as clickjacking / UI redress, consistent with Mozilla's classification: a page is able to obtain a confirmation the user did not intend to provide. Whatever the picker returns becomes available to the page; in the worst case that includes a file's name, size, MIME type and contents via the standard FileReader API. The core of the issue, however, is the unintended confirmation rather than the file read itself.

Confirming the vulnerable code path

Our penetration tester reproduced and traced the behaviour using a Firefox ASAN-optimised build. The standard release build is fully stripped of debug symbols, which makes meaningful breakpoints impossible under a debugger; the ASAN-optimised build (compiled with -O2) is stable enough to run while retaining sufficient symbol information for GDB to resolve function names. Mozilla's fuzzfetch was used to obtain the build:

pip install fuzzfetch
python3 -m fuzzfetch --asan --opt -n firefox-asan-opt

Firefox was then launched under GDB with debuginfod enabled (so source line numbers resolve) and the content sandbox disabled (so breakpoints in the parent process remain reachable across Firefox's multi-process architecture):

(gdb) set debuginfod enabled on
(gdb) set environment MOZ_DISABLE_CONTENT_SANDBOX=1
(gdb) break nsFilePicker::Open
(gdb) break nsFilePicker::OpenNonPortal
(gdb) run

GDB initially reports these breakpoints as pending, which is expected — libxul.so has not yet been loaded. The breakpoints resolve automatically once the library is loaded.

A local test page was used to open the file picker the instant Enter was pressed, while the key was being held. Execution halted in the picker code, and the backtrace confirmed the path:

#0  Open ()              widget/gtk/nsFilePicker.cpp:[line]   <- root cause
#1  RecvOpen ()          dom/ipc/FilePickerParent.cpp:312     <- IPC handler
#2  OnMessageReceived () ipc/ipdl/PFilePickerParent.cpp:317
#3  OnMessageReceived () ipc/ipdl/PContentParent.cpp:6656
#4  DispatchAsyncMessage() ipc/glue/MessageChannel.cpp:1798   <- IPC dispatch
...

Two observations confirm the vulnerable path:

• OpenNonPortal is present in the stack — Firefox is using the legacy GTK picker, not the DBus portal.
• FinishOpeningPortal is absent — had the portal been active, that function would appear in the stack. Its absence confirms the unpatched GTK path.

The IPC chain (RecvOpen → OnMessageReceived → DispatchAsyncMessage) reflects normal Firefox architecture: the renderer process has no direct filesystem access, so the request is routed over IPC to the privileged parent process, which opens the dialog. This is by design and is not part of the vulnerability.

Root cause

The cause is a single GTK call within nsFilePicker::Open() in widget/gtk/nsFilePicker.cpp:

if (GTK_IS_DIALOG(file_chooser)) {
    gtk_dialog_set_default_response(GTK_DIALOG(file_chooser),
                                    GTK_RESPONSE_ACCEPT);
}

gtk_dialog_set_default_response() designates the dialog's default widget — the one activated when Enter is pressed — and here it is set to GTK_RESPONSE_ACCEPT. GTK's documented behaviour is that pressing Enter activates the default widget, with no delay and no focus check. As a result, an Enter keypress that was already being held when the dialog opened is consumed by the new dialog and immediately fires ACCEPT, confirming it without user intent.

Risk Analysis

CVSS v4.0 base score assessed by Sawah Cyber Security. Mozilla rated the issue low severity (MFSA 2026-57).

An attacker would need to lure someone running Firefox’s older Linux (non-portal) file picker to a malicious web page, then rely on that person holding the Enter key at the exact moment the page silently opens a file dialog. A file dialog normally waits for a deliberate click; here the held Enter key confirms it on its own, with no click and no choice by the user.

If that happens, the page receives a file the user never chose to share and can read it through the browser’s standard file-reading feature (FileReader). That single file read is the worst case — there is no system takeover, no large-scale breach, and no way to target many people at once.

It is also hard to pull off. Three things have to line up at the same moment:

1. the older Linux (non-portal) picker must be in use;
2. the user must be holding Enter as the page silently opens the picker; and
3. a file must be there to return.

Modern Linux systems use the safer picker by default, so most people are not exposed at all. This keeps the issue low severity and high complexity, in line with Mozilla’s rating and comparable to the earlier Firefox keypress finding CVE-2024-11697.

Proof of Concept

Our penetration tester, who identified the vulnerability, built a working Proof of Concept (PoC) to confirm the behaviour is reproducible.

The screenshot below shows the browser console output captured during reproduction. The attacker’s page successfully read secrets.txt from the previous origin’s file picker session:

Remediation

Sawah Cyber Security advises updating Firefox to version 152 or later (MFSA 2026-57). Because Firefox is open source, the corrective change is visible in the public 152 source tree and can be reviewed by diffing widget/gtk/nsFilePicker.cpp between versions 151 and 152.

Where immediate updating is not feasible, the portal-based file picker can be preferred over the legacy GTK path. In about:config:

widget.use-xdg-desktop-portal.file-picker = 1

Vulnerability Disclosure Timeline

References

• Mozilla Foundation Security Advisory MFSA 2026-57 (primary vendor advisory): mozilla.org/en-US/security/advisories/mfsa2026-57
• Mozilla source change (autoland diff for widget/gtk/nsFilePicker.cpp): hg-edge.mozilla.org/integration/autoland/diff/…/widget/gtk/nsFilePicker.cpp
• CVE record (MITRE / CVE.org): cve.org/CVERecord?id=CVE-2026-12322
• NVD: nvd.nist.gov/vuln/detail/CVE-2026-12322
• Tenable: tenable.com/cve/CVE-2026-12322
• Ubuntu security: ubuntu.com/security/CVE-2026-12322
• Amazon Linux ALAS: explore.alas.aws.amazon.com/CVE-2026-12322.html
• Red Hat security: access.redhat.com/security/cve/CVE-2026-12322

This research was carried out by the penetration testing team at Sawah Cyber Security, an offensive and defensive cybersecurity firm operating in Indonesia and the Netherlands. For enquiries: [email protected].