PatchGap
Chrome · Prefetch

CVE-2026-87619

Info Disclosure in Prefetch
Low watch CVSS 4.3 chrome Info Disclosure 🧬 Authorization check exists but is not enforced on every path

Overview

Low
Severity
4.3
CVSS
No
Exploited ITW
Embargoed
Fix Status
ImpactObservable discrepancy in Prefetch
DescriptionObservable discrepancy in Prefetch
ComponentPrefetch
Bug ClassInfo Disclosure
Action tierwatch — information disclosure — security-relevant, below the RCE-class bar
Computed by PatchGap's deterministic exploitability ruler from the fixing commit. patch-now = RCE-class & attacker-reachable in a default config, or exploited in the wild; watch = real security signal below that bar; noise = no security relevance.
Tracker497433347
CWECWE-203
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
CISA KEVNot listed
CreditedGoogle
Reported2026-03-29 (per vendor advisory)
Disclosed2026-09-08

Fix not yet public

No public source fix for this bug has been identified on the main branch yet — it is embargoed or not yet disclosed. Root-cause analysis is withheld until the fix commit is available.

Background

Prefetch
Chromium’s speculative loading mechanism that fetches a resource before navigation, implemented in content::PrefetchService.
StoragePartition
the isolated storage container (cookies, cache, service workers) that a BrowserContext assigns to a given origin or embedder context.
Default storage partition
the StoragePartition returned by BrowserContext::GetDefaultStoragePartition(), used for ordinary top-level browsing.
Renderer initiator info
the GetRendererInitiatorInfo() record on a prefetch request that ties the request back to the RenderFrameHost that initiated it.
Key insight
The single mistake was checking only the target URL’s storage partition while ignoring the initiating frame’s storage partition, allowing a non-default-partition frame to trigger a default-partition prefetch; the fix closes this by deriving and comparing initiator_storage_partition before allowing prefetch to proceed.

Attack Path

  1. Host a frame in a non-default partition An embedder scenario places a frame (with an initiating RenderFrameHost) inside a non-default StoragePartition.
  2. Trigger a prefetch That frame initiates a prefetch whose target URL resolves to the default storage partition.
  3. Bypass the partition guard The old check passes because only the target URL’s partition matched the default, so eligibility is granted.
  4. Observe the discrepancy Cookie and service-worker state from the default partition influence the prefetch behavior, exposing an observable difference across the partition boundary.

Impact Assessment

An attacker gains an observable discrepancy across storage partitions, letting a frame in a non-default partition infer default-partition state (for example cookie or service-worker presence) via prefetch behavior. This occurs in the browser process’s prefetch eligibility path and requires the ability to initiate a prefetch from a frame residing in a non-default StoragePartition. Consistent with the metadata, the impact is a low-severity information/observability leak rather than memory corruption.

Audit Directions

  • Initiator-vs-target partition parity
    Wherever prefetch, prerender, or speculative loading makes an eligibility decision, confirm the initiator’s StoragePartition is validated, not just the target URL’s.
  • Optional initiator info
    Audit uses of GetRendererInitiatorInfo() and GetRenderFrameHost() for null cases, ensuring a missing initiator defaults safely to the default partition as the fix does.
  • Cross-partition observability
    Review other browser-process checks that gate on cookies or service workers to ensure they run against a single consistent partition, avoiding observable discrepancies across partition boundaries.

Original Bug Report

The reporter's bug is still restricted on the tracker. Chrome de-restricts security bugs ~30–90 days after the fix ships; a later run will backfill it here.
On This Page