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 logic error in the Split View feature allows a compromised renderer to initiate navigations that are incorrectly treated as browser-initiated. This bypasses critical security protections including SameSite=Strict cookies, Fetch Metadata (Sec-Fetch-Site), and Omnibox spoofing guards. The vulnerability exists because security-critical fields are not propagated when navigating a split tab.

Affected files:

• chrome/browser/ui/browser.cc
• content/browser/renderer_host/ipc_utils.cc
• chrome/browser/ui/navigator/browser_navigator.cc
• chrome/browser/ui/tabs/tab_strip_model.cc
• components/blocked_content/popup_blocker.cc
• content/browser/renderer_host/render_frame_host_impl.cc

Estimated timestamp from git blame: 2026-04-03

Summary

A potential vulnerability in Browser::OpenURLFromTab allows a compromised renderer to ’launder’ a cross-origin navigation by using the WindowOpenDisposition::NEW_SPLIT_VIEW disposition. When this disposition is used to navigate an existing split tab, the browser fails to propagate the is_renderer_initiated and initiator_origin flags. As a result, the navigation is treated as browser-initiated (e.g., as if it originated from the Omnibox), bypassing several web security invariants.

Root Cause Analysis

In chrome/browser/ui/browser.cc, the handling logic for WindowOpenDisposition::NEW_SPLIT_VIEW contains a path (lines 1913-1930) that triggers when a source tab is already part of a split view. In this case, the browser identifies the other tab in the split and initiates a navigation on it:

// chrome/browser/ui/browser.cc:1921
content::NavigationController::LoadURLParams load_params(params.url);
load_params.transition_type = params.transition;
load_params.referrer =
    content::Referrer(params.referrer.url, params.referrer.policy);
tab->GetContents()->GetController().LoadURLWithParams(load_params);

The code manually constructs LoadURLParams but fails to copy the is_renderer_initiated and initiator_origin fields from the original params. Since is_renderer_initiated defaults to false, the navigation is treated as trusted by the rest of the system.

Potential Attack Scenario

1. Renderer Compromise: An attacker compromises a renderer process (e.g., https://attacker.example).
2. Forced Split: The attacker sends a LocalFrameHost::OpenURL IPC with disposition=NEW_SPLIT_VIEW. Because this disposition is not subject to popup blocking in components/blocked_content/popup_blocker.cc, the browser creates a new tab and automatically pairs it with the user’s currently active tab (e.g., https://victim.example) into a split view.
3. Navigation Laundering: The attacker’s split tab sends a second OpenURL IPC with disposition=NEW_SPLIT_VIEW targeting a sensitive URL on the victim’s origin (e.g., https://victim.example/transfer_funds).
4. Security Bypass: The browser executes the navigation on the victim’s tab. Because it is incorrectly marked as browser-initiated:
   • SameSite=Strict cookies for victim.example are included in the request.
   • The Sec-Fetch-Site header is set to none, bypassing Fetch Metadata-based CSRF defenses.
   • The Omnibox may display the pending URL immediately, facilitating URL spoofing.
   • The navigation occurs across a BrowsingInstance boundary, violating Site Isolation principles.

Suggested Fix

Ensure all security-critical fields are propagated in Browser::OpenURLFromTab when handling NEW_SPLIT_VIEW. Specifically, is_renderer_initiated, initiator_origin, and initiator_base_url should be copied from the original OpenURLParams to the newly created LoadURLParams.

Additionally, consider adding a browser-side check to ensure the NEW_SPLIT_VIEW disposition is only honored if the kSplitViewLinkOpen feature flag is enabled, and enforce user gesture requirements consistent with other tab-opening dispositions.

Evaluated with Chrome root at commit: b3153093eb3c78c3e88ccf562bcbc20437a04b0e

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.