In js::RemapRemoteWindowProxies, each old remote proxy in otherProxies was turned into a deadWrapper and remapped onto target via js::RemapDeadWrapper, but the GC’s finalization observer tables were never told that the old object’s identity was being folded into target. This violated the invariant that every finalization observer must track the live object that supersedes its original target; observers registered against the object that becomes a dead wrapper were left pointing at a stale entry rather than at target. Because the remap is a mitigation-relevant identity change, leaving observers unrelocated is a logic error that lets FinalizationRegistry/WeakRef state diverge from the actual object graph after the transplant.

The fix obtains the GCRuntime via cx->runtime()->gc and, for each proxy, calls gc->relocateFinalizationObserverTarget(ObjectValue(*deadWrapper), ObjectValue(*target)) before RemapDeadWrapper, treating an allocation failure as fatal through oomUnsafe.crash. This restores the invariant so finalization observation follows the object to its new target instead of observing the discarded dead wrapper.

An attacker running script in the content process can drive finalization observer state out of sync with the real object graph across a remote window proxy remap, bypassing a GC mitigation and producing inconsistent FinalizationRegistry/WeakRef behavior. Preconditions are the ability to register a finalization observer on a remote WindowProxy and to induce a remap of that proxy. The metadata classifies this as a high-impact logic error / mitigation bypass in the JavaScript GC component.