◆ WebKit WeeklyBeta
← All reports

Popunder bypass via overlappping transient activations

LowWebCore FrameLoader —LogicError

CVE: CVE-2026-43804 · Safari 26.6 · Released July 27, 2026 Impact: Visiting a website may lead to an app denial-of-service Apple's description: This issue was addressed through improved state management. Credit: Heiko Kiesel of SEEMOO, TU Darmstadt

Severity: Low | Component: WebCore FrameLoader — createWindow() | a37a650 | Bugzilla 316816

Low — memory corruption도 없고, cross-origin read도 없으며, sandbox 경계를 넘는 동작도 없습니다. 다만 웹 콘텐츠 쪽에 조건 없는 raise-that-window primitive가 그대로 넘어갑니다. 앞을 막고 있던 guard가 "사용자가 방금 조작했는가"가 아니라 "호출한 페이지가 화면에 떠 있는가"만 묻고 있었기 때문입니다.

어떤 브라우저든 페이지가 스스로 할 수 있는 동작과 사용자가 요청했을 때만 허용되는 동작 사이에 선을 긋습니다. 윈도우 관리는 확실히 후자 쪽에 속합니다. top-level window를 이동하거나 크기를 바꾸거나 닫거나 앞으로 끌어올리는 동작은 모두 실제 상호작용 이후에만 허용되어야 하며, HTML user-activation 모델이 그 규칙을 집행합니다. window.open() 호출이 WebContent process에서 도달하는 지점이 바로 WebCore::createWindow()인데, 이 함수에는 성격이 전혀 다른 두 개의 출구가 있습니다. 하나는 새 browsing context를 만드는 경로이고, 다른 하나는 이름으로 기존 context를 찾아 재사용하는 경로입니다. 여기서 지켜져야 할 invariant는 두 출구가 동일한 수준으로 gate되어야 한다는 점입니다. 둘 다 사용자 눈에 똑같이 드러나는 동작이기 때문입니다.

관전 포인트: 페이지와 그 페이지가 연 popup이, 사용자 조작 없이 아무 때나 서로의 앞뒤 순서를 바꿀 수 있었습니다. 사용자가 보고 있는 창 뒤로 다른 창을 숨기거나, 두 창 사이에서 focus를 계속 튕기게 만들기에 충분한 수준입니다.

Source/WebCore/loader/FrameLoader.cpp

