CVE-2026-113009
Overview
Fix not yet public
Original Bug Report
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.ccchrome/browser/ui/views/frame/layout/browser_view_app_layout_impl.ccchrome/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:
- It converts the
locationpoint (relative to the RootView) to the coordinate space of theContentsWebView(point_in_contents_web_view_coords). - It then incorrectly passes this
point_in_contents_web_view_coordstoWidgetOwnedByAnchorContainsPoint(line 4453). WidgetOwnedByAnchorContainsPoint(line 2663) explicitly expects coordinates relative to theBrowserView, as it usesviews::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)
- Install a PWA that enables
window-controls-overlayor similar draggable region support. - Trigger a browser InfoBar to ensure there is a vertical offset between the browser frame and the web contents.
- Define a draggable region (
-webkit-app-region: drag) that overlaps the expected location of a permission prompt. - Trigger a permission prompt (e.g., Geolocation).
- 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.