The patch modifies DocumentWriter::begin, which is responsible for initializing a new Document’s security state as a load commits.

Before the fix, the code unconditionally inherited the Document’s policy container (which carries the Content Security Policy, referrer policy, and related security context) from currentHistoryItem whenever that history item existed and had a stored policy container: ‘if (currentHistoryItem && currentHistoryItem->policyContainer())’.

The invariant that was violated is that a policy container should only be resurrected from a HistoryItem when the navigation is actually a history traversal (Back/Forward), where restoring the exact prior security context is correct. For all other navigation types the new document must derive its policy container from the correct live source (for srcdoc iframes and other locally-generated documents, from the parent/initiator document). Because the guard did not check the navigation type, an iframe that happened to have a stale or attacker-influenced currentHistoryItem could have its CSP overwritten by whatever policy container was cached in that history item, rather than inheriting the parent frame’s restrictive CSP.

The included layout test demonstrates the concrete failure: an iframe with sandbox=‘allow-scripts’ whose srcdoc is assigned dynamically (rather than present as an initial attribute) would end up NOT enforcing the parent’s ‘script-src self’ policy, so a dynamic import() of a cross-origin module that should be blocked was instead allowed to load.

The fix restores the invariant by gating the history-based inheritance on ’triggeringAction && triggeringAction->type() == NavigationType::BackForward’, so history policy containers are only reapplied during genuine back/forward navigations; every other case falls through to the normal initiator-based inheritance and the parent CSP is correctly propagated into the srcdoc document.

The updated WPT expectation file (inheritance-from-initiator) flipping four FAIL results to PASS confirms the general bug: policy/context inheritance was being taken from the wrong source (history ‘p’ instead of the initiator ‘a’/‘b’) for location changes, window.open, and form submissions.

This is a logic/security-policy bypass, not a memory-corruption primitive: the flaw causes the wrong CSP (or none) to be enforced on locally-generated documents such as dynamically-assigned srcdoc iframes. It does not by itself grant read/write of memory, but it neutralizes a site’s script-src/default-src defenses, so any secondary HTML-injection or content-injection vector on the victim site can escalate into full script execution in that document’s context, enabling data theft or cross-origin resource loads the policy was meant to block. The effect is confined to the WebContent process security model (same-origin/CSP enforcement); there is no direct sandbox escape or process-privilege gain from this bug alone.