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

Overview: A race condition in SharedStorageWorkletHost potentially allows a compromised renderer to access victim Shared Storage data before the mandatory .well-known cross-origin opt-in check completes. This bypasses the security requirement that cross-origin data origins must explicitly opt-in to worklet access via a trusted-origins file. The attacker can indefinitely prolong this access by deliberately hanging the worklet’s script load.

Affected files:

• content/browser/shared_storage/shared_storage_worklet_host.cc

Estimated timestamp from git blame: 2025-11-25

Vulnerability Description

A race condition exists in SharedStorageWorkletHost that potentially allows a compromised renderer to bypass the cross-origin opt-in requirement for Shared Storage. When a cross-origin worklet is created, the host immediately binds and dispatches the SharedStorageWorkletServiceClient remote to the renderer process before the asynchronous fetch of the mandatory /.well-known/shared-storage/trusted-origins opt-in file has completed.

Because the Mojo receiver for SharedStorageWorkletServiceClient lacks message gating and its storage-accessing handlers (such as SharedStorageGet and SharedStorageUpdate) do not verify the current opt-in state, an attacker-controlled renderer can issue Mojo calls to read or modify a victim’s cross-origin data during the fetch window.

Furthermore, an attacker can extend this window indefinitely by intentionally hanging the fetch of the worklet script (AddModule), preventing the browser from ever evaluating the failed opt-in check and shutting down the worklet.

Potential Attack Steps

(Note: These are suggested steps based on static analysis; a working proof-of-concept has not yet been executed.)

1. Setup: An attacker compromises a renderer process (e.g., hosting https://attacker.com).
2. Initiate Worklet Creation: The attacker crafts a CreateWorklet Mojo message over the blink.mojom.SharedStorageDocumentService interface, specifying script_source_url as https://attacker.com/script.js and data_origin as https://victim.com.
3. Host Initialization: The browser processes this request in SharedStorageDocumentServiceImpl::CreateWorklet. It creates a SharedStorageWorkletHost, which identifies that a cross-origin opt-in is required (needs_data_origin_opt_in_ = true).
4. Process Allocation: On platforms where strict Site Isolation is not enforced for the target origin (e.g., Android), the SharedStorageRenderThreadWorkletDriver assigns the victim.com worklet to run in the attacker’s compromised renderer process.
5. Premature Binding: SharedStorageWorkletHost::GetAndConnectToSharedStorageWorkletService() immediately calls Initialize() on the worklet service. This binds the SharedStorageWorkletServiceClient receiver in the browser and dispatches the remote to the compromised renderer before the .well-known opt-in check completes.
6. Hang Script Load: The attacker configures their server at https://attacker.com/script.js to hang the network fetch indefinitely. This keeps the AddModule script loading state pending.
7. Exploit Remote: The attacker intercepts the prematurely dispatched SharedStorageWorkletServiceClient remote in their compromised renderer.
8. Bypass Checks: The attacker immediately sends unauthorized storage-access Mojo messages (e.g., SharedStorageGet). The corresponding handlers in SharedStorageWorkletHost only check general user settings via IsSharedStorageAllowed(), failing to verify the pending .well-known data_origin_opt_in_state_.
9. Indefinite Access: Even after the asynchronous .well-known check to victim.com eventually fails, MaybeFinishCreateWorklet() returns early because the script load (script_loading_state_) is still pending. The worklet is never expired, granting the attacker an indefinite, unauthorized read/write channel to victim.com’s Shared Storage data.

Impact

This vulnerability constitutes a high-severity cross-origin data leak and modification risk (S1 Site Isolation Bypass). A compromised renderer can perform unauthorized operations against a victim’s Shared Storage, completely bypassing the .well-known opt-in security mechanism.

Recommended Fix

Ensure that the SharedStorageWorkletServiceClient Mojo receiver does not process messages until the .well-known opt-in check has successfully completed. This can be achieved by:

1. Deferring Binding: Wait to bind and dispatch the SharedStorageWorkletServiceClient remote until data_origin_opt_in_state_ is successfully resolved in MaybeFinishCreateWorklet().
2. Explicit Checks: Alternatively, add an explicit check for a successful data_origin_opt_in_state_ in all storage-accessing Mojo handlers within SharedStorageWorkletHost (e.g., SharedStorageGet, SharedStorageUpdate, etc.) when needs_data_origin_opt_in_ is true.

Evaluated with Chrome root at commit: 0eb4855bda702feaaa8b899336664f97e3df88b8

Results 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. Please feel free to reach out to me if you have concerns or feedback.