← WebKit — 2026-W35

`075a8d041b63a6ae6a4cc690e2f96dd635914df9` window.open() with noopener should not always return null

severity medium class PolicyBypass confidence 0.6 signal score 8.17 Source/WebCore/loader patch-now

view commit ↗

Primitive: window.open with noopener still set an opener on a reused existing frame, leaking an opener reference
Triage note: createWindow now gates frame->updateOpener(openerFrame) behind !features.wantsNoOpener() and computes shouldReturnNull so noopener correctly suppresses the opener relationship on the existing-frame reuse path. This fixes an attacker-reachable noopener isolation bypass (opener access / reverse-tabnabbing).

Structural signals: smartptr_member_added (+4.87), area:Source/WebCore/loader (+2.0), surgical (+1.3)

Commit message

window.open() with noopener should not always return null
https://bugs.webkit.org/show_bug.cgi?id=322591

Reviewed by Chris Dumez.

The name lookup in "the rules for choosing a navigable" ignores noopener, so
window.open() can reuse an existing navigable when noopener is set. Two things
were wrong when it did: the reused navigable got its opener set to the caller,
and _self returned null instead of that navigable. _parent and _top were already
correct, as open() resolves them without reaching createWindow().

Spec changes: https://github.com/whatwg/html/pull/12845

Tests: imported/w3c/web-platform-tests/html/browsers/the-window-object/window-open-noopener-existing-iframe.html
       imported/w3c/web-platform-tests/html/browsers/the-window-object/window-open-noopener.html

Tests upstream: https://github.com/web-platform-tests/wpt/pull/62213

Canonical link: https://commits.webkit.org/319932@main

Before / after

Loading diff…

On This Page

075a8d041b63a6ae6a4cc690e2f96dd635914df9 window.open() with noopener should not always return null

Commit message

Before / after

`075a8d041b63a6ae6a4cc690e2f96dd635914df9` window.open() with noopener should not always return null