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 security bypass exists in GuestViewBase where forwarding draggable regions from a guest to the embedder delegate substitutes the embedder’s WebContents as the source parameter. This l laundering bypasses critical source-validation checks in AppWindow and AppBrowserController delegates. Consequently, an untrusted guest frame can potentially define arbitrary draggable regions over the entire native window of the host application, enabling clickjacking and interaction suppression.

Affected files:

• components/guest_view/browser/guest_view_base.cc
• extensions/browser/app_window/app_window.cc
• chrome/browser/ui/web_applications/app_browser_controller.cc

Estimated timestamp from git blame: 2025-12-29

Root Cause Analysis

In components/guest_view/browser/guest_view_base.cc, when a guest webpage notifies the browser of a change in its draggable regions, GuestViewBase::DraggableRegionsChanged gets called:

void GuestViewBase::DraggableRegionsChanged(
    const std::vector<blink::mojom::DraggableRegionPtr>& regions,
    content::WebContents* contents) {
  CHECK(!base::FeatureList::IsEnabled(features::kGuestViewMPArch));

  if (!attached() || !embedder_web_contents()->GetDelegate()) {
    return;
  }

  embedder_web_contents()->GetDelegate()->DraggableRegionsChanged(
      regions, embedder_web_contents()); // <-- Source substituted to embedder_web_contents()
}

Instead of forwarding the actual guest WebContents* source (contents), it substitutes the embedder_web_contents() pointer.

This substitution (or laundering) bypasses critical verification checks performed by the embedder delegates:

1. AppWindow::DraggableRegionsChanged (extensions/browser/app_window/app_window.cc):

   void AppWindow::DraggableRegionsChanged(
       const std::vector<blink::mojom::DraggableRegionPtr>& regions,
       content::WebContents* contents) {
     CHECK_EQ(contents, web_contents())
         << "Received DraggableRegionsChanged() notification for unexpected web contents";
     native_app_window_->DraggableRegionsChanged(regions);
   }
   

   The CHECK_EQ is bypassed because contents is substituted with the embedder’s web_contents() (which matches web_contents()).

2. AppBrowserController::DraggableRegionsChanged (chrome/browser/ui/web_applications/app_browser_controller.cc):

   void AppBrowserController::DraggableRegionsChanged(
       const std::vector<blink::mojom::DraggableRegionPtr>& regions,
       content::WebContents* contents) {
     content::WebContents* active_contents = 
         browser()->tab_strip_model()->GetActiveWebContents();
     if (contents != active_contents) {
       return;
     }
     ...
   

   The active WebContents verification check is bypassed because contents has been substituted with the active embedder WebContents.

Potential Attack Vector & Impact

Because coordinate translation is not applied to the forwarded vector, these regions are interpreted relative to the native coordinates of the outer/embedder window.

Furthermore, since draggable regions are standard CSS features (-webkit-app-region: drag), an untrusted webpage loaded inside a <webview> (in a Chrome App) or <controlledframe> (in an Isolated Web App) can trigger this notification natively without requiring a compromised renderer.

By specifying arbitrary coordinates (e.g., covering the entire native window frame or targeting specific coordinates of host controls), the guest page can mark arbitrary regions of the host UI as draggable. Any clicks in these areas will be captured by the OS window manager as window dragging gestures, which suppresses normal mouse click events from being processed by the application’s trusted elements. This enables clickjacking or UI redressing attacks where the attacker can selectively allow clicks only on specific elements (like a “Yes” or “Allow” button) while making “No” or “Deny” buttons unclickable.

Suggested Steps to Reproduce (Potential)

Please note: These are suggested/potential steps to reproduce. Our tooling agent doesn’t yet have the ability to run code or dynamically verify the exploit.

1. Install an Isolated Web App (IWA) containing a <controlledframe src="https://attacker.example"> or a frameless Chrome App containing <webview src="https://attacker.example">.
2. On the attacker-controlled guest webpage https://attacker.example, use the standard CSS property -webkit-app-region: drag; on the page body, or dynamically change the region style.
3. The layout engine will compile the regions and transmit them to the browser via the LocalMainFrameHost::DraggableRegionsChanged Mojo IPC.
4. Observe that the check in AppWindow::DraggableRegionsChanged or AppBrowserController::DraggableRegionsChanged passes successfully because the source was laundered to embedder_web_contents().
5. Click on the host application’s trusted UI elements (outside the boundaries of the guest iframe) and observe that clicks are intercepted and treated as window-dragging gestures by the OS.

Suggested Fix

To resolve this issue, GuestViewBase::DraggableRegionsChanged must not substitute the source WebContents parameter with the embedder’s WebContents. Instead, the original guest WebContents parameter should be passed (or the delegate should be updated to handle guest-origin region updates appropriately, such as translating coordinates relative to the guest’s position in the embedder window or explicitly discarding guest draggable region requests if the embedder does not want to support them).

Evaluated with Chrome root at commit: a2bea94528f4bd6cc57739c43fa3bb890b8367d3

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.