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

Original Article ↗ Hacker News Discussion ↗

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.