Google Password Manager attacks could hijack passkey-protected accounts
- Evelyn Carter
- Aug 6
- 4 min read
On August 3, 2026, Palo Alto Networks Unit 42 disclosed three techniques Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key targeting passkeys synced through Google Password Manager on Chrome for Windows. Each technique requires malware to already be present on the device. No exploitation in the wild has been reported, no specific CVE has been assigned, and the full list of affected Chrome versions remains unconfirmed.
The most important point is that these techniques do not break the cryptography behind passkeys. Instead, they exploit gaps in device-key management, device re-enrollment, and user-verification checks. The risk therefore lies not in the passkey standard itself, but in the surrounding implementation layers.
What happened to Google Password Manager?
Unit 42 described three attack paths that could allow malware on a compromised Windows device to use or extract passkeys synchronized through Google Password Manager. The research focused on Google Chrome running on Windows systems equipped with a Trusted Platform Module, or TPM.
However, malware running under a standard user account may be able to read Chrome’s local synchronization data and identify services, usernames, credential identifiers, and encrypted key material associated with passkeys. According to Unit 42, this data is stored in the Chrome profile’s synchronization database and can be accessed without administrator privileges.
How do the three Pass-ta-key techniques work?
Each technique targets a different part of the authentication system. Their impact ranges from creating a valid login assertion to extracting the private keys behind multiple synchronized passkeys.
Technique | Targeted component | Described capability | Key condition |
Pass-ta-key | Device identity key and TPM | Generates a login assertion without user interaction | The website does not strictly verify the User Verified flag |
Silver Pass-ta-key | User-verification key re-enrollment process | Registers an attacker-controlled key and enables login from another environment | Exploits a period when Chrome delays UV-key generation |
Golden Pass-ta-key | 32-byte Security Domain Secret | Decrypts and recovers private keys for synced passkeys | Malware extracts the secret from Chrome process memory |
Pass-ta-key abuses the device identity key
In the first technique, malware retrieves the wrapped device identity key and asks the TPM to sign an attacker-controlled authentication request. According to Unit 42, this can be performed through standard Windows cryptographic APIs without privilege escalation.
Google Cloud Authenticator may then return an assertion that is cryptographically valid. However, an assertion created without PIN or biometric verification does not set the User Verified, or UV, flag.
Silver Pass-ta-key replaces the user-verification key
Silver Pass-ta-key targets the process used to re-enroll a device with the cloud authenticator. During one stage of that process, Chrome delays creation of the user-verification key to avoid asking the user to enter multiple PINs in quick succession.
The researchers said malware could exploit this window to register an attacker-controlled key. If the service does not adequately verify the origin or hardware attestation of the new key, signatures produced by the attacker’s key may be accepted as proof that the user unlocked the device.
Golden Pass-ta-key extracts the master secret
Golden Pass-ta-key targets the Security Domain Secret, or SDS, a 32-byte symmetric secret used to protect the private keys of synchronized passkeys.
Google removed the SDS from the FIDO logging output referenced by the researchers after receiving the report. However, Unit 42 stated that the secret may still be passed to the Chrome process during the recovery flow and may remain accessible in memory.
What are the scope and limitations of the research?
The research does not establish that every system running Chrome is immediately vulnerable. Unit 42 limited its testing to Google Password Manager in Chrome on Windows devices with a TPM, and all attack paths require malware to already be active on the endpoint.
Passkeys still remove many common password risks, particularly password reuse and credential-phishing attacks. The findings do not support abandoning passkeys. Instead, they show that passkeys must be deployed together with endpoint security and correct application-side authentication controls.
For broader context, enterprises may review IPSIP’s analysis of corporate cybersecurity threats that require immediate mitigation. The article helps connect identity compromise with malware, supply-chain risk, and other operational weaknesses.
What should enterprises do now?
Update Google Chrome, Windows, and endpoint security tools to the latest vendor-supported versions.
Review EDR/XDR alerts involving unusual access to Chrome memory, browser-profile directories, or Windows CNG.
Restrict unapproved application execution through application control or allowlisting.
Enforce least privilege, remove unnecessary local administrator rights, and control tools capable of dumping process memory.
Review login history, newly registered devices, active sessions, and changes to authentication methods for high-value accounts.
Revoke sessions and re-enroll credentials when an endpoint compromise is detected.
For internally developed applications, configure userVerification=required and validate the UV flag in every WebAuthn assertion.
Create alerts for authentication from unfamiliar devices, locations, or execution environments.
Maintain an independently controlled account-recovery process that does not depend entirely on one endpoint.
Include identity-compromise procedures in the Incident Response Plan.
What does the IPSIP's Vietnam expert perspective show?
Phishing-resistant authentication does not replace endpoint security. Enterprises should treat identity, device, browser, and application controls as one connected security chain. A weakness in any single layer may reduce the effectiveness of strong authentication.
SOC 24/7 is relevant for organizations that need continuous monitoring for malware activity, suspicious process-memory access, and anomalous sign-ins. IPSIP’s cybersecurity and SOC 24/7 solutions can support centralized detection, investigation, and response processes.
Vulnerability Assessment and Pentest are relevant when an enterprise operates websites or applications that support WebAuthn. Assessments should examine user-verification requirements, assertion validation, device enrollment, and recovery procedures, but should not be treated as a substitute for endpoint monitoring.
For Vietnamese enterprises, the immediate priorities are to review endpoint malware-detection capabilities, validate WebAuthn implementation, and strengthen credential-revocation procedures after security incidents. Passkeys should remain part of a layered security architecture rather than being treated as a standalone protection mechanism.
References
Comments