CVE-2026-64730

Overview

Impact:

Description: Visiting a website that frames malicious content may lead to UI spoofing

Researchers: Kagami Rosylight of Mozilla

Key insight. Fullscreen Keyboard Lock was on by default, letting framed/hostile content capture the very keys (Escape/system chords) a user needs to escape a spoofed fullscreen; disabling it by default removes that trapping primitive.

Patch Details

diff --git a/Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml b/Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
index f10613bab755..a0e2bf9ec94c 100644
--- a/Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
+++ b/Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
@@ -3552,18 +3552,18 @@ FullScreenEnabled:
 
 FullScreenKeyboardLock:
   type: bool
-  status: stable
+  status: unstable
   category: dom
   humanReadableName: "Fullscreen API based Keyboard Lock"
   humanReadableDescription: "Fullscreen API based Keyboard Lock"
   condition: ENABLE(FULLSCREEN_API)
   defaultValue:
     WebKitLegacy:
-      default: true
+      default: false
     WebKit:
-      default: true
+      default: false
     WebCore:
-      default: true
+      default: false
 
 FullscreenRequirementForScreenOrientationLockingEnabled:
   type: bool

Background

Advisory: Apple Security Advisory

Terminology

• Fullscreen Keyboard Lock — The Keyboard.lock() API lets a fullscreen page capture normally reserved keys (Escape, system chords) instead of letting the browser/OS handle them.
• UI spoofing — Presenting fake, trusted-looking interface (e.g. a browser chrome or OS prompt) to deceive the user, especially when they cannot leave the spoofed view.
• Feature preference / status — WebKit gates features behind UnifiedWebPreferences flags; ‘unstable’ + default false disables a capability by default.

Root Cause Analysis

The shown diff is a WebKit feature-preference change, not the keyboard-lock logic itself, so the mechanism below is partly inferred from the flag’s purpose and the advisory (‘framing malicious content may lead to UI spoofing’). In UnifiedWebPreferences.yaml the FullScreenKeyboardLock preference — the Fullscreen API-based Keyboard Lock feature (Keyboard.lock()) — was marked status: stable and defaulted to true for WebKitLegacy, WebKit and WebCore. Keyboard Lock lets a page in fullscreen intercept normally reserved keys (including Escape and system chords) so they are delivered to the page rather than the browser/OS. The problem, per the advisory, is that when a site FRAMES malicious content and that content enters fullscreen with keyboard lock, it can capture the keys a user would use to leave fullscreen or regain trusted UI, so the framed content can present a spoofed, inescapable full-screen interface (UI spoofing) — the violated invariant is that the user must always be able to exit fullscreen and reach trusted browser UI, which keyboard lock in a framed/hostile context defeats. The fix flips the feature to status: unstable and defaultValue false across WebKitLegacy/WebKit/WebCore, disabling Fullscreen Keyboard Lock by default so pages can no longer trap those keys until the feature is reworked. The restored behavior is that Escape/system keys are not silently captured by (framed) fullscreen content by default. This is a policy/hardening change (turn a risky capability off by default); the keyboard-lock enforcement code that would gate framed use is not in this diff.

Attack Path

1. Frame malicious content

A page the user visits embeds attacker-controlled content in a frame.

2. Enter fullscreen with keyboard lock

The framed content requests fullscreen and uses the Keyboard Lock API to capture reserved keys including Escape.

3. Trap the user

Because Escape and system chords are intercepted, the user cannot easily exit fullscreen or reach trusted browser UI.

4. Spoof the UI

The full-screen framed content renders a fake browser/OS interface (address bar, prompts) to phish credentials or mislead the user.

Impact Assessment

A UI-spoofing / user-deception issue in the WebContent process with no memory corruption: framed content could use fullscreen keyboard lock to trap the user and present a spoofed interface. Impact is phishing/social-engineering rather than code execution; the mitigation simply disables the risky capability by default.

Audit Directions

Keyboard lock gating

Audit the Keyboard.lock() implementation (grep for keyboardLock / KeyboardLock / Escape handling in fullscreen) for whether it distinguishes top-level vs framed/cross-origin fullscreen and always honors an escape gesture.

Default-on fullscreen capabilities

Review other fullscreen-related preferences and pointer/keyboard capture features for default-true settings usable by framed content to trap input.

Changed Functions

Files Changed

Source Files

• Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml