Quick Answer
Palo Alto Networks Unit 42 disclosed three attack paths on August 3, 2026, showing that malware already running on a Windows PC can silently hijack Google Password Manager’s synced passkeys in Chrome with no fingerprint, PIN, or on-screen prompt required. The underlying passkey cryptography is intact, but a compromised endpoint removes the protection passkeys are designed to provide. Keep your Windows device free of malware and enable an endpoint security tool.
Key Takeaways
- Unit 42 researcher Arie Olshtein published 3 named attack paths on August 3, 2026: Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key.
- All 3 attacks require malware already running on the victim’s Windows device; none exploit a remote or zero-click vulnerability.
- The most serious variant, Golden Pass-ta-key, extracts a 32-byte Security Domain Secret from Chrome’s process memory, which decrypts every synced passkey in the victim’s Google account, with no Google-provided rotation mechanism currently documented.
- The attacks do not break WebAuthn’s underlying cryptography; they exploit the implementation layers around how Chrome stores device keys, handles re-enrollment, and validates user verification.
- No exploitation in the wild has been reported as of August 10, 2026, and no CVE has been assigned to the Unit 42 findings. Keep your endpoint secure and your Chrome installation up to date.
What exactly is the Pass-ta-key attack, and where did it come from?
The Pass-ta-key attack family is a set of 3 techniques disclosed by Palo Alto Networks Unit 42 researcher Arie Olshtein on August 3, 2026, in a paper titled Pass the Passkey: A Novel Attack Surface in Passwordless Authentication. The disclosure identifies three distinct attack paths collectively named Pass-ta-key, targeting Google Password Manager in Chrome on Windows devices equipped with a Trusted Platform Module, or TPM. The research was the result of responsible disclosure, meaning Unit 42 reported its findings to Google and affected parties before publishing.
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. The August 3 report focuses on Google Password Manager in Chrome on Windows systems with a Trusted Platform Module. That distinction shapes the risk picture significantly. The attack is not something a website visitor or email recipient triggers accidentally. It requires that malicious software is already running on the device before any of the 3 techniques can be applied.
The attacks exploit systems responsible for storing, synchronizing, and using passkey credentials. Unit 42 says the findings expose gaps between the security assumptions around passkeys and their implementation. For most consumers, the practical meaning is that passkeys still eliminate phishing and credential stuffing, but a Windows PC infected with an infostealer becomes a meaningful threat to those credentials.
How do the 3 attack variants work differently from one another?
Unit 42 detailed three attack paths against Chrome’s Google Password Manager cloud authenticator, which it calls Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key; the strongest targets the master key protecting the user’s synced passkeys. Each variant targets a different layer of the authentication system and carries a different level of persistence and severity.
| Variant | What It Targets | User Interaction Required | Persistence After Malware Removed | Works Against Sites That Validate UV Flag |
|---|---|---|---|---|
| Pass-ta-key | Chrome’s wrapped device identity key; signs attacker requests via Windows CNG APIs | None | No | No (rejected by sites that check UV flag correctly) |
| Silver Pass-ta-key | Device re-enrollment; registers attacker-controlled UV key with Google’s cloud authenticator | None | Until device is unregistered or re-enrolled | Yes (attacker’s own key satisfies UV check) |
| Golden Pass-ta-key | 32-byte Security Domain Secret in Chrome’s process memory; decrypts all synced passkey private keys | None | Indefinite (no rotation mechanism documented) | Yes (attacker holds the private keys directly) |
The base Pass-ta-key technique works by retrieving the wrapped device identity key and asking 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. The key limitation of this first variant is that an assertion created without PIN or biometric verification does not set the User Verified, or UV, flag. Sites that validate that flag correctly, such as GitHub, reject the assertion outright.
Silver Pass-ta-key overcomes that limitation by a different method. The attacker uses malware on the compromised device to force Chrome to re-register it by invalidating its existing verification key or deleting the local file containing its passkey state. During the re-registration process, the attacker can register a user-verification key they control because the cloud authenticator does not validate whether the new key originated from trusted hardware. This means that after the re-enrollment completes, the attacker can satisfy user-verification checks from a separate machine, with no further access to the victim’s device required.
Why is Golden Pass-ta-key considered the most serious variant?
Golden Pass-ta-key is the most serious of the 3 variants because of the scope and permanence of the access it can provide. The most damaging variant, Golden Pass-ta-key, targets the Security Domain Secret, a 32-byte master key used to protect synced passkeys. Unit 42 first found the secret exposed in Chrome’s device logging. Google removed it from that logging output after the report, but the researchers say the secret is still temporarily present in Chrome’s process memory during re-registration. With the secret, an attacker can recover the victim’s synced passkey private keys.
The persistence problem is significant. Google has no mechanism to rotate or revoke this Security Domain Secret, meaning malware that captures it permanently controls every passkey in a victim’s Google account. All three attacks require existing malware on the victim’s device, and at least one of them produces a compromise that persists indefinitely even after the malware is removed. For a consumer whose Windows PC has been infected and then cleaned, the Google passkeys on that account may remain exposed even after the malware is gone, as long as the attacker retained the extracted secret.
This persistence characteristic is what separates Golden Pass-ta-key from the other two variants and is the primary reason the research has attracted attention from the security community. That said, 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.
Does this mean passkeys are broken or unsafe to use?
Passkeys as a standard are not broken by this research. 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.
Passkeys still offer strong protection against the attack categories they were designed to defeat. Passkeys eliminate phishing, credential stuffing, and password reuse attacks, attack categories that have driven the majority of large-scale account compromises for the past two decades. What the Pass-ta-key research demonstrates is that the threat model has shifted, not that the security has disappeared. The attacks described here require existing endpoint malware. A traditional password stored in a browser or password manager would be equally or more exposed on a device that already has an active infostealer running.
The honest framing is that a cloud-synced passkey inherits the security of the weakest device it syncs to. That is a property of syncing, not of passkeys, and it echoes the trade-off in attacks against zero-knowledge password manager architectures. Convenience across devices costs you the guarantee that a private key never leaves one piece of hardware. Users in high-risk environments, such as journalists, executives, or anyone who uses privacy-focused security tools, should factor this into their threat model.
Which sites and services are actually vulnerable to these attacks?
Whether a site is vulnerable to the base Pass-ta-key technique depends entirely on how that site validates the WebAuthn user-verification flag. Unit 42 found different outcomes among the services tested. GitHub rejected the attack because the required UV signal was absent. But eBay accepted the assertion despite requesting user verification. eBay subsequently changed its implementation to validate the flag correctly, according to the researchers.
The original Pass-ta-key path only works against sites that fail to enforce user verification, and a surprising number do. The W3C Web Authentication specification defines the UV flag in the authenticator data flags byte, and validating it is the relying party’s job. Unit 42 found services that requested userVerification: “required” at registration, then never checked the returned bit. This is a site-side implementation failure, not a failure of the passkey specification itself, but the practical consequence is real for affected services.
Silver Pass-ta-key and Golden Pass-ta-key are not limited by the UV flag problem, which makes them more broadly applicable. Because these involve concerns similar to sophisticated in-process credential hijacking techniques, they represent a genuine escalation in the complexity of what an infostealer operating on a Windows device can accomplish against passkey-protected accounts. The key gatekeeping condition in every case remains whether the attacker’s malware has already landed on the device.
What has Google done in response, and are the attacks fully patched?
The researchers said Google removed an earlier Security Domain Secret exposure from Chrome’s FIDO logs and that eBay now validates the UV flag. The secret still reaches the client and stays in Chrome’s memory, so the logging change does not close the path the researchers describe. The disclosure does not establish whether all three attack paths have been closed.
BleepingComputer contacted Google for comment on Unit 42’s findings and to ask whether the described attacks have been fully addressed, but a response was not immediately available. As of August 10, 2026, Google has not published a public user-facing remediation guide specific to the Pass-ta-key findings, and no CVE has been assigned to the Unit 42 research. No exploitation in the wild has been reported, no specific CVE has been assigned, and the full list of affected Chrome versions remains unconfirmed.
For site developers and administrators, setting userVerification to required in WebAuthn configuration and then actually validating the UV flag in every authentication response before accepting it is the actionable server-side mitigation. A configuration that nominally requires user verification but does not check the UV bit provides no security benefit over a configuration that does not require it at all. Individual consumers do not control this setting and must rely on the sites they use to implement it correctly.
What should Chrome users on Windows do right now?
The most practical response for consumers is to focus on endpoint security, because every Pass-ta-key attack begins with malware already active on the device. The steps below apply to Chrome users on Windows who use Google Password Manager for passkeys.
- Run a full malware scan using your current endpoint security tool or Microsoft Defender, which is built into Windows 10 and Windows 11. Schedule it to run automatically on a regular basis.
- Keep Chrome updated by opening Chrome and navigating to Settings > Help > About Google Chrome. Chrome updates automatically when the browser restarts, but confirming the version is current takes less than a minute.
- Review your Google Account’s active devices by visiting myaccount.google.com/device-activity. Remove any device you do not recognize, which addresses the re-enrollment vector used by Silver Pass-ta-key.
- Consider a hardware security key as an additional credential alongside your synced passkeys. Enrolling at least one hardware security key alongside the synced passkey provides a device-bound credential that never syncs, never touches Chrome’s enclave state, and cannot be recovered from memory.
- Avoid installing software from untrusted sources on the Windows device where you use Chrome. Infostealer malware, which is the realistic delivery mechanism for these attacks, commonly arrives through social-engineering techniques like ClickFix or trojanized application installers.
Stop and contact a security professional or your organization’s IT team if you suspect your Windows device is already compromised. Attempting to clean an active infostealer infection without professional guidance can leave residual components in place, and given that the Golden Pass-ta-key compromise may persist after malware removal, expert verification of a clean state is warranted before relying on those passkeys again. For enterprise environments, apply the principle of least privilege across user accounts to limit what any installed malware can access, which also reduces the damage any infostealer can do against Chrome’s local data.
Users who want broader context on how Windows-level tracking and credential exposure risks connect to browser security should note that endpoint hygiene protects multiple layers simultaneously, not just passkeys.
FAQ
Do I need to delete my Google passkeys because of Pass-ta-key?
Deleting your Google passkeys is not necessary or recommended in response to this research. Passkeys remain more secure than passwords and SMS codes, because there is no shared secret to steal or to be phished out of you. The three techniques described by Unit 42 require malware already active on the computer, a condition under which a traditional password manager would be compromised by equivalent or simpler means. Keep using passkeys and focus on keeping your device free of malware.
Does this attack work on Mac, iPhone, or Android?
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. The published findings cover Google Password Manager in Chrome on Windows with a TPM. The specific attack paths have not been demonstrated against macOS, iOS, or Android in this research.
Can a website tell if its users were affected by Pass-ta-key?
A website can reduce its exposure by correctly validating the WebAuthn user-verified flag on every authentication response, which is the server-side control that blocked the attack against GitHub. Authentication hinges on a single User Verified bit in the authenticator data. When relying parties fail to validate this flag, multi-factor authentication effectively collapses into a single factor. Sites that have not audited their WebAuthn implementation should do so promptly against Unit 42’s published guidance.
Is there a way to tell if the Golden Pass-ta-key attack already captured my Security Domain Secret?
There is currently no documented user-facing method to detect whether the Security Domain Secret was extracted from Chrome’s process memory. As of August 3, 2026, searches of Google’s public Chrome materials found no notice documenting either reported change, and none of them describes a way for a user to check whether a Security Domain Secret was exposed. If you have reason to believe your device was recently infected with an infostealer, contact a security professional and consider reviewing all devices linked to your Google account.
Does using a hardware security key instead of a synced passkey eliminate this risk?
Using a hardware security key that stores a device-bound credential and does not sync substantially reduces the exposure described in this research, because the private key never enters Chrome’s sync system or process memory in the same way. That said, Unit 42 did not test every device-bound security key configuration, and a hardware key is not automatically proven immune to every endpoint attack. A hardware key is a strong mitigation against the specific Pass-ta-key attack surface, but it does not replace the need for a clean, malware-free endpoint.