Google Passkeys Hijacked by Malware in Pass-ta-key Attacks

The master key protecting every passkey in your Google account is 32 bytes. That sentence is longer than the key itself. Unit 42 showed that malware running as your normal Windows user, with no administrator rights and no prompt on your screen, can pull it out of Chrome's process memory while it briefly sits there in plaintext.

Two things are true at once, and most coverage picks only one. Passkeys still kill phishing outright. And on a compromised machine, the passkey is not the unbreakable object the marketing implies.

Key Takeaways

• Palo Alto Networks Unit 42 disclosed three attack paths in early August 2026 named Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key, all targeting Google Password Manager in Chrome on Windows.
• Pass-ta-key steals Chrome's wrapped device identity key from disk and signs an attacker's request through Windows CNG APIs, producing a valid assertion with no biometric prompt.
• Golden Pass-ta-key extracts the 32 byte security domain secret from Chrome's memory, decrypting every synced passkey on the account, and Google offers no way to rotate it.
• All three paths need malware already running on the victim's Windows machine, making infostealers the realistic delivery vector rather than any flaw in WebAuthn or FIDO2.

What Is the Pass-ta-key Attack?

Pass-ta-key lets unprivileged malware impersonate a trusted device to Google's cloud authenticator and receive a valid WebAuthn assertion with no user interaction. Per Unit 42's research, Chrome keeps a hardware backed device identity key on Windows but exports it as a wrapped blob in a local file, passkey_enclave_state. Malware reads that blob and replays it through standard Windows CNG calls.

The TPM still does the signing, which is the uncomfortable part: the hardware behaves as designed, because the request reaching it looks legitimate. One bit separates the result from a real sign in. The User Verified flag is 1 when a genuine verification key signs, 0 when the identity key signs instead, and sites that check it are safe from this first path.

What Do Silver and Golden Pass-ta-key Do?

Silver Pass-ta-key defeats the user verification check. Golden Pass-ta-key steals the master key encrypting all of your synced passkeys.

Silver deletes the local enclave state file, forcing Chrome to onboard the device again. Chrome briefly defers creating the user verification key during that flow, and the attacker registers their own key in the gap. The cloud authenticator never validates attestation on the new key, so assertions signed by it carry the User Verified flag set to 1. BleepingComputer reported this yields durable access from the attacker's own system, with the victim's machine no longer needed at sign in.

Golden targets the security domain secret, or SDS: a 32 byte symmetric key encrypting every passkey synced to the account. Malware triggers the same onboarding flow, then dumps Chrome's memory while the SDS sits there in the clear. Recover it and every existing and future synced passkey is readable. Google stripped the SDS from Chrome's FIDO device log after Unit 42 reported it, but the memory exposure remains.

Why Your Gmail Account Is the Real Prize

A Google account passkey does not just open Gmail. It opens the mailbox every other account you own uses to verify you. Password resets, login codes, billing alerts and recovery links land in one place. Take that inbox and you inherit everything downstream of it, one reset link at a time.

That blast radius is why attackers keep returning to Gmail. Stealer logs have already put enormous volumes of Google logins into circulation, including a database of 48 million Gmail credentials. State backed crews have gone after the recovery layer directly, as when Russian operators abused Gmail app passwords to sidestep multi factor authentication. Pass-ta-key reaches the same objective through a newer door.

Passkeys did not eliminate the threat to your inbox. They relocated it. The attack used to arrive as a convincing message asking for your password; now it runs quietly on your laptop. The perimeter moved from your judgment to your endpoint.

Does This Mean Passkeys Are Broken?

No. Nothing here breaks WebAuthn or FIDO2 cryptography, and nothing works remotely against a clean machine. Every path assumes malware already executing on the victim's Windows host at ordinary user privilege. That is a post compromise scenario, where your session cookies, browser profile and saved passwords were already in play. The FIDO Alliance reported on May 7, 2026 that roughly 5 billion passkeys are in use and 75% of people surveyed have enabled one. Rolling that back would be a mistake.

The honest read is narrower: a cloud synced passkey inherits the security of the weakest device it syncs to. That is a property of syncing, not of passkeys, and it echoes the trade off in attacks against zero knowledge password manager architectures. Convenience across devices costs you the guarantee that a private key never leaves one piece of hardware.

The Relying Party Failure Developers Need to Fix

The original Pass-ta-key path only works against sites that fail to enforce user verification, and a surprising number do. The W3C Web Authentication specification defines the UV flag in the authenticator data flags byte, and validating it is the relying party's job. Unit 42 found services that requested userVerification: "required" at registration, then never checked the returned bit. eBay was one such case and has since fixed it.

If you ship WebAuthn, three checks belong in your verification path:

• Validate the UV bit on the server, not just in the browser request options. Asking for it without verifying it reduces two factors to one.
• Set userVerification to required, not preferred, for anything that moves money, changes credentials, or triggers recovery.
• Track the signature counter where the authenticator supplies one and alert on inconsistencies. Unit 42 filed a Chromium issue on this because it is a cloning signal.

Has Google Fixed It?

Partially, and not publicly enough to call the matter closed. Unit 42 filed three Chromium issues: the SDS appearing in plaintext in chrome://device-log/FIDO, missing attestation validation on new verification keys, and the absent signature counter check. Google removed the log exposure. The other two are load bearing for Silver and Golden, and the research does not say either is resolved.

As The Hacker News noted, a National Vulnerability Database search on August 3, 2026 turned up no CVE for the three techniques, and Google had not answered BleepingComputer's request for comment at publication.

What Should You Do Right Now?

The defense is not "stop using passkeys." It is refusing to let one compromised laptop become the whole account.

• Enroll at least one hardware security key alongside the synced passkey. A device bound credential on a YubiKey never syncs, never touches Chrome's enclave state, and cannot be recovered from memory.
• Turn on the Advanced Protection Program if you are a journalist, executive, activist, or admin. It requires security keys or device bound passkeys and hardens account recovery, the exact surface Silver targets.
• Audit your device list monthly. Google's "See devices with account access" page lists every session; sign out anything unfamiliar, then change your password to invalidate the rest.
• Treat any infostealer infection as a full credential reset event. That now includes passkeys. Rebuild the machine, then register your passkeys again from a clean device.
• Stop treating the biometric prompt as proof. The point of Pass-ta-key is that a valid assertion appears without one ever reaching your screen.

One implication the research leaves unstated: any credential system that ships a master key to the client during recovery has this shape of problem, whoever builds it. Chrome on Windows is where Unit 42 looked, not the only place the pattern exists.

Sources: Palo Alto Networks Unit 42, BleepingComputer, The Hacker News, the W3C Web Authentication specification, and the FIDO Alliance.