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 Use-After-Free (UAF) vulnerability exists in the browser process on macOS when Navigator::DidNavigate returns early. If the WebContents is destroyed during a nested AppKit message loop spun by ExitFullscreenModeForTab, the NavigationRequest unique_ptr is dropped upon early-return and its destructor dereferences a freed FrameTreeNode. Because the FrameTreeNode pointer is marked as RAW_PTR_EXCLUSION, it is not protected by MiraclePtr.

Affected files:

• content/browser/renderer_host/navigation_request.cc
• content/browser/renderer_host/navigator.cc
• content/browser/renderer_host/navigation_request.h

Estimated timestamp from git blame: 2026-03-06

Root Cause Analysis

A potential Use-After-Free (UAF) vulnerability exists in the browser process due to ~NavigationRequest dereferencing a freed FrameTreeNode when Navigator::DidNavigate returns early on macOS.

In Navigator::DidNavigate (content/browser/renderer_host/navigator.cc):

void Navigator::DidNavigate(
    RenderFrameHostImpl* render_frame_host,
    const mojom::DidCommitProvisionalLoadParams& params,
    std::unique_ptr<NavigationRequest> navigation_request,
    bool was_within_same_document, bool caused_by_ad) {
  ...
  base::WeakPtr<RenderFrameHostImpl> weak_rfh = render_frame_host->GetWeakPtr();
  delegate_->DidNavigateAnyFramePreCommit(navigation_request.get(),
                                          was_within_same_document);
  if (!weak_rfh) {
    return; // Destroys navigation_request -> ~NavigationRequest()
  }

If DidNavigateAnyFramePreCommit triggers a nested AppKit message loop (e.g., via ExitFullscreenModeForTab on macOS) and destroys the WebContents (due to a queued window-close task), the function returns early at the !weak_rfh check.

However, the WebContentsImpl and its root FrameTreeNode have already been freed. NavigationRequest::frame_tree_node_ is explicitly excluded from MiraclePtr (RAW_PTR_EXCLUSION in content/browser/renderer_host/navigation_request.h):

RAW_PTR_EXCLUSION FrameTreeNode* const frame_tree_node_;

Consequently, ~NavigationRequest dereferences this stale pointer:

• navigation_request.cc:2321 reads frame_tree_node_->navigation_request() from freed memory.
• navigation_request.cc:2410 calls GetDelegate()->DidFinishNavigation(this). GetDelegate() dereferences frame_tree_node_ to get the freed FrameTree, then Navigator, then NavigatorDelegate, executing a virtual method call on a potentially attacker-controlled pointer.

Potential Attack Scenario

Note: These are potential steps to trigger the issue, as our tooling agent does not have the ability to run code or verify a live exploit.

1. On macOS, Page A opens same-site popup Page B.
2. Page B requests HTML fullscreen (document.documentElement.requestFullscreen()) and then navigates to a cross-document location.
3. Immediately before the commit occurs, Page A closes B (w.close()), queuing a destruction task in the browser’s event loop.
4. When DidCommitProvisionalLoad is processed on the browser, ExitFullscreen spins a nested AppKit run loop to animate the fullscreen transition.
5. The nested loop executes the pending close task, destroying WebContentsImpl and freeing its FrameTreeNode.
6. Once the nested loop exits, the !weak_rfh guard fires in Navigator::DidNavigate and returns early.
7. This triggers ~NavigationRequest, dereferencing the freed frame_tree_node_ and calling GetDelegate()->DidFinishNavigation(this).

Impact

This issue could lead to a browser-process Use-After-Free (UAF). If the memory is reclaimed and sprayed by an attacker, they can control the layout and execute arbitrary virtual method calls, potentially resulting in Remote Code Execution (RCE) in the browser process (sandbox escape).

Suggested Fix

To prevent the UAF, do not dereference frame_tree_node_ directly in the destructor of NavigationRequest if it is no longer valid. Since FrameTreeNode provides a stable ID lookup, we can store FrameTreeNodeId and retrieve the node dynamically, verifying it is still alive before performing actions in the destructor:

// In NavigationRequest::~NavigationRequest():
FrameTreeNode* node = FrameTreeNode::GloballyFindByID(frame_tree_node_id_);
if (node) {
  if (NavigationRequest* request = node->navigation_request()) {
    if (request->IsQueued() && request != this) {
      ...
    }
  }
}

And update GetDelegate() to handle null pointers gracefully if the node has been destroyed:

NavigatorDelegate* NavigationRequest::GetDelegate() const {
  FrameTreeNode* node = FrameTreeNode::GloballyFindByID(frame_tree_node_id_);
  return node ? node->navigator().GetDelegate() : nullptr;
}

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.