macOS: Secure Event Input remains enabled after password form submission

#557064072 Reported 2026-09-04 Assigned / P3 Patched build available

Problem

Secure Event Input remains active after navigation

Submitting a form by pressing Enter while a password field is focused can leave macOS Secure Event Input enabled after the destination page loads. While active, global hotkeys, text expansion tools, and other applications using CGEventTap may stop receiving keyboard events.

Reproduction

while true; do
  clear
  ioreg -l -w 0 | grep SecureInput
  sleep 1
done
  1. Open the test login page.
  2. Enter tomsmith and SuperSecretPassword!.
  3. Keep focus in the password field and press Enter.
  4. After navigation, check whether kCGSSessionSecureInputPID still contains Chromium's PID.

Expected and actual behavior

Expected

After navigation

kCGSSessionSecureInputPID = 0

Affected build

After navigation

Secure input remains owned by Chromium until the tab is closed.

Fix

Release secure password input when entering BFCache

The patch disables the macOS secure password input scope when the outgoing render widget enters the back-forward cache. DOM focus remains preserved for BFCache restoration, while the process-global macOS state is released during navigation.

Patch commit: be1f48eccd5b0

Patched macOS build

⬇ Download patched Chromium for macOS

Universal build

Unsigned development build for Intel and Apple Silicon. Unzip it, move Chromium.app to Applications, then remove quarantine if macOS blocks launch:

Version: Chromium 155.0.8050.0
Architectures: x86_64 + arm64
Download size: 450 MiB
SHA-256: c8b7c53883a9de6ae36c7b5ad36d82966210dc87bb33039f44f401913d9efed3

xattr -dr com.apple.quarantine /Applications/Chromium.app

This binary is provided only to verify issue 557064072. It does not update automatically and should not be used as a primary browser.

Links

Chromium issue Build packaging notes