The vulnerable path was WindowGlobalParent::RecvSetCookies, which received a base domain, origin attributes, and cookie data over IPC and forwarded them directly to CookieServiceParent::SetCookies without confirming that the sending content process was actually permitted to operate on that base domain and those origin attributes. Because content processes are untrusted and can be compromised, the parent must independently verify that any domain and partition a child asks to modify corresponds to content the child is legitimately hosting; this invariant — never trust a child-supplied aBaseDomain/aOriginAttributes pair — was violated.

The fix inserts a call to cs->ContentProcessHasCookie(aBaseDomain, aOriginAttributes) and returns IPC_FAIL when the process has no legitimate association with that cookie scope. This works because it re-establishes the parent-side authorization check before the cookie write, so a process can only set cookies for scopes it actually holds.

An attacker who already controls a content process gains the ability to set cookies for base domains and origin partitions outside that process’s legitimate scope, a privilege escalation within the parent (broker) process’s cookie service. This can be leveraged for session fixation or cross-site state manipulation against other origins. The precondition is a pre-existing compromise or memory-corruption foothold in a content process capable of sending IPC.