Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A compromised renderer can potentially bypass Autofill’s overlap checks by repositioning an HTML form popup after the initial check has occurred. On Windows, these popups are implemented as separate native windows, and existing visibility defenses fail to detect occlusion by these external windows. This creates a potential clickjacking vector to trick users into accepting Autofill suggestions without informed consent.

Affected files:

• chrome/browser/ui/views/autofill/popup/popup_view_views.cc
• chrome/browser/ui/views/autofill/popup/popup_view_utils.cc
• content/browser/renderer_host/render_widget_host_impl.cc
• chrome/browser/ui/autofill/autofill_popup_hide_helper.cc
• chrome/browser/ui/views/autofill/popup/popup_row_view.cc

Estimated timestamp from git blame: 2026-03-04

Summary

A potential Time-of-Check Time-of-Use (TOCTOU) vulnerability exists in the Autofill popup’s overlap detection mechanism on Windows. When an Autofill popup is displayed, the browser performs a one-shot check to ensure it is not occluded by renderer-created HTML form popups (like <select> menus). However, a compromised renderer can move its popup after this check is completed. Because the browser does not continuously monitor the bounds of these native windows or account for their occlusion in the suggestion acceptance logic, an attacker can occlude Autofill suggestions with deceptive content.

Technical Details

The defense mechanism in PopupViewViews::DoUpdateBoundsAndRedrawPopup (chrome/browser/ui/views/autofill/popup/popup_view_views.cc) invokes BoundsOverlapWithHtmlFormPopup(), which snapshots the current bounds of renderer-owned HTML form popup widgets. If no intersection is detected at that moment, the Autofill suggestions are shown.

A compromised renderer can potentially exploit this by:

1. Creating a popup widget initially positioned off-screen.
2. Triggering Autofill suggestions. The browser’s one-shot check sees no overlap.
3. Calling the Mojo method PopupWidgetHost::SetPopupBounds to move the popup directly over the Autofill suggestions after the initial check.

On Windows, these popups are separate native windows (HWNDs). The browser’s secondary defense, PopupRowView::IsViewVisibleEnough() (chrome/browser/ui/views/autofill/popup/popup_row_view.cc), relies on views::View::GetVisibleBounds(). This method only calculates visibility within the internal Views hierarchy of a single widget and cannot detect occlusion by external native windows. Consequently, the renderer can paint arbitrary content over the Autofill suggestion, tricking the user into an unintended interaction.

Potential Attack Steps

1. Gain code execution in a sandboxed renderer process.
2. Create an HTML form element (e.g., <select>) that opens a native popup window.
3. Position the popup off-screen via SetPopupBounds before it is audited.
4. Trigger an Autofill suggestion on a sensitive field (e.g., a credit card input).
5. Wait for the 500ms safety period (kIgnoreEarlyClicksOnSuggestionsDuration) to elapse.
6. Reposition the popup to occlude the Autofill suggestion with a deceptive “Confirm” button.
7. When the user clicks the deceptive button, the renderer quickly moves its popup away, causing the subsequent mouseup event to fall through to the Autofill suggestion, which is then accepted because the visibility check fails to detect the prior occlusion.

Suggested Fix

1. Continuous Monitoring: The Autofill UI should register as an observer for the aura::Window of any active HTML form popups associated with the tab. Any change in the bounds of these windows should trigger a re-evaluation of the Autofill popup’s overlap status.
2. Enhanced Visibility Checks: Modify PopupRowView::IsViewVisibleEnough() to incorporate Aura-level occlusion tracking (aura::WindowOcclusionTracker), which is capable of detecting when a window is covered by other native windows, rather than relying solely on GetVisibleBounds().

Evaluated with Chrome root at commit: 1a8d40fc44df2088d5945c0bf53584038aa1614a

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

Data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.