The replicated BrowsingContext field HistoryID was declared FIELD(HistoryID, nsID, {.mCanSet = CanSet::Unrestricted}). Unrestricted means any process participating in the sync — including an untrusted content/child process — could set HistoryID on a browsing context. Because HistoryID identifies the history/navigation identity of the context, letting a content process set it lets that process desynchronize or spoof the history identity that the parent and other processes rely on, which is a site-isolation violation: a compromised or malicious renderer can assert control over cross-process navigation/history state it should not own.

The one-line patch changes the policy to FIELD(HistoryID, nsID, {.mCanSet = CanSet::ParentOnly}), so only the parent process may set HistoryID. Content processes attempting to set it are rejected by the sync machinery, restoring the invariant that this identity field is authoritative only when written by the trusted parent. This is purely an access-control/policy change on who may write a replicated field; the diff contains no memory-safety sink.

The change concerns the parent/content synchronized state of BrowsingContext; the vulnerability is exploitable from a content process and is categorized by the advisory as a site-isolation issue (moderate). No privilege beyond running in a content process is required to attempt the field set. The gained capability is the ability to set/spoof the HistoryID identity field across processes; this is an authorization/policy weakness, not memory corruption — there is no memory-safety sink in the diff. The precise security impact of a spoofed HistoryID (navigation confusion, history spoofing) is plausible but the concrete exploitation chain is inferred beyond what the one-line policy change proves.