When the WebProcess schedules a resource load on the NetworkProcess, WebLoaderStrategy::scheduleLoadFromNetworkProcess() builds a NetworkResourceLoadParameters and calls createSandboxExtensionHandlesIfNecessary() to mint sandbox-extension handles that grant the NetworkProcess read access to any local file the load requires (files referenced in an httpBody upload, and, per the shown hunk, the file-system path of the request URL via SandboxExtension::createHandle(request.url().fileSystemPath(), ReadOnly)). Before the patch this function returned void: it attempted to create the handles and then the caller proceeded with the load unconditionally, whether or not handle creation actually succeeded. Sandbox-extension creation for a path can succeed or fail depending on whether that path exists and is accessible, so a load that proceeded without a needed extension would behave observably differently (e.g. proceed to a file read that succeeds or fails, or produce different errors/timing) than one where the extension was granted. That observable difference is a side channel: it lets attacker-controlled web content distinguish states of the local filesystem, which the CVE describes as a fingerprinting capability.

The fix changes createSandboxExtensionHandlesIfNecessary() to return bool — it returns resourceSandboxExtension.has_value() after the httpBody/file-path branch and true when there is no body — so the caller can tell whether a required extension was successfully created. WebLoaderStrategy now checks that return value and, if it is false, dispatches resourceLoader->didFail(blockedError(request)) on the main run loop and returns early, aborting the load uniformly instead of proceeding without the extension. This restores the invariant that a load requiring a local-file sandbox extension either runs with that extension or fails as blocked — never runs in a degraded, path-existence-dependent way — so the success/failure of the load no longer leaks whether the underlying file path was accessible. Note: the middle of the function (the httpBody element loop, diff lines 34-56) is not shown, so the exact set of paths for which handles are created is partly inferred from the visible request.url().fileSystemPath() branch and the function’s name.

This is an information-disclosure / fingerprinting bug, not a memory-corruption primitive: the leaked signal is coarse (whether a local file path is accessible), gated by whichever loads can be induced to reference local paths, and yields no read/write of memory. It spans the WebProcess (WebLoaderStrategy, where the load is now aborted) and the NetworkProcess (which holds the parameters and would otherwise act on a degraded load); there is no path to code execution. Realistic impact is enhanced device/user fingerprinting and possible existence-oracle for known file paths, consistent with the medium severity and the CVE’s fingerprinting description.