On August 4, 2026, Unit 42 researchers at Palo Alto Networks published research that shatters the perception of passkey invulnerability on Windows. Three attack techniques — Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key — allow malware already present on a machine, with only standard user privileges, to obtain valid authentication responses for accounts protected by FIDO2 passkeys. The target is Google Password Manager in Chrome, the world's largest passkey ecosystem. The FIDO2 protocol is not broken; the flaw resides in Google's vendor-specific implementation.
- Three documented techniques — Pass-ta-key, Silver Pass-ta-key, Golden Pass-ta-key — bypass passkeys in Chrome on Windows with TPM, without requiring elevated privileges.
- Pass-ta-key exploits TPM keys without a persisted name to sign requests with the User Verified flag set to zero; eBay accepted the response before fixing it, GitHub rejected it.
- Silver Pass-ta-key forces device re-registration by registering an attacker-controlled verification key, without the service verifying origin from secure hardware.
- Golden Pass-ta-key extracts the 32-byte Security Domain Secret from Chrome memory: a master secret protecting all synced passkeys, with no rotation or revocation mechanism.
How the First Attack Works: Pass-ta-key
The malware retrieves the wrapped_identity_private_key file from the path %LocalAppData%\Google\Chrome\User Data\Profile\Sync Data\LevelDB, where Chrome stores synchronized credential records. With this wrapped key, the attacker calls the Windows API NCryptCreatePersistedKey without specifying a persistence name, creating a temporary cryptographic handle. The signature produces a formally valid authentication response with the User Verified flag set to zero.
Validation of this flag divides services. GitHub validates it and rejected the researchers' attempt. eBay, at the time of testing, did not validate it and accepted the response — then corrected the behavior. The discrepancy shows that passkey robustness depends on misaligned server-side implementations, not just the client authenticator.
The Second Technique: Forcing Re-registration
Silver Pass-ta-key operates by invalidating the existing verification key or deleting the browser's local state file. Chrome interprets the event as a need to re-register the device with the Google cloud authenticator. The malware intercepts this flow and registers its own verification key. The remote service accepts the new key without verifying that it originates from original secure hardware.
The consequence is subtle but severe: the user receives no alarm signal, the procedure appears legitimate, and the device remains functionally synchronized. The attacker has replaced the trust anchor without breaking cryptography, but by abusing key lifecycle management.
The Third Ring: The Security Domain Secret in Memory
Golden Pass-ta-key targets the Security Domain Secret (SDS), a 32-byte block that protects all of the Google account's synced passkeys. During registration or retrieval, the SDS transits in cleartext in the Chrome process memory. Researchers documented that by forcing a re-registration and analyzing the allocation pattern, it is possible to extract the secret directly from user memory.
"even though Google removed this secret from Chrome's logging output after our report, the SDS is still sent to the client and remains accessible in Chrome's process memory. If the attacker forces the victim to re-register with the cloud authenticator and knows which pattern to look for, they can extract it directly from memory" — Palo Alto Networks Unit 42 (via Hardware Upgrade)
The structural problem is that no mechanism exists to rotate or revoke the Security Domain Secret. Once extracted, the value potentially compromises all past and future synced passkeys. As the researchers emphasized: "In the current implementation there does not appear to be a way to rotate or revoke the secret, so even passkeys synced in the future would remain protected by the same value."
Chrome as Weak Link: Architecture vs. Protocol
The research draws a sharp line between protocol and implementation. FIDO2/WebAuthn assumes the local authenticator guarantees user verification and that the private key is non-exportable. Windows TPM meets these requirements. Chrome, however, manages the key lifecycle in a way that allows: arbitrary wrapping without named persistence, re-registration without attestation of hardware origin, and exposure of master secrets in user memory rather than in an isolated enclave.
The eBay case shows that even services adopting passkeys can neglect fundamental checks on the User Verified flag. The combination of weak client implementation and incomplete server validation creates a failure chain that the "phishing-resistant" promise does not cover: the malware is already inside the endpoint.
Context: CVE-2026-34348 and the Passkey Moment
In the same period, Microsoft released an update on July 14, 2026 for CVE-2026-34348, a Windows Event Logging Service vulnerability with CVSS 6.5 (MEDIUM) that exposed passkey data. According to contextual sources, this conceptually related research — conducted by Michael Grafnetter and associated with the term "Pass-the-Passkey" — addresses different technical mechanisms than those of Unit 42. The 6.5 CVE represents a separate vector in the same Windows ecosystem, confirming that the passkey attack surface is actively being explored.
No CVE was assigned as of August 3, 2026 for the three techniques documented by Unit 42. Google has not publicly commented on the research at the time of publication. No infrastructure overlaps emerge linking the Unit 42 techniques to CVE-2026-34348 at this stage.
What to Do Now
For service developers implementing passkeys: rigorously validate the User Verified flag in authentication responses, explicitly rejecting responses with a zero value when policy requires user verification. For enterprises rolling out passkeys: assess whether endpoint protection — including visibility into processes interacting with Windows cryptographic APIs and access to Chrome LevelDB databases — covers the already-present-malware scenario. For Windows users with Google Password Manager: the brief documents no specific corrective actions by Google as of August 4, 2026; the dossier does not specify whether unaffected Chrome versions exist or whether fixes have been deployed since.
The research documents no in-the-wild exploitation of the three techniques, but their local-access requirement — not remote — makes them compatible with the most common compromise type on Windows endpoints.
Why the Passkey Promise Is at Risk of Inflation
Passkeys were pitched as the definitive elimination of passwords and their human weakness. The Unit 42 research demonstrates that, in the largest existing passkey ecosystem, an endpoint compromise returns the scenario to the same operational risk level: account takeover, persistent access, absence of alarm signals. The difference is that the user has no password to change, and the Security Domain Secret is not rotatable.
Google's implementation has transformed a protocol designed for secure hardware into a cloud synchronization system with attenuated guarantees. Until the vendor redesigns key lifecycle management and SDS isolation, passkeys in Chrome on Windows remain passkeys in name, passwords in fact — with one more centralized point of failure.
Sources
- https://www.hwupgrade.it/news/sicurezza-software/malware-senza-privilegi-entra-negli-account-protetti-da-passkey_157282.html
- https://windowsforum.com/windows-news.4/cve-2026-34348-windows-11-fixes-passkey-data-exposure.440578/
Information verified against cited sources and current as of publication.