← WebKit — 2026-W37
acb9b59d02a814f1ce57af6cca4a9e280dca877e [WebKit Process Model] ProvisionalPageProxy::didReceiveSyncMessage forwards unallowlisted sync messages to target WebPageProxy
severity medium
class PolicyBypass
confidence 0.5
signal score 6.17
Source/WebKit/UIProcess
Primitive: Provisional (uncommitted) process could trigger arbitrary WebPageProxy sync message handlers
Triage note: ProvisionalPageProxy::didReceiveSyncMessage previously forwarded any non-BackForwardList sync message to page->didReceiveSyncMessage; it now allowlists only ShouldGoToBackForwardListItemSync and WebBackForwardList, logging the rest. This restricts the sync-IPC surface a not-yet-committed process can reach, an authorization hardening rather than a demonstrated memory bug.
Triage note: ProvisionalPageProxy::didReceiveSyncMessage previously forwarded any non-BackForwardList sync message to page->didReceiveSyncMessage; it now allowlists only ShouldGoToBackForwardListItemSync and WebBackForwardList, logging the rest. This restricts the sync-IPC surface a not-yet-committed process can reach, an authorization hardening rather than a demonstrated memory bug.
Structural signals: smartptr_member_added (+4.87), surgical (+1.3)
Commit message
[WebKit Process Model] ProvisionalPageProxy::didReceiveSyncMessage forwards unallowlisted sync messages to target WebPageProxy
https://bugs.webkit.org/show_bug.cgi?id=315484
rdar://176912339
Reviewed by Ben Nham.
ProvisionalPageProxy::didReceiveSyncMessage special-cased two
synchronous message names and then forwarded every other
Messages::WebPageProxy::* sync message to the target tab's
WebPageProxy via a catch-all page->didReceiveSyncMessage(...) call.
This is asymmetric with its async sibling
ProvisionalPageProxy::didReceiveMessage, which allowlists the
specific messages a provisional page may legitimately send and
drops everything else.
During a process-swap back navigation, this allowed a WebContent
process holding a ProvisionalPageProxy for another tab to dispatch
RunJavaScriptAlert/Confirm/Prompt, HandleSynchronousMessage,
RequestDOMPasteAccess, CreateNewPage, PrintFrame, and other
synchronous handlers on that tab's WebPageProxy while the tab's
m_mainFrame->url() and pageLoadState() still reflected a
cross-site origin committed in a different process.
Give the synchronous dispatcher the same explicit-allowlist
treatment as the asynchronous one: keep the existing handlers for
BackForwardGoToItem and DecidePolicyForNavigationActionSync,
forward ShouldGoToBackForwardListItemSync (which the asynchronous
allowlist already names) and the read-only WebBackForwardList
queries to the page, and drop every other synchronous WebPageProxy
message with a ProcessSwapping log entry instead of dispatching it.
* Source/WebKit/UIProcess/ProvisionalPageProxy.cpp:
(WebKit::ProvisionalPageProxy::didReceiveSyncMessage):
Identifier: 316606.686@safari-7625-branch
Before / after
Loading diff…
On This Page