How Malicious Browser Extensions Can Hijack WebAuthn and Bypass Passkeys

TLDR: Researchers at DEF CON 2025 demonstrated that browser extensions can intercept and manipulate the WebAuthn API to perform unauthorized authentication. By hooking navigator.credentials.create and navigator.credentials.get, an attacker can proxy requests and forge responses, effectively bypassing the security guarantees of passkeys. This attack highlights that the browser acts as a trust anchor, and if that anchor is compromised, the entire authentication flow is subverted.

Passkeys were supposed to be the death knell for credential stuffing and phishing. By moving the authentication secret from a shared, guessable string to a hardware-backed, origin-bound cryptographic key, the industry promised a future where account takeovers were significantly harder to execute. Yet, the security of this entire model rests on a single, often overlooked assumption: the browser itself is a secure, untampered mediator.

The research presented at DEF CON 2025 shatters this assumption. It turns out that if an attacker can execute code within the browser context—specifically through a malicious extension—they can turn the WebAuthn API against itself.

The Mechanics of the Hijack

The WebAuthn flow relies on the browser to act as a trusted intermediary between the user's authenticator and the relying party (the server). When a user initiates a registration or authentication event, the website calls the Web Authentication API. The browser then handles the communication with the authenticator, prompts for user verification (like Touch ID or a PIN), and returns the signed assertion to the website.

The vulnerability lies in the fact that the browser exposes these APIs to the page context. A malicious extension, which operates with high privileges in the browser, can hook these functions before they ever reach the legitimate browser implementation.

By overwriting navigator.credentials.create and navigator.credentials.get, an attacker can intercept the entire handshake. In the registration flow, the extension can silently generate its own key pair, store the private key on an attacker-controlled endpoint, and return a forged response to the website. The website, believing it has successfully registered a legitimate passkey, stores the attacker's public key. From that point forward, the attacker has full, persistent access to the account.

Technical Implementation

The attack is surprisingly straightforward for anyone familiar with browser extension development. Because extensions can inject scripts into the page context, they can easily replace the native WebAuthn methods.

// Simplified example of hooking the credentials API
const originalCreate = navigator.credentials.create;

navigator.credentials.create = async (options) => {
    // Intercept the request, proxy to attacker, or forge response
    console.log("Intercepted WebAuthn create request", options);
    // Return a forged credential object
    return forgeCredential(options);
};

The researchers demonstrated that this isn't just a theoretical exercise. By using a simple Node.js server to store the intercepted credentials, they could successfully register a passkey on a target site without the user ever knowing. The "Silent Mode" of their proof-of-concept extension allowed them to perform these actions without triggering any visible UI prompts, making the attack invisible to the victim.

Real-World Pentesting and Impact

For a pentester or bug bounty hunter, this research changes the threat model for client-side security. If you are assessing an application that relies heavily on WebAuthn for high-value transactions, you must consider the browser environment as part of the attack surface.

During an engagement, if you can achieve XSS or convince a user to install a malicious extension, you are no longer limited to stealing session cookies. You can effectively own the user's identity by registering your own passkey. This is a critical finding for OWASP A07:2021 – Identification and Authentication Failures.

The impact is total account takeover. Unlike a stolen password, which can be reset, a registered passkey provides the attacker with a persistent, hardware-backed authentication method that is difficult for the user to detect or revoke without administrative intervention.

Defending the Trust Anchor

Defending against this requires a shift in how we view browser security. Developers cannot rely solely on the browser to enforce security boundaries. While you cannot prevent a user from installing a malicious extension, you can make it significantly harder for an attacker to operate.

Implement a strict Content Security Policy (CSP) to prevent the injection of unauthorized scripts. Furthermore, utilize Trusted Types to sanitize DOM sinks and prevent DOM-based XSS, which is a common vector for injecting the malicious code needed to hook the WebAuthn API.

For enterprise environments, the solution is tighter control over the browser. Use Chrome Enterprise or Microsoft Edge management policies to enforce an allowlist of extensions. If an extension isn't explicitly approved, it shouldn't be running.

The browser is the new operating system. It handles our most sensitive secrets, our identity, and our financial transactions. We have spent years hardening the server-side, but this research proves that the client-side, specifically the browser's role as a trust anchor, is the next major battleground. If you aren't auditing the extensions running in your environment, you are leaving the front door wide open.