Google Password Manager passkeys stored through Chrome on Windows can be abused by malware already running under the logged-in user’s account, according to new research from Palo Alto Networks’ Unit 42. The finding is serious for anyone who treats a synchronized passkey vault as protection after an endpoint has been compromised — but the claim that “one virus can unlock every future Google passkey” goes beyond what the public record establishes.
Unit 42 calls the three techniques Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key. They target Chrome’s Google Password Manager cloud authenticator on Windows systems with a Trusted Platform Module, or TPM, rather than breaking WebAuthn cryptography or defeating a fingerprint reader remotely. TechRadar and The Hacker News independently reported the research this week, both emphasizing the same prerequisite: malware must already be executing on the victim’s Windows PC.
That boundary is vital. Passkeys still block the attacks they were designed to stop — phishing pages, password reuse, credential stuffing, and theft of a website’s password database. What Unit 42 demonstrates is that, once hostile code operates inside the same Windows session as Chrome, the protection shifts from “can an attacker steal a password?” to “what can malware make the credential provider do?”
Google’s own documentation draws a clear distinction between a passkey saved locally in Windows Hello and one saved in Google Password Manager. A Windows Hello passkey stays on that PC and is not synchronized or backed up. Google Password Manager, by contrast, makes passkeys available wherever the user signs into Chrome or Android with the same Google account.
That convenience is the element Unit 42 examined. Google says Password Manager protects synchronized passkey secrets with end-to-end encryption, and the researchers do not claim to have cracked that encryption. Their point is more uncomfortable: the Chrome client sometimes has to ask the local TPM to perform cryptographic operations, enroll a device into the account’s security domain, or handle key material needed to use the synchronized vault.
A TPM protects private material from simple file theft. It does not magically make every request submitted by software on a compromised, logged-in PC legitimate. If malware can abuse the trusted application’s flow, it may be able to obtain an authentication response without asking the user for a Windows Hello PIN, face scan, or fingerprint.
For Windows administrators, this is an endpoint-security story as much as an authentication story. A user who opens a malicious attachment, installs a rogue browser extension, or runs an infostealer has not merely exposed cookies and saved passwords; in this scenario, they may have exposed the machinery that authorizes passkey use.
This is where the research exposes a problem outside Google’s Password Manager. The WebAuthn specification is explicit: when a website requires user verification, the relying party — the website accepting the sign-in — must check the returned UV bit in the signed authenticator data. Asking the browser to require verification is not enough if the server then fails to validate what came back.
According to Unit 42’s testing, GitHub rejected the lower-assurance assertion, while eBay initially accepted it. The researchers say eBay fixed that validation gap after disclosure. That result changes the practical reading of the first technique: it is not a universal bypass of every passkey login. Well-implemented relying parties can reject it today, irrespective of whether Google changes its own service.
The discrepancy is a reminder for developers and identity teams deploying passkeys. A WebAuthn configuration with
If the provider accepts that replacement or additional verification key, the attacker may be able to produce assertions marked as user-verified later from a system they control. In other words, the concern is no longer merely a silent sign-in from the infected laptop; it is persistence through the credential provider’s trust relationship.
Public Chromium code confirms that Chrome has a deferred user-verification-key creation state. It does not, by itself, prove that Unit 42’s complete substitution chain remains exploitable in the latest Chrome Stable build. Unit 42’s report and follow-up coverage do not identify affected Chrome version numbers, a CVE, or a public Google bulletin stating which of the three paths have been closed.
That missing information matters more than the dramatic attack names. IT teams cannot use a KB number, CVE identifier, or Chrome version threshold to determine exposure, and Google has not published a user-facing remediation workflow specifically for this research. As of August 7, 2026, there is also no public evidence that criminals are exploiting these techniques in the wild.
The researchers say Google removed an earlier SDS exposure in Chrome’s internal FIDO logs after disclosure. But they contend that the secret still reaches Chrome process memory, leaving a target for malware able to read that process at the right time. This is a meaningful improvement over a permanently written log, but it is not the same as eliminating the memory-exposure risk Unit 42 describes.
Still, “every future passkey” is not a conclusion users should draw from the public material. The research establishes a potential route to recover synchronized passkey secrets under a compromised session. It does not establish that a stolen SDS grants an attacker an irreversible, universal ability to decrypt every passkey a user will create forever, regardless of credential deletion, re-enrollment, account recovery, future key rotation, or provider-side changes.
The unresolved issue is more practical: Google’s public Password Manager controls let users change a Password Manager PIN and delete all Password Manager data, but they do not explain whether those actions rotate or revoke a previously exposed Security Domain Secret. No public Google advisory currently answers that question. That leaves affected users without a documented “rotate the master sync secret” button — a material gap in incident-response guidance.
For accounts with financial, administrative, source-code, or recovery authority, consider maintaining a device-bound alternative such as a FIDO2 hardware security key. A passkey held in Windows Hello is also local-only rather than synchronized, though that choice trades recoverability and cross-device convenience for narrower exposure. Losing or reinstalling the PC means a Windows Hello-stored passkey cannot be recovered.
If a Windows device may already be infected, removing a suspicious extension or running a quick malware scan is not a sufficient response to this research. The safer operational sequence is to isolate the system, investigate or rebuild it from trusted media, review Google account sessions and signed-in devices, revoke active sessions where appropriate, and recreate high-value passkeys from a known-clean device. Organizations should also review account recovery methods, because a stolen recovery channel can defeat even a perfectly implemented passkey strategy.
For services that accept passkeys, the immediate action is technical and specific: require user verification for sensitive authentication, validate the returned UV flag server-side, and test that the rejection actually occurs. Unit 42’s GitHub-versus-eBay result shows that the distinction is not theoretical.
Passkeys have not failed here. The research instead puts a hard limit on a common marketing shorthand: phishing-resistant authentication does not mean malware-resistant endpoints. Chrome users who synchronize passkeys through Google Password Manager should keep using passkeys, but administrators should stop treating passwordless sign-in as a substitute for browser hardening, endpoint detection, application allowlisting, and a recovery plan for a device that has already been lost.
That boundary is vital. Passkeys still block the attacks they were designed to stop — phishing pages, password reuse, credential stuffing, and theft of a website’s password database. What Unit 42 demonstrates is that, once hostile code operates inside the same Windows session as Chrome, the protection shifts from “can an attacker steal a password?” to “what can malware make the credential provider do?”
Chrome’s synchronized vault is the target
Google’s own documentation draws a clear distinction between a passkey saved locally in Windows Hello and one saved in Google Password Manager. A Windows Hello passkey stays on that PC and is not synchronized or backed up. Google Password Manager, by contrast, makes passkeys available wherever the user signs into Chrome or Android with the same Google account.That convenience is the element Unit 42 examined. Google says Password Manager protects synchronized passkey secrets with end-to-end encryption, and the researchers do not claim to have cracked that encryption. Their point is more uncomfortable: the Chrome client sometimes has to ask the local TPM to perform cryptographic operations, enroll a device into the account’s security domain, or handle key material needed to use the synchronized vault.
A TPM protects private material from simple file theft. It does not magically make every request submitted by software on a compromised, logged-in PC legitimate. If malware can abuse the trusted application’s flow, it may be able to obtain an authentication response without asking the user for a Windows Hello PIN, face scan, or fingerprint.
For Windows administrators, this is an endpoint-security story as much as an authentication story. A user who opens a malicious attachment, installs a rogue browser extension, or runs an infostealer has not merely exposed cookies and saved passwords; in this scenario, they may have exposed the machinery that authorizes passkey use.
The first attack can be stopped by the website receiving the passkey
The baseline Pass-ta-key method, as described by Unit 42, abuses Chrome’s device identity material to request a valid assertion from Google’s cloud authenticator. The assertion is signed and can look structurally legitimate, but it lacks the WebAuthn user verified signal that should indicate a real local PIN or biometric verification took place.This is where the research exposes a problem outside Google’s Password Manager. The WebAuthn specification is explicit: when a website requires user verification, the relying party — the website accepting the sign-in — must check the returned UV bit in the signed authenticator data. Asking the browser to require verification is not enough if the server then fails to validate what came back.
According to Unit 42’s testing, GitHub rejected the lower-assurance assertion, while eBay initially accepted it. The researchers say eBay fixed that validation gap after disclosure. That result changes the practical reading of the first technique: it is not a universal bypass of every passkey login. Well-implemented relying parties can reject it today, irrespective of whether Google changes its own service.
The discrepancy is a reminder for developers and identity teams deploying passkeys. A WebAuthn configuration with
userVerification set to required is only half the control. The server-side verification must reject an assertion where the UV flag is absent. The standard requires it; the research shows why treating that check as optional is a security defect.Silver Pass-ta-key aims for persistence beyond the infected PC
The Silver Pass-ta-key variant is more consequential because it attacks device re-enrollment. Unit 42 says malware can force Chrome into a state where it is enrolling the computer again, then exploit a deferred user-verification-key creation process to register attacker-controlled key material.If the provider accepts that replacement or additional verification key, the attacker may be able to produce assertions marked as user-verified later from a system they control. In other words, the concern is no longer merely a silent sign-in from the infected laptop; it is persistence through the credential provider’s trust relationship.
Public Chromium code confirms that Chrome has a deferred user-verification-key creation state. It does not, by itself, prove that Unit 42’s complete substitution chain remains exploitable in the latest Chrome Stable build. Unit 42’s report and follow-up coverage do not identify affected Chrome version numbers, a CVE, or a public Google bulletin stating which of the three paths have been closed.
That missing information matters more than the dramatic attack names. IT teams cannot use a KB number, CVE identifier, or Chrome version threshold to determine exposure, and Google has not published a user-facing remediation workflow specifically for this research. As of August 7, 2026, there is also no public evidence that criminals are exploiting these techniques in the wild.
Golden Pass-ta-key is a vault-recovery problem, not a magic future-key switch
The “golden” technique is the reason the research has drawn attention. Unit 42 says malware can extract the 32-byte Security Domain Secret, or SDS, from Chrome process memory during an enrollment or recovery flow. That secret is used in the protection of synchronized passkey private keys.The researchers say Google removed an earlier SDS exposure in Chrome’s internal FIDO logs after disclosure. But they contend that the secret still reaches Chrome process memory, leaving a target for malware able to read that process at the right time. This is a meaningful improvement over a permanently written log, but it is not the same as eliminating the memory-exposure risk Unit 42 describes.
Still, “every future passkey” is not a conclusion users should draw from the public material. The research establishes a potential route to recover synchronized passkey secrets under a compromised session. It does not establish that a stolen SDS grants an attacker an irreversible, universal ability to decrypt every passkey a user will create forever, regardless of credential deletion, re-enrollment, account recovery, future key rotation, or provider-side changes.
The unresolved issue is more practical: Google’s public Password Manager controls let users change a Password Manager PIN and delete all Password Manager data, but they do not explain whether those actions rotate or revoke a previously exposed Security Domain Secret. No public Google advisory currently answers that question. That leaves affected users without a documented “rotate the master sync secret” button — a material gap in incident-response guidance.
What Windows users and administrators should do now
There is no reason for ordinary users to delete all passkeys. Replacing passkeys with reused passwords would restore phishing and credential-stuffing risks that passkeys substantially reduce. The appropriate response is to treat Chrome’s synchronized passkey vault as a high-value credential store and protect the Windows endpoint accordingly.For accounts with financial, administrative, source-code, or recovery authority, consider maintaining a device-bound alternative such as a FIDO2 hardware security key. A passkey held in Windows Hello is also local-only rather than synchronized, though that choice trades recoverability and cross-device convenience for narrower exposure. Losing or reinstalling the PC means a Windows Hello-stored passkey cannot be recovered.
If a Windows device may already be infected, removing a suspicious extension or running a quick malware scan is not a sufficient response to this research. The safer operational sequence is to isolate the system, investigate or rebuild it from trusted media, review Google account sessions and signed-in devices, revoke active sessions where appropriate, and recreate high-value passkeys from a known-clean device. Organizations should also review account recovery methods, because a stolen recovery channel can defeat even a perfectly implemented passkey strategy.
For services that accept passkeys, the immediate action is technical and specific: require user verification for sensitive authentication, validate the returned UV flag server-side, and test that the rejection actually occurs. Unit 42’s GitHub-versus-eBay result shows that the distinction is not theoretical.
Passkeys have not failed here. The research instead puts a hard limit on a common marketing shorthand: phishing-resistant authentication does not mean malware-resistant endpoints. Chrome users who synchronize passkeys through Google Password Manager should keep using passkeys, but administrators should stop treating passwordless sign-in as a substitute for browser hardening, endpoint detection, application allowlisting, and a recovery plan for a device that has already been lost.
References
- Primary source: geekspin
Published: August 7, 2026 at 1:00 PM UTC
Loading…
geekspin.co - Related coverage: techradar.com
Loading…
www.techradar.com - Related coverage: support.google.com
Loading…
support.google.com - Related coverage: blog.google
Loading…
blog.google - Related coverage: learn.microsoft.com
Support for Passkeys in Windows | Microsoft Learn
Learn about passkeys and how to use them on Windows devices.learn.microsoft.com - Related coverage: developers.google.com
Loading…
developers.google.com - Related coverage: support.microsoft.com
Loading…
support.microsoft.com - Related coverage: support.microsoft.com
Loading…
support.microsoft.com - Related coverage: security.googleblog.com
Loading…
security.googleblog.com - Related coverage: developers.google.com
Loading…
developers.google.com - Related coverage: safety.google
Loading…
safety.google - Related coverage: chromium.org
Loading…
www.chromium.org - Related coverage: blogs.windows.com
Loading…
blogs.windows.com - Related coverage: cloud.google.com
Loading…
cloud.google.com - Related coverage: cloud.google.com
Loading…
cloud.google.com - Related coverage: cybersecuritynews.com
Loading…
cybersecuritynews.com - Related coverage: unit42.paloaltonetworks.com
Loading…
unit42.paloaltonetworks.com - Related coverage: support.google.com
Loading…
support.google.com - Related coverage: passwords.google
Loading…
passwords.google - Related coverage: tsapps.nist.gov
Loading…
tsapps.nist.gov - Related coverage: androidauthority.com
Loading…
www.androidauthority.com - Related coverage: clrn.org
Loading…
www.clrn.org - Related coverage: pages.nist.gov
Loading…
pages.nist.gov