Unit 42 'Pass-ta-key': Google Password Manager Passkey Attacks Let Malware Hijack Accounts Without a Fingerprint

Malware that never got admin rights, never phished a one-time code, and never put a single window on the victim's screen can still sign into that person's passkey-protected accounts. That is the finding Palo Alto Networks' Unit 42 published on Aug. 3, and it lands squarely on one of the reassuring things we tell people about passkeys: that a login needs your fingerprint, your face, or your PIN. In the case Unit 42 describes, it needs none of them.

The catch is where the passkey lives. Unit 42 went after Chrome's Google Password Manager acting as a cloud authenticator — the software passkey store that syncs your credentials across your devices through your Google account. Running as an ordinary Windows user, malware can coax that authenticator into producing a valid sign-in, or walk away with the secret that decrypts every synced passkey you own. As The Hacker News summarized it, the attacks could let malware hijack passkey-protected accounts outright.

What Unit 42 Actually Disclosed

Unit 42's "Pass the Passkey" research does not break WebAuthn cryptography. The math holds. The problems sit in the operational code around the passkey: how Chrome stores its device keys, how it re-enrolls a device when that state is missing, and whether the site you are signing into bothers to confirm a human was verified. Attack the plumbing, Unit 42 argues, and you never have to touch the cryptography.

The researchers grouped the weaknesses into three named paths of increasing severity. Each assumes the attacker already has code running as the logged-in user — the same foothold that infostealers and commodity trojans routinely get from a bad download or a malicious extension. From there, the goal shifts from stealing a password to manufacturing a legitimate-looking passkey assertion, or stealing the key material behind all of them.

The Three Paths

Unit 42 named them Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key. The naming echoes the Kerberos "silver ticket / golden ticket" hierarchy on purpose: each step up the ladder gets closer to the master secret and does more damage. The table below lays out what each one targets. Device-bound passkeys — the ones kept in a hardware security key, a Windows Hello TPM, or an on-device Apple keychain — are a different design and are not in scope here.

Following the brief's defender-only framing, I'm leaving out how each step is carried out; the point that matters is the outcome. The bottom rung already gives an attacker a usable login. The top rung, Golden Pass-ta-key, is the one that should worry defenders most: Unit 42 says malware can trigger a re-enrollment, read the SDS out of Chrome's memory while it briefly sits there in plaintext, and use it to decrypt the victim's synchronized passkey private keys. Recover that one secret and you are not hijacking a single session — you are holding the keys to every account the victim protects with a synced passkey.

The Quieter Problem: The "User Verified Flag"

A second Unit 42 write-up points at something that isn't Chrome's alone to fix. WebAuthn assertions carry a single bit in the authenticator data called the User Verified flag. Set to 1, it says a human proved themselves with a biometric or PIN on this request. Left at 0, it says they didn't. That one bit is what separates a passkey acting as two factors ("something you have" plus "something you are/know") from a passkey acting as one.

The gap is on the receiving end. Many relying parties — the websites and apps you log into — configure WebAuthn's userVerification setting as preferred rather than required, so logins keep working across a messy range of devices. A relying party that then never checks whether the User Verified flag actually came back as 1 will accept an assertion that was never gated by a fingerprint or PIN at all. Unit 42 reports that even when a relying party does ask for user verification, the cloud authenticator returned a valid assertion regardless of whether the request was signed with a verification-gated key or not. Either way, the "two-factor" passkey quietly collapses to a single factor, and the malware paths above have a much easier target.

What Defenders Can Check Now

There's no exploit code to chase here, and nothing in the disclosure asks you to rip out passkeys — they remain far better than reused passwords. The useful moves are about narrowing exposure on the cloud-authenticator path Unit 42 attacked:

• Prefer device-bound passkeys for high-value accounts. Hardware security keys, Windows Hello backed by the TPM, and on-device Apple passkeys sit outside the scope of this research because the private key never leaves the device and isn't decrypted from a synced cloud secret. For admin, finance, and identity-provider logins, that distinction is worth the friction.
• Enforce Chrome enterprise policy. Managed Chrome lets you control credential sync, profile separation, and extension installs. Tightening those reduces both the malware foothold and what a foothold can reach in the browser's credential store.
• Watch for the sign-in patterns this produces. A silent assertion still shows up somewhere: a login from a device or location the user never authenticated on, passkey re-enrollment events, or a sudden new user-verification key. Alert on unusual passkey and re-enrollment activity rather than trusting "it was a passkey, so it was the user."
• If you run a relying party, require and validate user verification. Set userVerification to required where your user base allows it, and actually check the User Verified flag in the returned assertion instead of assuming it. That closes the single-factor collapse on your side of the handshake.

What This Means For The Passkey Trust Model

The industry pitch for passkeys leans on two ideas: they're phishing-resistant, and the private key is supposed to be hard to steal. Unit 42's work chips at the second idea specifically for cloud-synced passkeys. Sync is the feature that made passkeys usable for normal people — lose your phone, keep your logins — and it's exactly that convenience that creates a decryptable secret sitting in a syncable store, reachable by software running as you.

That's the honest tension. Device-bound keys are more resistant to this class of attack but harder to recover and roll out at scale; synced keys are easy to live with but concentrate risk in the cloud authenticator and the endpoint. Neither is "the answer," and treating passkeys as a finished, uniformly safe category is how you end up surprised by research like this.

My read: This isn't a reason to walk back passkeys, but it is a reason to stop talking about them as one flat thing. "Passkey" spans a hardware key you can't clone and a cloud-synced credential an infostealer can reach — and the security gap between those two is now a lot more concrete. If your threat model includes malware on the endpoint (it should), device-bound passkeys for your crown-jewel accounts just got a stronger argument, and "we use passkeys" stopped being a complete answer to "how do you protect that login?"

Open Questions

Several load-bearing details aren't nailed down in the public disclosure yet, and I'm flagging them rather than guessing. Unit 42 and The Hacker News don't specify which Chrome versions are affected, and I've seen no confirmation that Google has shipped a patch or advisory tied to this work. Whether the same techniques carry over to other synced passkey providers — Apple, Microsoft, 1Password, Bitwarden — is not established; this research is scoped to Chrome's Google Password Manager cloud authenticator. I also haven't seen CVE identifiers assigned, or any named malware family observed using these paths in the wild. Treat those as unconfirmed until the vendors weigh in, and I'll update if that changes.

Primary Documents

• Unit 42 — "Pass the Passkey: A Novel Attack Surface in Passwordless Authentication"
• The Hacker News — "Google Password Manager Attacks Could Let Malware Hijack Passkey-Protected Accounts"