Google Password Manager Passkey Attacks Expose Post-Compromise Risks

Researchers at Palo Alto Networks' Unit 42 have uncovered three attack paths against Chrome's Google Password Manager cloud authenticator that could allow malware running as a standard Windows user to hijack passkey-protected accounts without triggering any fingerprint, PIN, or on-screen prompt. Dubbed Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key, the techniques target the operational code surrounding passkey cryptography rather than the cryptographic primitives themselves, including how Chrome stores device keys, manages TPM-backed re-enrollment, and handles user-verification enforcement on the relying-party side. The strongest variant, Golden Pass-ta-key, aims to extract the 32-byte Security Domain Secret (SDS) used to decrypt synced passkey private keys, which could give attackers reusable access from their own infrastructure after the initial compromise.

The attack chain begins with local reconnaissance. Chrome stores synchronized credential records under %LocalAppData%\Google\Chrome\User Data\\Sync Data\LevelDB, where an unprivileged process can harvest relying-party identifiers, usernames, credential IDs, and encrypted private-key material. In the first path, Pass-ta-key, the attacker extracts Chrome's wrapped device identity key and leverages the Windows Cryptography API: Next Generation (CNG) to request a TPM signature on an attacker-controlled payload. Current Chromium source code reveals a design weakness: Chrome instantiates the TPM key without a label, relying on a TODO comment referencing Chromium issue 398125799 to fix the omission, which means the exported key blob can be reloaded later under a flag that suppresses user prompts. The resulting assertion is functionally identical to a legitimate one, differing only by a single user-verification bit that many sites fail to validate.

Silver Pass-ta-key installs an attacker-controlled user-verification key to forge authenticated assertions, while Golden Pass-ta-key extracts the SDS to decrypt the user's synced passkey vault wholesale. All three paths require malware already executing on the victim's Windows endpoint equipped with a Trusted Platform Module, and none abuse cryptographic flaws in the FIDO2 or WebAuthn protocols themselves. As of the August 3, 2026, publication date, no CVE identifiers have been assigned, no exploitation in the wild has been observed, and the National Vulnerability Database returned no entries matching the three named techniques. Readers concerned about session and credential hygiene can run a quick privacy checkup with our privacy checkup tool, verify whether any of their credentials have appeared in known leaks using the email breach checker, and test the strength of existing passwords with the password checker.