A recent revelation by **Unit 42** details a concerning set of vulnerabilities affecting **Chrome's Google Password Manager** on **Windows** systems equipped with a **Trusted Platform Module (TPM)**. These post-compromise attack paths allow malware, already running on a victim's device, to bypass passkey security measures, including fingerprint or PIN verification, to gain unauthorized access to accounts. Crucially, these attacks do not break the underlying cryptography of passkeys. Instead, they target the surrounding code and implementation details within Chrome, such as how device keys are stored, device re-enrollment processes, and whether relying parties adequately verify user interaction. ### The Attack Vectors: Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key **Unit 42** identified three distinct attack paths: * **Pass-ta-key**: This technique extracts Chrome's wrapped device identity key and leverages the same TPM to sign an attacker-controlled request via **Windows Cryptography API: Next Generation (CNG)** calls. The issue stems from Chrome creating the TPM key without a key name and exporting it as an opaque blob, which can then be reloaded without prompting the user. While the resulting authentication assertion lacks the User Verified (UV) flag, the **Web Authentication specification** states that relying parties requiring user verification *must* fail the ceremony if this bit is absent. **GitHub** reportedly enforced this check, while **eBay** initially accepted such assertions before fixing the validation gap after disclosure.  * **Silver Pass-ta-key**: This path targets the device re-enrollment process. Malware can force Chrome to re-enroll the device, and during a specific window, an attacker can register their own user-verification key. Assertions signed with this attacker-controlled key carry the UV flag, potentially enabling persistent access without requiring the victim's device. **Unit 42** recommends that credential providers attest newly enrolled keys to mitigate this vulnerability. * **Golden Pass-ta-key**: This most potent attack targets the **Security Domain Secret (SDS)** itself. Malware can trigger a re-enrollment process, allowing it to read the 32-byte SDS from Chrome's process memory while it briefly resides there in plaintext. This secret can then be used to recover synchronized passkey private keys, leading to full account compromise and persistent access from an attacker's environment. ### Scope and Remediation The research is limited to **Google Password Manager** in Chrome on Windows systems with a TPM, and all attack paths require an initial endpoint compromise. As of August 3, 2026, no **CVE** identifiers have been assigned to these techniques, and a full remediation status remains unclear. While **Google** reportedly removed an earlier SDS exposure from Chrome's FIDO logs and **eBay** now validates the UV flag, **Unit 42** indicates that the SDS still reaches the client and remains in Chrome's memory, suggesting the Golden Pass-ta-key path may still be viable. ### Recommendations for IT Security Professionals and Users This research underscores the critical importance of robust endpoint security. For organizations and privacy-conscious individuals utilizing passkeys, several measures are recommended: * **Relying parties** should ensure their systems are configured to set `userVerification` to `required` and **always verify the returned UV bit**, rather than solely trusting the request setting. * **Credential providers** should implement stronger checks for re-registration and recovery, restrict access to local passkey state, and ensure master keys are not exposed in client logs or memory. * Users should be aware that if they suspect compromise, simply changing their **Google Password Manager PIN** or deleting data may not invalidate a stolen **Security Domain Secret (SDS)**. The absence of an SDS-specific rotation or revocation control is a significant concern.  **Ghost Protocol** has reached out to **Google** for comment on whether a stolen SDS survives a Password Manager PIN change and to **Palo Alto Networks** for further details on their research. We will update this story with any responses.