The vulnerable path is DocumentStorageAccess::requestStorageAccess in Source/WebCore/dom/DocumentStorageAccess.cpp. When the Storage Access API request completed with StorageAccessWasGranted::No, the completion handler decided whether to keep (preserve) the calling frame’s transient user activation with the single test ‘shouldPreserveUserGesture = result.promptWasShown == StorageAccessPromptWasShown::No’. The intended invariant is that user activation may only be preserved/consumed across the async round-trip when the caller actually had a user gesture (or the request legitimately did not require one). But the old test keyed only on whether a UI prompt was shown, ignoring whether the original call carried a gesture. A no-prompt, no-gesture rejection therefore left the frame with transient user activation it never legitimately earned. The diff shows the request now captures the gesture state at call time in a renamed enum value ‘hasUserGestureOrNoUserGestureRequired’ (previously the ambiguous ‘HasOrShouldIgnoreUserGesture’), and that value is captured into the completion lambda.

The fix replaces the test with ‘promptNotShownButMayHaveUserGesture = result.promptWasShown == StorageAccessPromptWasShown::No && hasUserGestureOrNoUserGestureRequired == HasUserGestureOrNoUserGestureRequired::Yes’, so activation is only preserved when a gesture (or no-gesture-required condition) was actually present. The enum rename is threaded end-to-end through ChromeClient, WebChromeClient, WebPage, the NetworkConnectionToWebProcess IPC message, WebResourceLoadStatisticsStore, the serialization list and messages.py, but those are mechanical renames; the behavioral fix is the added conjunct. The new layout test confirms the intended behavior: an iframe calls document.requestStorageAccess() with no user gesture, the request is rejected, and in the rejection handler window.open must be blocked (no synthesized activation). Per the CVE text the consequence is that spuriously preserved activation lets a page perform gesture-gated actions such as writing the clipboard without a real user interaction, hence ‘silently hijack clipboard data’.

This is a logic/security-policy bug, not a memory-safety primitive: it grants a page unearned transient user activation, which the CVE ties to silent clipboard access (and generically enables other gesture-gated actions such as popups). There is no memory corruption, OOB, or UAF here, so it does not escalate toward code execution; the realistic outcome is a privacy/integrity violation (reading or overwriting clipboard contents, launching a popup) driven entirely from the WebContent process within the normal renderer sandbox. Severity is medium: user-visible harm without a crash or sandbox escape.