Recap of Our “Passkeys Pwned” Talk at DEF CON

What the ”Passkeys Pwned” talk is and isn’t about, and what it reveals about the importance of correct implementation of the standard

The Passkeys Pwned Talk Summary

As outlined in the DEF CON abstract below, the Passkeys Pwned attack highlights a passkey implementation flaw, specifically that of WebAuthn in the registration and authentication process. The Passkey Pwned attack is not actually a cryptographic flaw, nor is it a criticism of the FIDO Alliance. This information was detailed in both the DEF CON presentation and technical blog.

DEF CON 33 Passkeys Pwned Talk Abstract

“This presentation demonstrates how attackers can proxy WebAuthn API calls to forge passkey registration and authentication responses. We’ll showcase this using a browser extension as an example, but the same technique applies to any website vulnerable to client-side script injection, such as XSS or misconfigured widgets”

The Passkeys Pwned attack highlights that regular web threats — such as CDN attacks, XSS and browser extensions — can lead to unauthorized access via passkeys without requiring any endpoint, OS or browser compromise. In today’s world, every website loads resources from third-party CDNs, leading to a major supply chain risk.

This is reminiscent of the Ledger Connect Kit CDN and NPM vulnerability in December 2023, where malicious code was injected into decentralized apps, allowing attackers to drain crypto wallets without needing to compromise the user’s device. Just this week, another malware injection attack on NPM packages impacted over 2.6 billion downloads, highlighting the inevitability of supply chain attacks on the web.

The demo videos below show how the Passkey Pwned attack can be delivered via a browser extension (as shown at DEF CON) or by adding a piece of code in the console without a browser extension.

Given the level of impact Passkeys Pwned can have on enterprises, we felt that it was important to clarify and re-iterate the nature of the attack for the benefit of security practitioners. Contrary to what is shared in the Ars Technica report, the Passkeys Pwned attack does not require “endpoint compromise,” nor does it involve a cryptographic flaw in the FIDO2 protocol.

Again, the Passkeys Pwned attack is an implementation flaw that leverages common web threats to intercept the passkey registration and authentication flow.

To allay any confusion, here’s a summary of what the Passkey Pwned talk is and isn’t about:

Will the Passkeys Pwned Attack work if I have a pre-registered passkey?

The Passkeys Pwned attack can indeed still work if the victim previously registered their passkeys — but not by stealing the existing private key. Instead, as detailed in the DEF CON presentation and technical blog, the attacker:

  1. Force fails the passkey authentication
  2. Downgrades the user to “password authentication”
  3. Forces user to re-register their passkey, which is then intercepted by the attacker with the Passkeys Pwned attack

Thus, this allows attackers to gain unauthorized access to passkey-authenticated SaaS apps without needing to steal any pre-existing private key stored in the victim’s authenticator.

Learning from the Past

Looking into history, there have been many parallels through which new standards are improved through the trials of time in collaboration with the research community.

SAML introduced assertion encryption because browsers were untrusted carriers. OIDC adopted the Authorization Code Flow with PKCE to keep tokens out of front-channel pages.

The same principle applies to HTTP-only cookies. They exist for one reason: in a “perfect world” scripts wouldn’t inject into the page and wouldn’t steal sensitive tokens. Unfortunately, in the real world, script injections (via XSS or compromised third-party code) is a common occurrence. Thus, browsers now directly manage them to keep authentication tokens away from page-accessible JavaScript. The need for HTTP-only cookies serves as a reminder that it is naive to trust page context.

No authentication system is built perfectly from day one. Given the nascency of passkey adoption, there are bound to be implementation flaws — and one of them is pushing sensitive workflows into the browser environment without taking into account how attackers can inject themselves into the workflow. This is the vulnerability that the Passkeys Pwned attack exploits.

Thus, while there is nothing wrong with the passkey encryption technology itself, it is a shared responsibility between industry consortiums, application developers and enterprises to fix this implementation flaw in order for passkeys to realize its full potential to deliver the security it was designed to provide.

How to Mitigate the Passkeys Pwned Attacks

While it may take some time for passkeys implementation best practices to mature, there are several things enterprises can do in the meantime to mitigate the Passkeys Pwned attack:

Educate Employees on Passkeys

Given that the Passkeys Pwned attack exploits the victim’s belief that equates biometric requests with security, it is critical to raise awareness among employees on how passkeys work and how it can be exploited by the Passkeys Pwned attack. This should include actionable guidance such as escalating to security/IT teams if a previously registered passkey repeatedly fails.

Implement Warning Signs in Workflow

While dedicated security training is essential, it is also important to consistently remind users of the risk of a Passkey Pwned attack in their regular workflow. For example, security teams can push a pop-up to remind users to disable any unauthorized browser extensions when registering a new passkey.

Enable MFA

As with many identity attacks, setting up MFA for IDPs that leverage passkeys as an authentication method can add an extra layer of defense. Where possible, a step-up MFA that triggers upon unusual passkey usage patterns — such as logins from a new device, location or multiple passkey failures — may be a good way to balance user experience and protection against the Passkey Pwned attack.

Audit Browser Extensions

Given that the attack can also be delivered through browser extensions, it is critical for enterprises to conduct a thorough audit of the extensions employees are using. This includes performing dynamic analysis to understand each extension’s behavior at runtime and blocking extensions that inject suspicious scripts onto login pages. Last but not least, this audit should be conducted every time there is an update to an extension to protect against trusted extensions that turn malicious.

Harden the Browser

Inspect and block all malicious scripts from running, including injected scripts by third-party sites and extensions. Enterprises should also block non-whitelisted sites and extensions from calling the WebAuthn APIs to prevent attackers from intercepting the passkey registration and authentication process, a critical component in the Passkey Pwned Attack.

The Challenge of Delivering Difficult News

Security researchers, enterprises and industry consortiums like the FIDO Alliance have always worked hand-in-hand to advance authentication technologies to defend against the true adversary: attackers. We want to continue to encourage future researchers to disclose critical discoveries when their findings challenge widely held assumptions, or reveal uncomfortable truths about technologies we rely on. Most importantly, the Passkey Pwned attack remains to be a critical vulnerability for many enterprises and it would be careless to dismiss a major security loophole based on a coverage rooted in misinterpretation.

In summary, the Passkeys Pwned attack highlights a major WebAuthn implementation flaw that impacts any passkey authenticated app, allowing attackers to gain unfettered access to business-critical enterprise SaaS apps and data. We hope that this article and the appended demos clarify the Passkeys Pwned attack, and arm you with specifics you need to take mitigating steps in your own organization.

For industry consortium representatives and enterprise security leaders who would like to learn more, contact us at founder@sqrx.com. We would be more than happy to provide a technical deep dive with our researchers and answer any questions over an in-depth conversation.


Recap of Our “Passkeys Pwned” Talk at DEF CON was originally published in SquareX Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Recap of Our “Passkeys Pwned” Talk at DEF CON appeared first on Security Boulevard.

19 September 2025


>>More