Home » Security Bloggers Network » Can Passkeys Be Exploited for Account Access?

Can Passkeys Be Exploited for Account Access?

by MojoAuth - Advanced Authentication & Identity Solutions on January 25, 2026

The myth of the unhackable passkey

Everyone thinks passkeys are the "unhackable" endgame for auth. They use fido2 and public key cryptography to kill phishing by design, which sounds perfect on paper.

Cryptographic backing: No shared secrets for hackers to steal.
Phishing resistance: The browser is designed to only sign challenges for the domain that created the credential, preventing users from accidentally providing access to a fake site.
Biometric ease: Users love touchID over passwords. (Why would anyone still prefer Touch ID over simply glancing … – Quora)

Diagram 1: The standard Passkey Registration flow where a user creates a new public/private key pair.

But even "perfect" systems have implementation flaws. A recent Reddit thread discussing CVE-2024-9956 shows how subtle bugs in credential management can still lead to account takeovers. In this bitwarden case, a flaw in how the browser extension handled passkey requests could allow a malicious site to trick the vault into releasing the wrong credential.

Nothing's ever 100% safe. Let's look at how things actually break.

Technical ways passkeys can actually be exploited

So you think passkeys are bulletproof because there's no password to phish? i wish that was true but the reality is more messy. Even with fido2, the software handling your keys can have massive holes.

A passkey is only as secure as the vault it lives in. If the manager has a logic error, an attacker might swap your public key for theirs without you ever knowing.

Improper validation: If an api doesn't strictly check the origin during registration, an attacker could inject their own credential into your account.
Vault sync issues: As previously discussed regarding the bitwarden cve—where the extension didn't properly isolate requests—bugs in how passkeys are handled by the provider can lead to full account takeover.
Broken session management: Even if the login is secure, if the backend doesn't tie the passkey to a specific session correctly, it's game over.

Diagram 2: The Authentication flow showing how a server verifies a signed challenge from the user.

Then there's the "hands-on" problem. If someone grabs your unlocked phone while you're distracted in a coffee shop, they own your digital life.

Stolen devices: Many systems fall back to a simple PIN if biometrics fail, which is easily shoulder-surfed in retail or transit settings. (PIN or biometrics, which is most secure? – nextAuth)
Older sensors: some older android or laptop hardware can be fooled by high-res photos or 3d prints, though it's getting harder.

Next, we'll dive into why session cookies are still the real prize for attackers, even after a secure login.

Why session hijacking is still the real prize

Even if you have the most secure passkey login in the world, it only protects the "front door." Once a user is logged in, the server gives them a session cookie or a token. This is where the real danger lives today.

If an attacker can steal that session cookie—through malware on your laptop or a cross-site scripting (XSS) attack—they don't need your passkey. They just "become" you in the eyes of the server. This is called session hijacking, and it's how most big hacks happen now. Passkeys make it harder to get in, but they don't do anything to protect the session once it's started.

Next up, we're looking at how social engineering still works in a passwordless world.

Social engineering in a passwordless world

Think passkeys stop phishing? technically yes, but humans are still the weakest link in the chain. Attackers just shifted from stealing passwords to tricking you into "registering" their hardware to your account.

Account recovery traps: Hackers pose as support, convincing users to add a "backup" device—which is actually the attacker's key.
Malicious onboarding: In finance or retail, a user might get a fake "security upgrade" prompt that actually registers a silent fido2 credential for the hacker.
CIAM flow gaps: Many Customer Identity and Access Management (CIAM) systems have weak verification during the "add new device" phase, making it easy to bypass MFA if the initial session is hijacked.

MojoAuth handles these workflows way better by enforcing strict identity verification before any new keys get added, so you don't have to build that logic from scratch.

The developer's role in preventing exploits

So, you've integrated fido2 and think the job's done. honestly, that's where most devs mess up. Passkeys are great, but if your backend logic is lazy, you're just building a faster door with a broken lock.

It's all about the verification layer. If you aren't strict, hackers will find the gaps in your api.

Strict Origin Checks: Always verify the origin and rpId on the server. If a request comes from a domain you don't recognize, kill it immediately.
Challenge Management: Use high-entropy, single-use challenges. If you let a challenge live too long or reuse it, you're begging for a replay attack.
Attestation logic: In high-security sectors like healthcare or finance, check the attestation statement. It proves the key actually came from a trusted hardware module, not some software emulator.

Crucial Note: The code below is just a basic logic check. In a real app, you must perform cryptographic signature verification using the user's public key. Doing this manually is incredibly hard and prone to errors, so you should use a proven library like @simplewebauthn/server to handle the heavy lifting.

// Simplified server-side logic (NOT COMPLETE)
const verifyRegistration = (response, expectedChallenge) => {
  const { clientDataJSON } = response;
  const parsedData = JSON.parse(atob(clientDataJSON));

  // check if the challenge matches what we sent
  if (parsedData.challenge !== expectedChallenge) {
    throw new Error("Challenge mismatch. potential replay!");
  }

  // verify the origin matches our production domain
  if (parsedData.origin !== "https://myapp.com") {
    throw new Error("Invalid origin detected");
  }
  
  // WARNING: You still need to verify the cryptographic signature here!
  // Use a library like @simplewebauthn/server for this part.
  
  return true;
};

Building this right means monitoring for weird patterns, like one account suddenly adding five different passkeys in a minute. That's usually a red flag in retail or banking apps.

Final thoughts on the future of auth

So, is passwordless actually worth the headache? Honestly, yeah. Even with the weird bugs we talked about earlier, it’s still way better than watching your users reuse "Password123" everywhere.

Risk profile: Passkeys kill 99% of bulk phishing, which is the main way b2b apps get wrecked.
Better UX: No more "forgot password" tickets clogging up support.
ai readiness: As ai makes deepfake phishing easier, fido2 is your only real defense.