Palo Alto Networks Unit 42 has demonstrated three ways that malware already running on a Windows computer can abuse Google Password Manager’s synced passkey workflow. In the strongest scenario, the malware can recover the secret that protects synchronized passkeys and use them from the attacker’s own system. The research does not break passkey cryptography and does not show that visiting a website is enough: every demonstrated path begins with a compromised Windows endpoint.[1]
The August 3 report focuses on Google Password Manager in Chrome on Windows systems with a Trusted Platform Module (TPM). The researchers call the attack family Pass-ta-key. They responsibly disclosed the findings and did not describe an active criminal campaign.
Who is affected by the Pass-ta-key research?
The demonstrated risk applies most directly when all of these conditions overlap:
- Chrome on Windows is signed in and synchronizes passkeys through Google Password Manager;
- the computer has already run malware in the user’s account, even without administrator rights;
- the attacker can read or change Chrome profile data, communicate with the TPM, or inspect Chrome process memory;
- the targeted website accepts the resulting WebAuthn assertion.
Unit 42 did not test every browser, operating system, password manager, or device-bound security key. A hardware security key that does not synchronize its private key is therefore outside this specific research, not automatically proven immune to every endpoint attack. Google says synced passkeys can be managed from Google Password Manager on Chrome and Android.[2]
This is also distinct from a fake passkey enrollment call or phishing page. Social engineering tricks a person into approving an attacker’s credential; Pass-ta-key starts after local malware has already made the Windows device untrustworthy.
How the three Google passkey attacks differ
Pass-ta-key: live access through the victim’s TPM
Malware reads synced credential records and a wrapped device identity key, then asks the victim’s TPM to sign an authentication request. It can run as a standard user without showing a device-unlock prompt. This path normally fails when the website correctly requires and validates user verification.
Silver Pass-ta-key: an attacker-controlled verification key
The attacker forces device re-enrollment and registers an attacker-controlled user-verification key while Chrome is in a pending onboarding state. The attacker can then authenticate later without keeping the victim’s computer online.
Golden Pass-ta-key: synchronized passkeys decrypted
Malware forces re-enrollment, inspects Chrome memory for the Security Domain Secret (SDS), and uses it to decrypt synchronized passkey records. Unit 42 says the current design provides no SDS rotation or revocation, so simply recreating another synced passkey may not close a confirmed Golden exposure.
The first reconnaissance step is especially important for incident response. Chrome stores synchronized WebAuthn records under a profile path such as %LocalAppData%\Google\Chrome\User Data\{Profile}\Sync Data\LevelDB. Those records reveal which services and usernames use passkeys, although their private keys remain encrypted until an attack path obtains the required signing or decryption capability.
What Google and affected websites fixed
Google removed the SDS from the visible chrome://device-log/FIDO log after Unit 42 reported it. The researchers say the same secret still reaches the Chrome process during recovery and can remain accessible in memory. The report does not name a Chrome version that closes all three attack classes.
The basic Pass-ta-key path also depends on how each website handles the WebAuthn user-verification flag. Unit 42 found that eBay accepted an assertion without the required verification during testing; eBay fixed that validation gap after disclosure. GitHub rejected the same kind of request in the researchers’ test. That difference is why one successful demonstration does not mean every passkey-protected account is equally exposed.
For website operators, the immediate control is to request userVerification = required and actually validate the returned UV flag. Credential providers also need stronger attestation for new device keys, tighter protection of local passkey state, and detection for unexpected re-enrollment or recovery events.
What to do if malware ran on your Windows PC
- Stop using the suspected PC for sign-ins. Disconnect it from the network if unknown account activity is happening now. Do not create replacement passkeys from the same Chrome profile.
- Use a trusted phone or another clean computer. Review Google security events, signed-in devices, recovery methods, third-party connections, and active sessions. Google recommends changing the password and removing unfamiliar devices or account access during hacked-account recovery.[3]
- Prioritize the email account and password manager. Then secure banking, crypto, work, developer, social, and shopping accounts. Remove unfamiliar passkeys at both Google Password Manager and the individual service where possible.
- Clean the endpoint before signing in again. A security tool may remove the visible payload while a loader, scheduled task, service, browser policy, extension, or bundled module remains. The infostealer cleanup and account-recovery guide explains the safe order. Gridinsoft Anti-Malware can check Windows for credential-stealing malware and persistence, but a clean scan cannot revoke an already stolen passkey or session.
- Escalate a plausible Golden exposure. If incident evidence shows Chrome memory dumping, forced passkey re-enrollment, or theft of the SDS, involve the affected service or your organization’s incident-response team. Until the provider confirms a safe rotation path, use a non-synced hardware security key or another independently protected sign-in method for high-value accounts.
If several accounts changed, access returned after a password reset, or passkeys appeared that you did not create, follow the broader hacked-account recovery checklist. If there is no malware evidence, no unknown session, and no unexpected passkey enrollment, the research alone is not a reason to delete every passkey. Keep Chrome and Windows updated and maintain the clean-device controls that password managers depend on.
References
- Arie Olshtein. “Pass the Passkey: A Novel Attack Surface in Passwordless Authentication.” Palo Alto Networks Unit 42, published and updated August 3, 2026. Unit 42 report.
- Google. “Manage passkeys in Chrome.” Google Chrome Help, accessed August 3, 2026. Chrome Help.
- Google. “Secure a hacked or compromised Google Account.” Google Account Help, accessed August 3, 2026. Google Account Help.