if (!request.frameName().isEmpty() && !isBlankTargetFrameName(request.frameName())) {
if (RefPtr frame = openerFrame.loader().findFrameForNavigation(request.frameName(), protect(openerFrame.document()).get())) {
if (!isSelfTargetFrameName(request.frameName())) {
 
- if (RefPtr page = frame->page(); page && isInVisibleAndActivePage(openerFrame))
+ RefPtr openerWindow = openerFrame.window();
+ if (RefPtr page = frame->page(); page && isInVisibleAndActivePage(openerFrame) && openerWindow && openerWindow->hasTransientActivation())
page->chrome().focus();
}
if (!features.wantsNoOpener())

Tools/TestWebKitAPI/Tests/WebKit/WKWebView/VerifyUserGestureFromUIProcess.mm

+TEST(VerifyUserGesture, PopunderPreventedViaDualEventListeners)
+{
+ auto openerHTML = "<script>"
+ "window.name = 'opener';"
+ "let popup;"
+ "let opened = false;"
+ "addEventListener('pointerdown', () => {"
+ " if (!opened) {"
+ " opened = true;"
+ " popup = window.open('https://domain2.com/popup');"
+ " }"
+ "});"
+ "addEventListener('click', () => {"
+ " if (popup && popup.refocusOpener) popup.refocusOpener();"
+ "});"
+ "</script>"_s;
+ auto popupHTML = "<script>"
+ "function refocusOpener() { window.open('', 'opener'); }"
+ "</script>"_s;
...
+ __block bool focusCalled = false;
+ uiDelegate.get().focusWebView = ^(WKWebView *) {
+ focusCalled = true;
+ };
+
+ [openerWebView mouseDownAtPoint:CGPointMake(50, 50) simulatePressure:NO];
+ [openerWebView mouseUpAtPoint:CGPointMake(50, 50)];
+ [openerWebView waitForPendingMouseEvents];
...
+ EXPECT_FALSE(focusCalled);
+}
Patch Details

기능적으로 바뀐 부분은 한 줄입니다. WebCore::createWindow()의 named-target branch, 즉 request.frameName()이 비어 있지 않고 _blank도 아니며 openerFrame.loader().findFrameForNavigation()을 통해 이미 존재하는 frame으로 해석되는 경우에 들어가는 분기가 대상입니다. 이 분기에서 page->chrome().focus() 앞을 막는 guard에 조건 두 개가 추가되었습니다. 패치는 RefPtr openerWindow = openerFrame.window();를 if-initializer 밖으로 끌어올리고, 조건을 page && isInVisibleAndActivePage(openerFrame) && openerWindow && openerWindow->hasTransientActivation()으로 확장했습니다. 결과적으로 대상 창을 앞으로 끌어올리려면, window.open()을 호출한 창이 현재 살아 있는 transient activation을 보유하고 있어야 합니다.

여기서 패치가 하지 않은 일에 주목할 필요가 있습니다. activation을 요구하기만 하고 consume하지는 않습니다. commit message는 이것이 release branch(305413.1061@safari-7624.5-branch)에 반영된 버전과 의도적으로 다른 선택임을 명시하고 있으며, 그쪽 버전은 consume을 수행했습니다. trunk에서 이 지점에 consume을 넣으면 imported/w3c/web-platform-tests/html/browsers/windows/consume-user-activation/window-open.html이 깨집니다. 311026@main에서 이미 window.open()의 consumption 범위를 새 browsing context를 실제로 생성하는 경우로 좁혀두었기 때문인데, 이는 spec의 "rules for choosing a navigable"를 따른 결과입니다. 이름으로 재사용하는 경로는 아무것도 생성하지 않으므로, activation을 소모해서는 안 됩니다.

diff의 나머지는 regression test인 TEST(VerifyUserGesture, PopunderPreventedViaDualEventListeners)입니다. 이 테스트는 보고된 우회 형태를 처음부터 끝까지 그대로 재현합니다. domain1.com의 opener 페이지 위에서 실제 mouseDown/mouseUp 쌍이 발생하고, 이 페이지는 스스로를 opener로 명명한 뒤 pointerdown 핸들러에서 domain2.com의 popup을 엽니다. 이어서 click 핸들러에서, 즉 같은 물리적 클릭에서 파생된 다른 이벤트에서 popup 쪽으로 진입해 window.open('', 'opener')를 실행합니다. 검증 조건은 opener의 focusWebView UI-delegate callback이 단 한 번도 호출되지 않는 것입니다.

Background

user-activation 모델. 브라우저는 스스로 실행되는 스크립트와 사용자 입력의 직접적인 결과로 실행되는 스크립트를 구분합니다. 클릭이나 키 입력 같은 상호작용은 창마다 유지되는 짧은 수명의 플래그, 즉 transient activation을 설정합니다. gate가 걸린 API들은 사용자가 인지할 만한 동작을 수행하기 전에 이 플래그를 조회합니다. LocalDOMWindow::hasTransientActivation()은 해당 플래그가 현재 유효한지를 반환하고, consumeTransientActivation()은 이를 소모합니다. 그래서 한 번의 상호작용은 정확히 한 번의 gated action만 승인하게 됩니다.

activation이 전파되는 범위. 문서가 activation을 받으면, HTML 모델은 이를 상위 frame과 같은 frame tree 안의 same-origin 하위 frame으로 전파합니다. 다만 다른 top-level browsing context로는 넘어가지 않습니다. 따라서 새로 열린 popup은 자기 activation 없이 시작하며, 사용자가 popup을 직접 조작할 때에만 activation을 획득합니다.

이름을 지정한 window targeting. window.open(url, name)은 무조건 창을 새로 만들지 않습니다. 먼저 이름이 일치하는 기존 browsing context를 찾는데, 이 조회를 FrameLoader::findFrameForNavigation()이 담당하며 호출자가 접근할 수 있는 frame으로 범위가 제한됩니다. _blank와 _self 키워드는 isBlankTargetFrameName()과 isSelfTargetFrameName()이 따로 인식해 각자의 경로에서 처리합니다.

createWindow(). window.open() 뒤에 있는 WebCore 함수입니다. 반환 타입은 std::pair<RefPtr<Frame>, CreatedNewPage>인데, 이름이 지정된 target이 이미 존재하면 그 frame을 재사용하면서 새 page가 생성되지 않았음을 보고하고, 그렇지 않으면 embedder에게 생성을 요청합니다. 두 결과는 함수 내부에서 구조적으로 다른 경로를 거칩니다.

Chrome::focus()와 그 앞의 predicate. Chrome::focus()는 특정 Page를 담고 있는 창을 앞으로 가져와 달라고 embedder에 요청하는 WebCore 측 호출이며, API 테스트에서는 TestUIDelegate의 focusWebView block으로 드러납니다. isInVisibleAndActivePage(frame)은 page 상태에 대한 predicate로, 해당 frame의 page가 현재 보이는 상태이고 active window 안에 있는지를 판정합니다.

Popunder. 콘텐츠가 두 번째 창을 연 뒤 원래 창이 그 위로 올라오도록 만드는 창 순서 조작 기법입니다. 새 창은 열린 채로 남지만, 사용자가 실제로 보고 있는 창 뒤에 가려집니다.

RefPtr. WebKit의 reference-counted smart pointer입니다. openerFrame.window()는 frame의 LocalDOMWindow를 반환하며, 여기서는 검사가 진행되는 동안 로컬 RefPtr로 보유됩니다.

Analysis

capability 검사가 있어야 할 자리를 ambient-authority 검사가 대신 차지하고 있던 사례입니다.

  Before:                                  After:
  window.open('', 'opener')                window.open('', 'opener')
    └─► findFrameForNavigation()             └─► findFrameForNavigation()
          └─► isInVisibleAndActivePage?            └─► isInVisibleAndActivePage?
                 "am I on screen?"  ── yes ─┐            AND hasTransientActivation?
                                            │               "did a user touch ME?"
                 ┌──────────────────────────┘                    │
                 ▼                                   popup: no ──┴──► blocked
            chrome().focus()  ← no gesture required

다이어그램의 왼쪽 열이 패치 이전 인가 로직의 전부입니다. isInVisibleAndActivePage(openerFrame)이 답하는 질문은 "호출한 페이지가 현재 화면에 있고 active window 안에 있는가"입니다. 이것은 호출자가 우연히 놓인 환경을 기술할 뿐, 호출자가 보유한 권한이 아닙니다. 공격자 페이지가 방금 열어서 맨 앞에 놓여 있는 popup이라면, 이 질문의 답은 간단히 yes이고 그 상태가 계속 유지됩니다. predicate는 frame 하나를 받아 거기서 도달 가능한 상태를 읽을 뿐이며, 특정 사용자 상호작용에 묶인 요소는 아무것도 없습니다. 오른쪽 열은 빠져 있던 질문을 추가하는데, popup은 구조상 이 질문에 no로 답할 수밖에 없습니다.

동작 메커니즘은 여기서 곧바로 따라옵니다. 이름이 기존 frame으로 해석되는 순간 createWindow()는 named-target branch로 단락되어 들어갑니다. 그래서 page를 생성하는 경로를 지키는 popup-blocking 검사나 새 창용 activation 검사는 아예 조회되지 않습니다. 결과적으로 이 호출은 순수한 "저 창을 앞으로 올려라" primitive로 축소되며, findFrameForNavigation()을 통해 target을 이름으로 해석할 수 있는 frame이라면 누구나 사용할 수 있게 됩니다. 실제로는 공격자 자신의 browsing-context group 안에 있는 창들, 즉 스스로 만들어낸 opener/openee 체인이 그 대상입니다. popup에서 window.open('', 'openerName')을 호출하고, URL을 비워 두어 navigation조차 발생하지 않게 하면, 그것으로 exploit은 끝입니다.

제목의 "overlapping transient activations"는 보고자가 이 코드의 이전 상태를 상대로 찾아낸 구체적인 우회를 가리키며, regression test가 이를 정확히 인코딩하고 있습니다. 물리적인 클릭 한 번은 activation을 실어 나르는 단일 이벤트가 아니라 하나의 연속된 시퀀스입니다.

  1. opener에서 pointerdown이 발생합니다. 핸들러가 window.open('https://domain2.com/popup')을 호출하는데, 이는 실제로 새 browsing context를 생성하는 경우이므로 activation을 consume합니다.
  2. popup이 로드되어 스크립트를 실행하고 refocusOpener()를 정의합니다.
  3. opener에서 click이 발생합니다. 물리적으로는 동일한 상호작용이지만 별개의 이벤트이며, opener의 창에 transient activation을 새로 발급합니다.
  4. opener의 click 핸들러가 popup 쪽으로 진입해 popup.refocusOpener()를 호출하고, 그 안에서 window.open('', 'opener')가 실행됩니다.
  5. 이 호출은 기존 opener frame을 이름으로 해석하고, 생성 경로는 완전히 건너뛴 채 page->chrome().focus()를 호출합니다. opener가 popup 위로 올라오면서 popunder가 성립합니다.

popup 생성 시점에 적용되는 consumption 기반 완화책은 1단계에서 이미 충족되고 소모됩니다. 그리고 3단계에서 페이지는 어차피 새 토큰을 다시 받게 됩니다. fix가 상위 지점이 아니라 focus를 호출하는 자리에 놓인 이유가 여기에 있으며, consume이 아니라 require가 올바른 동사인 이유이기도 합니다. 4단계의 호출은 popup의 realm에서 시작되는데, popup의 창은 activation을 한 번도 보유한 적이 없습니다. activation은 frame tree 안에서만 전파되고 top-level window를 절대 넘지 않기 때문입니다. 따라서 요구만 해도 popunder는 consume과 똑같은 강도로 차단되며, spec 기준으로 이 경로가 소모할 이유가 없는 토큰을 쓰지 않아도 됩니다.

영향 범위는 제한적입니다. 문제의 호출은 WebContent process에서 시작되어 Chrome::focus() → ChromeClient::focus()를 거쳐 UI process로 전달되고, 실제 raise는 UI process가 수행합니다. 공격자에게 유리한 방향으로 sandbox 경계가 넘어가지도 않고, WebContent process에 추가 capability가 들어오지도 않습니다. UI process는 그저 정상적인 UI 동작을 수행할 뿐이며, 다만 그것을 요청할 자격이 없던 호출자를 위해 수행하게 됩니다. 공격자가 얻는 것은 자기 창 집합에 대한 임의의 z-order 제어입니다. 광고나 phishing 표면을 popunder로 배치하거나, focus를 가로채거나, 루프로 돌려 focus를 계속 튕기게 만들 수 있습니다. Apple의 advisory가 app denial-of-service로 분류한 것이 마지막 경우입니다. memory-safety, cross-origin 데이터 접근, sandbox 측면의 결과는 없습니다.

권한이 필요한 cross-window raise가 "내 페이지가 보이고 active한가"라는 ambient 상태에 gate되어 있었습니다. popup이 기본적으로 충족하는 조건이며, popup이 절대 보유할 수 없는 사용자 상호작용 토큰이 아니었습니다.

Insight

이 commit은 release branch에서는 올바랐던 fix가 trunk로 forward-port되면서 미묘하게 어긋나는 사례이기도 합니다. branch 버전은 activation을 consume했습니다. 다만 trunk에서는 그 사이에 window.open()의 consumption 의미가 새 browsing context 생성에 한정되도록 좁혀졌고(311026@main), 이름으로 재사용하는 경로에서 consume하면 WPT conformance test가 깨지게 됩니다. trunk 형태를 지탱하는 근거는 정책적 판단이라기보다 threat model 관찰에 가깝습니다. popup의 principal은 애초에 토큰을 획득할 수 없으므로, 여기서는 require-check가 consume-check와 정확히 같은 강도를 갖습니다. 여기서 일반화할 수 있는 원칙이 나옵니다. consume은 spec이 지시하는 자리에서만 수행하고, 공격자의 principal이 해당 권한을 획득할 수 없음을 증명할 수 있다면 단순한 요구 검사를 택하는 편이 낫습니다.

Audit directions