By ByteBot
Security researchers at Palo Alto Networks Unit 42 disclosed this week three attack classes — dubbed Pass-TA-Key, Silver Pass-TA-Key, and Golden Pass-TA-Key — that allow malware on a Windows device to hijack Google Password Manager passkeys without touching a password or triggering a biometric prompt. The most severe variant, Golden Pass-TA-Key, extracts the Security Domain Secret: a 32-byte master encryption key that decrypts every passkey synced to a Google account. One malware infection can hand attackers permanent access to every service you protected with a Google passkey.
Passkeys were marketed as phishing-resistant and unextractable. This research shows that the sync model enabling cross-device convenience creates a master key that malware can steal. The attacks don’t break passkey cryptography. They exploit the implementation gaps in how Google handles device trust and recovery flows.
Three Attacks, One Escalating Playbook
The base variant, Pass-TA-Key, extracts the device identity key from the Windows TPM (Trusted Platform Module) and uses it to impersonate the victim’s machine when requesting authentication from Google’s Cloud Authenticator. No admin privileges required. As Palo Alto Networks Unit 42 describes it: “the cloud authenticator then treats the request as coming from the victim’s trusted computer” — and returns valid signed credentials.
Silver Pass-TA-Key goes further. For accounts requiring user verification, the attacker forces Chrome into device re-enrollment by corrupting or deleting the local passkey state. During the brief window when the cloud authenticator hasn’t yet validated a newly registered verification key, the attacker registers their own. From that point, they can authenticate from any device — without the victim’s machine ever being involved again.
However, Golden Pass-TA-Key is the one that changes the calculus entirely. By monitoring Chrome during re-registration and dumping process memory, the attacker extracts the Security Domain Secret. This 32-byte key decrypts every synced passkey private key in the Google account. The attacker can clone all of them to their own hardware and authenticate as the victim indefinitely across every passkey-protected service. Google removed the SDS from Chrome’s device-log interface after disclosure, but Unit 42 confirmed it remains accessible in Chrome’s process memory during certain operations.
One Infection, Every Passkey Gone
The Golden attack reframes the incident response question. When a password is compromised, the fix is obvious: change the password. When the SDS is stolen, there is no direct equivalent. The attacker holds cryptographic copies of every passkey the victim created through Google Password Manager. Changing your Google password does nothing — passkeys are independent of passwords, and the attacker has already cloned them. BleepingComputer’s analysis confirms victims may not know which services they used passkeys for, let alone which are now compromised.
Google’s log fix after disclosure — removing the SDS from the visible FIDO device log — is a mitigation, not a solution. The more significant question is what memory isolation changes follow. For now, the risk is real on any Windows device with TPM running Chrome that also has malware present. That last condition is not a small thing — but it’s also not a rare thing in 2026.
Related: Keyv npm Supply Chain Attack: Shai-Hulud Hits 2B Installs
Developers: Your WebAuthn Server Is Probably Wrong
Unit 42 tested eBay’s passkey implementation and found it accepted authentication assertions without the required user verification flag. eBay fixed the gap after disclosure — but the researchers are explicit that eBay is unlikely to be unique. The W3C WebAuthn Level 3 specification defines the user verification flag in the authenticator data flags byte, and validating it is the relying party’s responsibility. Most server-side WebAuthn libraries will not enforce it by default. Developers must explicitly check that user verification was satisfied in every authentication response.
The fix list from Unit 42 is short: require and validate UV on all passkey assertions, enforce attestation for newly registered device keys, harden recovery and re-enrollment flows against unexpected re-registration attempts, and treat any sudden drop in UV requirements as an anomaly worth investigating. If your WebAuthn server-side implementation was written by copying a tutorial, audit it. The eBay validation failure is not an edge case — it is what happens when teams ship WebAuthn without reading the spec past the happy path.
The Real Threat Model
Context matters here. All three attacks require malware already running on the victim’s Windows device. You cannot execute Pass-TA-Key attacks remotely. Passwords, by contrast, can be stolen with a phishing page, a database breach, or credential stuffing — entirely without device access. Malware is a meaningfully higher bar. Hardware security keys — YubiKey and equivalents — are not affected: their private keys never leave the hardware, there is no sync model, and there is no Security Domain Secret to extract.
Synced passkeys and hardware-bound passkeys have different threat models. This disclosure doesn’t change the fact that synced passkeys are substantially more secure than passwords for most users and most threat scenarios. It does change how you should evaluate high-security accounts: for those, hardware keys remain the stronger choice. For everyone else, the advice is the same as it was before this research — passkeys over passwords, every time.
Key Takeaways
- Golden Pass-TA-Key extracts the master encryption key protecting all Google-synced passkeys — one malware infection can permanently compromise every passkey-protected account
- Changing your password after a Golden attack does nothing; passkeys are independent of passwords and the attacker has already cloned them
- Developers implementing WebAuthn must validate the UV flag server-side on every assertion — eBay did not, and most tutorials skip this step
- Hardware security keys are not affected by these attacks and remain the stronger choice for high-security accounts
- All three attacks require malware already on the device; passkeys still provide stronger protection than passwords for the vast majority of threat scenarios
