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

Overview: A compromised renderer can hijack DevTools sessions for cross-origin pages by supplying a stolen devtools_frame_token during fenced frame creation. The browser improperly scopes token uniqueness validation to the current tab and silently overwrites the process-global DevTools target map on collision, allowing an attacker to intercept Chrome DevTools Protocol (CDP) commands.

Affected files:

• content/browser/devtools/devtools_agent_host_impl.cc
• content/browser/devtools/render_frame_devtools_agent_host.cc
• content/browser/renderer_host/render_frame_host_impl.cc
• content/browser/renderer_host/render_frame_proxy_host.cc

Estimated timestamp from git blame: 2026-01-06

Overview

A logic error exists in DevToolsAgentHostImpl where process-global DevTools target IDs can be overwritten due to insufficient validation during Fenced Frame creation. A compromised renderer can exploit this to hijack DevTools automation sessions (e.g., Puppeteer) connecting to cross-origin targets, leading to cross-origin data theft.

Vulnerability Details

The issue stems from a combination of three factors:

1. Cross-WebContents Token Leak: When a renderer opens a cross-origin popup, the browser sends a PageBroadcast.CreateRemoteMainFrame Mojo IPC to the opener renderer so it can build a remote frame proxy. This IPC leaks the victim frame’s devtools_frame_token to the potentially compromised opener renderer.
2. Insufficient Validation Scope: When a renderer creates a Fenced Frame, it supplies a devtools_frame_token via the LocalFrameHost.CreateFencedFrame Mojo IPC. RenderFrameHostImpl::CreateFencedFrame attempts to ensure this token is unique to prevent collisions. However, it only checks nodes within the current tab’s FrameTree (GetOutermostMainFrame()->frame_tree()->NodesIncludingInnerTreeNodes()). It fails to check for collisions across different WebContents.
3. Silent Map Overwrite: When the DevTools agent host is created for the new fenced frame, DevToolsAgentHostImpl::NotifyCreated registers it in a process-global map:

   void DevToolsAgentHostImpl::NotifyCreated() {
     DCHECK(!GetDevtoolsInstances().contains(id_));
     GetDevtoolsInstances()[id_] = this;
     // ...
   }
   

   Because DCHECK is compiled out in Release builds, the global map entry for the victim’s token is silently overwritten with a pointer to the attacker’s new fenced frame agent host.

Potential Attack Steps

Note: These are theoretical steps as our tooling does not yet have the ability to run code to produce a working proof-of-concept.

1. An attacker gains code execution in a renderer process (e.g., via a V8 bug).
2. The compromised renderer opens a cross-origin window to a sensitive site (e.g., window.open('https://victim.com')).
3. The browser sends a CreateRemoteMainFrame IPC to the attacker’s renderer. The attacker intercepts this IPC and extracts the victim’s devtools_frame_token.
4. The compromised renderer crafts a LocalFrameHost.CreateFencedFrame Mojo IPC to create a fenced frame in its own document, passing the stolen victim’s devtools_frame_token instead of a randomly generated one.
5. The browser’s validation passes because the victim is in a different WebContents.
6. The browser creates a RenderFrameDevToolsAgentHost for the attacker’s fenced frame, which silently overwrites the victim’s entry in the global GetDevtoolsInstances() map.
7. An automated DevTools client (like Puppeteer or a Chrome Extension) attempts to attach to the victim’s target ID.
8. DevToolsAgentHostImpl::GetForId returns the attacker’s fenced frame. The DevTools client unknowingly sends CDP commands (e.g., Runtime.evaluate to inject scripts or Input.dispatchKeyEvent to type passwords) into the attacker’s frame, allowing the attacker to steal credentials or hijack the session.

Suggested Fix

1. Harden Map Insertion: In DevToolsAgentHostImpl::NotifyCreated(), upgrade the DCHECK to a CHECK, or safely handle the collision without overwriting existing valid instances.
2. Enforce Global Uniqueness: Update the validation in RenderFrameHostImpl::CreateFencedFrame to check the global DevToolsAgentHost::GetForId() (or a truly global registry) to ensure the token doesn’t collide with any existing target across all WebContents.
3. Browser-Side Token Generation: Consider having the browser unconditionally generate the devtools_frame_token for Fenced Frames rather than trusting the token provided by the renderer via IPC.

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.