Chrome · Passwords
CVE-2026-79058
Authorization Error in Passwords
Overview
Low
Severity
9.1
CVSS
No
Exploited ITW
Fixed
Fix Status
Background
- Password generation popup
- Browser-side UI, driven from
chrome_password_manager_client.cc, that offers a Chrome-generated strong password for a new-password field; it is positioned over the page using data (ui_data, includingui_data->form_data) supplied by the renderer. - Back/forward cache (BFCache)
- A navigation optimization that keeps a
RenderFrameHostalive but inactive after the user navigates away, so it can be restored on back/forward; an inactive frame is no longer what the user is looking at. - `CheckFrameActiveAndNotPrerendering()`
- A helper used in this file that returns false when a
RenderFrameHostis not active (e.g. BFCached or otherwise non-primary) or is prerendering, so callers can refuse to act on behalf of such frames. - Renderer-controlled Mojo reply
- A callback whose arguments and arrival time are determined by the renderer process, so the browser must re-validate the frame’s state when it arrives rather than when the request was sent.
Root Cause Analysis
The patched code is a browser-side handler (the enclosing function name is not shown in the hunk) that receives renderer-supplied password-generation ui_data together with a driver, and after a null check proceeds to validate ui_data->form_data.url() with password_manager::bad_message::CheckChildProcessSecurityPolicyForURL() and then show generation UI. Before the patch, nothing verified that driver->render_frame_host() was still the active, user-visible frame at the time the reply arrived. Because the reply is asynchronous and renderer-controlled, it can be delivered after the originating frame has been placed into BFCache or otherwise become non-primary, so the browser would draw the generation popup on top of whatever page is now displayed. The violated invariant is that browser UI acting on behalf of a frame must only be shown while that frame is active and is what the user sees.
The fix adds an early return when CheckFrameActiveAndNotPrerendering(driver->render_frame_host()) fails, placed before the URL security-policy check and before any UI is shown, so replies from inactive or prerendering frames are dropped.
Key insight
The handler trusted that a renderer’s asynchronous reply still came from the frame the user was looking at; the fix adds a frame-activeness check (
CheckFrameActiveAndNotPrerendering) at reply time so popups cannot be shown for BFCached or non-primary frames.Attack Path
- Attacker page triggers generation
A page with a new-password form causes the renderer to request password generation UI, so a reply carrying
ui_datawill be sent to the browser (requires password generation to be available for the user, inferred). - Originating frame becomes inactive Before that reply is processed, the page navigates the tab (or otherwise causes the frame to be BFCached / become non-primary), so a different page, possibly another origin, is now shown.
- Late reply reaches the browser
The renderer-controlled reply arrives; pre-patch the handler only checked
ui_data/driverfor null and the form URL against the inactive frame’s process policy. - Popup drawn over the wrong page The browser shows the password generation popup over the currently visible page, letting the attacker present Chrome password UI in a misleading context (UI spoofing per the commit subject).
Impact Assessment
An attacker-controlled page can cause trusted Chrome password-generation UI to appear while a different page is displayed, a browser-UI spoofing issue that could mislead the user about which site a generated password belongs to or what they are interacting with. The precise timing may be easier to control from a compromised renderer, which can delay the reply arbitrarily (inferred); the commit subject only describes “potential UI spoofing”, and the advisory states “Missing authorization in Passwords” with no in-the-wild exploitation reported. No memory corruption or credential disclosure is demonstrated by the patch.
Changed Functions
| Function | Change | Notes |
|---|---|---|
ifchrome/browser/password_manager/chrome_password_manager_client.cc |
modified |
Files Changed
chrome/browser/password_manager/chrome_password_manager_client.cc
Audit Directions
- Async renderer replies that drive browser UIAudit Mojo callbacks and reply handlers in autofill, password manager, permissions and payments that show popups/bubbles, and confirm they re-check
RenderFrameHost::IsActive()(or an equivalent helper) when the reply arrives, not only when the request was sent. - BFCache and prerender lifecycle gapsLook for features that store a
driver,RenderFrameHost*orWeakPtracross an async hop and later act on it; an object still being alive does not mean its frame is user-visible. - Ordering of validationWhere handlers already validate renderer data (URL/origin policy checks), make sure frame-state checks run first and that a failure returns before any UI or state change.
Patch
From 0a587d5886da25124d5c597ecd5e6961f2800faa Mon Sep 17 00:00:00 2001
From: Anna Tsvirchkova <atsvirchkova@google.com>
Date: Tue, 07 Jul 2026 00:51:22 -0700
Subject: [PATCH] Fix potential UI spoofing via password generation popup triggered by BFCached frame
Bug: 519242511
Change-Id: Ie0cedcb03613d519bcb2fd7ca1e8740e4d96f5a5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8035089
Reviewed-by: Ioana Treib <ioanap@chromium.org>
Commit-Queue: Anna Tsvirchkova <atsvirchkova@google.com>
Cr-Commit-Position: refs/heads/main@{#1657751}
---
diff --git a/chrome/browser/password_manager/chrome_password_manager_client.cc b/chrome/browser/password_manager/chrome_password_manager_client.cc
index 0767097a..232dec7 100644
--- a/chrome/browser/password_manager/chrome_password_manager_client.cc
+++ b/chrome/browser/password_manager/chrome_password_manager_client.cc
@@ -2163,6 +2163,11 @@
if (!ui_data || !driver) {
return;
}
+ // The reply is renderer-controlled and may arrive after the originating RFH
+ // has been BFCached / become non-primary; do not show UI for inactive RFHs.
+ if (!CheckFrameActiveAndNotPrerendering(driver->render_frame_host())) {
+ return;
+ }
// Check the data because it's a Mojo callback and the input isn't trusted.
if (!password_manager::bad_message::CheckChildProcessSecurityPolicyForURL(
driver->render_frame_host(), ui_data->form_data.url(),
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