The vulnerable path is the nsDocShellLoadState::nsDocShellLoadState constructor that reconstructs a load request from IPC data supplied by a content process via aActor.

Before the fix, this constructor validated the triggering principal but never checked the combination of a javascript: target URI with a triggering remote type belonging to a content process, so a javascript: load could be attributed to and execute across a process boundary. The violated invariant is that a javascript: “navigation” must remain intra-process — it must run only in the same content process that legitimately triggered it — because it executes script directly against the target document.

The fix adds an explicit guard: if mURI->SchemeIs("javascript") and mTriggeringRemoteType != NOT_REMOTE_TYPE, the parent treats the message as malformed, calls aActor->FatalError, and aborts. This works because a genuine same-process javascript: load never needs to cross a process boundary, so rejecting cross-process javascript: loads outright closes the injection channel without breaking legitimate flows.

An attacker who already controls one content process gains the ability to execute javascript: in another origin’s or process’s document context, a universal cross-site-scripting / process-isolation bypass driven from the privileged parent’s load logic. The critical precondition is prior code execution or message-forging capability in a content process; the flaw itself lives in the trusted parent process that arbitrates cross-process loads. This turns a single compromised renderer into cross-origin script injection, which is why the impact is rated critical and public exploit code exists.