Chrome · Linux Toolkit Theming › GTK
CVE-2026-78974
Spoofing in Linux Toolkit Theming (GTK)
Overview
Low
Severity
5.4
CVSS
No
Exploited ITW
Fixed
Fix Status
Background
- `SelectFileDialogLinuxGtk`
- Chrome’s Linux implementation of the native file picker, built on GTK’s
GtkFileChooserDialog; it is shown for web-triggered file and folder uploads (<input type=file>, including folder-upload mode) and for browser-initiated open/save dialogs. - Dialog default response
- the GTK response ID that a
GtkDialogtriggers when the user presses Enter while no other widget handles the key; it is set withgtk_dialog_set_default_response. - `kResponseTypeAccept`
- Chrome’s custom accept-button response ID (value 0 according to the commit message), added by an earlier mitigation to stop GTK from treating the Open/Select button as the pre-selected default.
- `gtk.sigs`
- the signature list Chrome uses to generate stubs for GTK functions that it loads dynamically at runtime; every new GTK API call must be listed there.
Root Cause Analysis
When a file-open or folder-select dialog was shown, some GTK environments (the commit names XFCE and custom GTK themes) still focused the first non-cancel button, which is the accept button. This happened even though the earlier mitigation had given that button the custom kResponseTypeAccept ID instead of a standard “accept” response.
As a result, a key press the user meant for the web page, such as Enter, could reach the dialog the moment it appeared and confirm the current selection without the user ever reading the dialog. The broken invariant is that a security-sensitive choice (handing local files or folders to a web page) must need deliberate user input, not just a keystroke that happens to arrive while the dialog opens.
The patch calls gtk_dialog_set_default_response(GTK_DIALOG(dialog), GTK_RESPONSE_CANCEL) right after each open and select-folder dialog is created, so an unintended Enter now cancels the dialog. Deliberate selection still works, because pressing Enter in the file list or filename entry is handled through GtkFileChooser’s file-activated signal. The two GTK symbols are added to gtk.sigs so the dynamically loaded GTK provides them. Save-As dialogs are left unchanged on purpose.
Key insight
Chrome relied on a non-standard accept response ID to keep the accept button from becoming the default, but GTK themes and desktop environments do not reliably honour that. The fix sets Cancel as the explicit default response, so an Enter key press that arrives while the dialog opens fails safe.
Attack Path
- Lure the user into typing A malicious page gets the user to press keys repeatedly, for example with a game or a fake form, so that an Enter press is likely at a predictable moment.
- Open the picker During a user activation the page triggers a file upload or folder upload chooser. On Linux with GTK this creates the dialog through the open or select-folder code paths patched here.
- Keystroke reaches the dialog On affected desktop environments or themes, the accept button is focused when the dialog appears, so the user’s next Enter press activates it before the user notices the dialog.
- Unintended disclosure The dialog returns whatever was selected by default (for a folder chooser, plausibly the current directory) to the page, which can read the contents of the upload (inferred).
Impact Assessment
A web page can trick a user into confirming a native file or folder chooser they did not mean to accept, which can expose local files or a whole directory to the site (inferred). This needs Linux with the GTK file dialog, an affected desktop environment or theme (XFCE or custom GTK themes, per the commit), a user activation to open the picker, and social engineering to get a well-timed key press. The advisory rates this as UI misrepresentation in Linux Toolkit Theming and does not report in-the-wild exploitation.
Files Changed
ui/gtk/gtk.sigsui/gtk/select_file_dialog_linux_gtk.cc
Audit Directions
- Native dialogs with an accept-by-default actionCheck other platform dialogs (Save-As, which this patch leaves out on purpose; print; permission and certificate pickers; and the Linux portal-based
SelectFileDialog) for an accept action bound to Enter or to initial focus while the dialog opens. - Relying on toolkit or theme behaviourMitigations that depend on how a toolkit treats a custom response ID or focus order (like the earlier
kResponseTypeAccept= 0 trick) should be retested on other desktop environments, themes and GTK3/GTK4 builds. Explicit default and focus settings are more robust. - Missing input-protection delayCompare with Chrome’s in-browser dialogs, which ignore input for a short time after showing (the “input protector” pattern). Native OS dialogs opened from web content do not get that protection automatically.
Patch
From 1580de16c61d14aa215901fab5eb0ffbab454cf5 Mon Sep 17 00:00:00 2001
From: Tom Anderson <thomasanderson@chromium.org>
Date: Tue, 07 Jul 2026 17:18:32 -0700
Subject: [PATCH] [GTK] Mitigate file picker accept button focus stealing
Explicitly set the file open and folder selection dialog's default
response to GTK_RESPONSE_CANCEL using gtk_dialog_set_default_response.
The previous mitigation (CL 7399531) used a custom 0 response ID to
attempt to prevent GTK from preselecting the accept button. However,
certain desktop environments like XFCE and custom GTK themes still focus
the first non-cancel button upon the dialog's appearance.
By designating GTK_RESPONSE_CANCEL as the default response for
open/upload dialogs, unintended Enter key presses will safely close the
dialog. Standard user selection via pressing Enter in the file list or
filename entry remains unaffected as they are handled internally by
GtkFileChooser via its file-activated signal.
This focus-prevention behavior is restricted to File Open and Select
Folder dialogs. Save As dialogs continue to use the default Save button
to avoid usability regressions when typing filenames.
Bug: 503048520
Change-Id: I5d2243c5ea2bf113180ea5a091945943fa34bab3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8061985
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1658399}
---
diff --git a/ui/gtk/gtk.sigs b/ui/gtk/gtk.sigs
index 8e13d2d..a669940 100644
--- a/ui/gtk/gtk.sigs
+++ b/ui/gtk/gtk.sigs
@@ -196,3 +196,5 @@
void gtk_window_set_modal(GtkWindow* window, gboolean modal);
void gtk_print_settings_set_printer(GtkPrintSettings* settings, const gchar* printer);
GType gtk_settings_get_type(void);
+GType gtk_dialog_get_type(void);
+void gtk_dialog_set_default_response(GtkDialog* dialog, gint response_id);
diff --git a/ui/gtk/select_file_dialog_linux_gtk.cc b/ui/gtk/select_file_dialog_linux_gtk.cc
index c354a04..e56fa5b 100644
--- a/ui/gtk/select_file_dialog_linux_gtk.cc
+++ b/ui/gtk/select_file_dialog_linux_gtk.cc
@@ -464,6 +464,7 @@
GtkWidget* dialog = GtkFileChooserDialogNew(
title.c_str(), nullptr, GTK_FILE_CHOOSER_ACTION_OPEN, GetCancelLabel(),
GTK_RESPONSE_CANCEL, GetOpenLabel(), kResponseTypeAccept);
+ gtk_dialog_set_default_response(GTK_DIALOG(dialog), GTK_RESPONSE_CANCEL);
SetGtkTransientForAura(dialog, parent, platform_);
AddFilters(GTK_FILE_CHOOSER(dialog));
@@ -504,6 +505,7 @@
title_string.c_str(), nullptr, GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER,
GetCancelLabel(), GTK_RESPONSE_CANCEL, accept_button_label.c_str(),
kResponseTypeAccept);
+ gtk_dialog_set_default_response(GTK_DIALOG(dialog), GTK_RESPONSE_CANCEL);
SetGtkTransientForAura(dialog, parent, platform_);
GtkFileChooser* chooser = GTK_FILE_CHOOSER(dialog);
if (type == SELECT_UPLOAD_FOLDER || type == SELECT_EXISTING_FOLDER)
Loading diff…
Original Bug Report
The reporter's bug is still restricted on the tracker. Chrome de-restricts security bugs ~30–90 days after the fix ships; a later run will backfill it here.
References
On This Page