CVE-2024-9956 – PassKey Account Takeover in All Mobile Browsers

Original Article ↗ Hacker News Discussion ↗

A newly disclosed vulnerability (CVE-2024-9956) in mobile browsers allowed attackers near a victim’s device to hijack passkey-protected sessions via Bluetooth, undermining claims that passkeys are effectively “phishing proof.” Commenters explain that the bug enabled an attacker-controlled device to sit in the middle of a WebAuthn login, stealing a live session rather than the underlying credential, and potentially taking over accounts depending on site configuration. While major browsers have now patched the flaw, the exchange highlights both the complexity of securing passkey flows (especially QR/BLE-based cross-device login) and the gap between “phishing resistant” marketing and real-world attack surfaces.

Patch status and vendor response

  • Vulnerability was reported in 2024; major fixes shipped later:
    • Chrome: v130 (Oct 2024), Edge: v130-based (Oct 2024).
    • Safari: 18.3 (Jan 2025).
    • Firefox: 136 (Mar 2025).
  • Commenters note Chrome/Google reacted fastest; Firefox was slower mainly because contact with Mozilla apparently only succeeded in Feb 2025.
  • Debate over whether this reflects prioritization, resources, or disclosure timing; consensus that all three big vendors behaved professionally once aware.

Attack mechanics and impact

  • Attack uses browser support for fido: intents plus BLE “caBLE” cross‑device authentication:
    • Victim visits attacker’s site.
    • Site triggers a passkey flow that actually talks (via BLE) to the attacker’s device, which proxies to the real site.
  • Result: attacker doesn’t get the private key or “credential” itself but obtains a valid authenticated session, often enough for account takeover (e.g., register their own passkey).
  • Analogy: more like abusing an SSH agent socket than stealing an SSH private key.

BLE, pairing, and proximity

  • Clarified that traditional Bluetooth pairing is not needed; BLE advertisements are unidirectional broadcasts used to prove proximity and can be relayed (“Bluetooth wormhole”).
  • “Within Bluetooth range” refers to RF distance, not prior pairing; proxying can extend range arbitrarily, constrained mainly by signal strength and practicality.

Fixes and residual attack surface

  • Main browser fix: block navigation to fido: URLs from web content (while still allowing legitimate QR-scanner/OS flows).
  • Some uncertainty remains around QR-based attacks where a page displays a QR that encodes a FIDO URL and BLE is proxied; mitigations rely on UI separation and user training.

Phishing resistance vs. “phishing proof”

  • Discussion around marketing claims:
    • Many materials say “phishing resistant”, not “phishing proof”.
    • Several commenters see this bug as a serious but narrow, non-scalable attack requiring physical proximity and a tailored setup—still far better than password phishing at Internet scale.
    • Others call it an “epic fail” for a system sold primarily on anti‑phishing properties and a reminder that no scheme is truly “unphishable”.

User mitigations and broader attitudes

  • Practical advice:
    • Avoid or distrust cross-device/BLE passkey flows if concerned; prefer on-device passkeys or password-manager-based implementations.
    • Disabling Bluetooth or limiting its use is suggested by some, though others argue that Bluetooth is integral for wearables/headphones and should be hardened, not abandoned.
  • Some participants feel vindicated sticking with strong passwords + hardware/OTP 2FA; others report good experiences with passkeys (especially via password managers) but worry about vendor lock-in and export.