PatchGap
Chrome · GuestView

CVE-2026-13871

Logic Error in GuestView
Medium chrome Logic Error 📄 Reporter bug report 🔧 Commit mapped

Overview

Medium
Severity
—
CVSS
No
Exploited ITW
Fixed
Fix Status
ImpactInsufficient data validation in GuestView
DescriptionInsufficient data validation in GuestView
ComponentGuestView
Bug ClassLogic Error
Tracker497961376
Fix commit3666da54d07d (chromium/src) +2/-1
CISA KEVNot listed
CreditedGoogle
Disclosed2026-06-30

Files Changed

  • components/guest_view/browser/guest_view_base.cc

Patch

view commit
From 3666da54d07db74a5ce36831456529c1b92fde82 Mon Sep 17 00:00:00 2001
From: Kevin McNee <[email protected]>
Date: Mon, 11 May 2026 17:46:13 -0700
Subject: [PATCH] Ensure pre-attachment guest owner RFH updates stay within the same renderer

An unattached guest is scoped to the process that created it.

Fixed: 497961376
Change-Id: I3d4c588080bb07b8122dc7f045bc677f118bad62
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7837698
Reviewed-by: Alex Moshchuk <[email protected]>
Commit-Queue: Alex Moshchuk <[email protected]>
Auto-Submit: Kevin McNee <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1628925}
---

diff --git a/components/guest_view/browser/guest_view_base.cc b/components/guest_view/browser/guest_view_base.cc
index 4092932e..ba981b25 100644
--- a/components/guest_view/browser/guest_view_base.cc
+++ b/components/guest_view/browser/guest_view_base.cc
@@ -91,7 +91,8 @@
   void RenderFrameHostChanged(content::RenderFrameHost* old_host,
                               content::RenderFrameHost* new_host) override {
     if (old_host && guest_->owner_rfh_id_ == old_host->GetGlobalId() &&
-        new_host && guest_->element_instance_id_ == kInstanceIDNone) {
+        new_host && guest_->element_instance_id_ == kInstanceIDNone &&
+        old_host->GetProcess() == new_host->GetProcess()) {
       // TODO(crbug.com/40202416): Do something similar for MPArch.
       guest_->owner_rfh_id_ = new_host->GetGlobalId();
     }
Loading diff…

Original Bug Report

reported by [email protected]

GuestView ownership transfer bypasses CanEmbedderAccessInstanceID

Project Fortify, an experimental security project, has identified the following potential security issue.

Overview: A compromised renderer can hijack an unattached GuestView to bypass Site Isolation and control an extension’s storage partition. The RenderFrameHostChanged logic fails to validate the new host’s origin or process during cross-process navigations. This allows an attacker to bypass CanEmbedderAccessInstanceID and attach the guest while retaining the original privileged identity.

Affected files:

  • components/guest_view/browser/guest_view_base.cc
  • components/guest_view/browser/guest_view_manager.cc
  • extensions/browser/guest_view/web_view/web_view_guest.cc

Estimated timestamp from git blame: 2025-11-04

Final Conclusion

A compromised renderer successfully hijacks an unattached GuestView by bypassing CanEmbedderAccessInstanceID, maintaining the original extension-keyed storage partition and bypassing Site Isolation.

Potential Attack Steps

Note: These are suggested steps; our tooling agent does not yet have the ability to run code.

  1. Initial logic and parameters for GuestView creation and owner_rfh_id_ assignment are validated.
  2. Standard processing applied for handling cross-process tab navigation to an attacker-controlled site.
  3. Standard processing applied for OwnerContentsObserver::RenderFrameHostChanged execution.
  4. Standard processing applied for Mojo interface binding (guest_view::mojom::GuestViewHost) and the AttachToEmbedderFrame Mojo invocation.
  5. Standard processing applied for GuestViewManager::CanEmbedderAccessInstanceID validation.
  6. Established context routes the flow to GuestViewBase::AttachToOuterWebContentsFrame.
  7. owner_web_contents() == embedder_web_contents evaluates to true; execution jumps directly to the else branch (owner_rfh_id_ = outer_contents_frame->GetParent()->GetGlobalId();), skipping UpdateWebContentsForNewOwner. The attacker attains full control over the GuestView, retaining the original extension’s identity and isolated StoragePartition.

Suggested Fix

Modify GuestViewBase::OwnerContentsObserver::RenderFrameHostChanged to verify that the new_host belongs to the same process or shares the same origin as the old_host before updating guest_->owner_rfh_id_. Additionally, enforce stricter origin checks during the attachment process in AttachToOuterWebContentsFrame.

Evaluated with Chrome root at commit: a9cbf6e8b275fe4147435aa905f3b7f5a656f5f0

Results from so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; 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
On This Page