Medium chrome UAF 📄 Reporter bug report

Overview

Medium
Severity
—
CVSS
No
Exploited ITW
Embargoed
Fix Status
ImpactUse after free in WindowControlsOverlay
DescriptionUse after free in WindowControlsOverlay
ComponentWindowControlsOverlay
Sub-componentUI>Browser>WebAppInstalls>WindowControlsOverlay
Bug ClassUAF
Tracker514066540
CISA KEVNot listed
CreditedGoogle
Disclosed2026-10-20

Fix not yet public

No public source fix for this bug has been identified on the main branch yet — it is embargoed or not yet disclosed. Root-cause analysis is withheld until the fix commit is available.

Original Bug Report

reported by vm...@google.com

Potential coordinate mismatch in BrowserView::ShouldDescendIntoChildForEventHandling

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 potential coordinate space error in BrowserView may cause event hit-testing for browser-owned widgets (like permission prompts) to fail when they overlap with a PWA’s draggable region. This occurs because coordinates relative to the web contents are incorrectly passed to a method expecting coordinates relative to the BrowserView.

Affected files:

  • chrome/browser/ui/views/frame/browser_view.cc
  • chrome/browser/ui/views/frame/layout/browser_view_app_layout_impl.cc
  • chrome/browser/ui/web_applications/app_browser_controller.cc

Estimated timestamp from git blame: 2023-06-06

Summary

A potential vulnerability has been identified in BrowserView::ShouldDescendIntoChildForEventHandling where a coordinate space mismatch may allow renderer-controlled draggable regions to interfere with event targeting for browser-owned UI components, such as permission prompts, JS alerts, or the Find Bar.

Technical Details

In chrome/browser/ui/views/frame/browser_view.cc, the method ShouldDescendIntoChildForEventHandling determines if an event should be allowed to reach a child window. For PWAs with draggable regions enabled, the code checks if a click falls within an app-defined draggable region. To prevent these regions from intercepting clicks intended for browser UI, it includes a safety check using WidgetOwnedByAnchorContainsPoint.

The implementation contains the following logic:

  1. It converts the location point (relative to the RootView) to the coordinate space of the ContentsWebView (point_in_contents_web_view_coords).
  2. It then incorrectly passes this point_in_contents_web_view_coords to WidgetOwnedByAnchorContainsPoint (line 4453).
  3. WidgetOwnedByAnchorContainsPoint (line 2663) explicitly expects coordinates relative to the BrowserView, as it uses views::View::ConvertPointToScreen(this, ...) to perform its internal checks.

In most browser configurations (e.g., when toolbars, bookmark bars, or InfoBars are visible), the ContentsWebView has a non-zero vertical offset relative to the BrowserView. Consequently, passing web-contents-relative coordinates to a method expecting browser-view-relative coordinates results in a vertical shift (typically 70-100 pixels). This shift causes WidgetOwnedByAnchorContainsPoint to return a false negative, leading ShouldDescendIntoChildForEventHandling to return false and drop the event.

Potential Impact

An attacker could potentially define a draggable region in a PWA that overlaps a browser-owned widget. Due to the coordinate mismatch, clicks on the widget would be incorrectly treated as falling outside the widget and inside a draggable region, causing the event to be dropped. This could be used to prevent a user from clicking “Block” or “Close” on a security-sensitive prompt, or to cause clicks to fall through to the underlying web content.

Suggested Steps to Reproduce (Potential)

  1. Install a PWA that enables window-controls-overlay or similar draggable region support.
  2. Trigger a browser InfoBar to ensure there is a vertical offset between the browser frame and the web contents.
  3. Define a draggable region (-webkit-app-region: drag) that overlaps the expected location of a permission prompt.
  4. Trigger a permission prompt (e.g., Geolocation).
  5. Attempt to click a button on the prompt that overlaps the draggable region and observe if the click is ignored or directed to the web content.

Suggested Fix

Modify BrowserView::ShouldDescendIntoChildForEventHandling to calculate and pass coordinates relative to the BrowserView when calling WidgetOwnedByAnchorContainsPoint:

    gfx::Point point_in_browser_view_coords(location);
    views::View::ConvertPointToTarget(GetWidget()->GetRootView(),
                                      this,
                                      &point_in_browser_view_coords);

    return !controller->draggable_region()->contains(
               point_in_contents_web_view_coords.x(),
               point_in_contents_web_view_coords.y()) ||
           WidgetOwnedByAnchorContainsPoint(point_in_browser_view_coords);

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.

View on issue tracker