Pass-ta-key: Three Attack Techniques Extract Google’s Synced Passkeys From Chrome Memory — 32-Byte Master Key, No Admin Rights Required, No CVE, Two Issues Unresolved
userVerification = required and rigorously validate the UV flag — Pass-ta-key (Attack 1) is defeated by relying parties that correctly validate user verification. eBay fixed this after Unit 42 reported it; many sites have not. (4) Credential providers: validate attestation on new device key registrations — Silver Pass-ta-key (Attack 2) is defeated by attestation validation at registration. (5) If you see Chrome memory dumping, forced passkey re-enrollment, or passkeys appearing you didn’t create — treat as an active compromise. The SDS has no rotation or revocation path in the current design — once stolen, recreating a synced passkey may not close the exposure. (6) No CVE has been assigned and Google had not publicly commented at time of publication. Two of three underlying issues remain unresolved.
Sources: Palo Alto Networks Unit 42 — “Pass the Passkey: A Novel Attack Surface in Passwordless Authentication” (primary research, published August 3, 2026) · Bleeping Computer — “New Pass-ta-key attacks let malware hijack Google-synced passkeys” · The Hacker News — “Google Password Manager Attacks Could Let Malware Hijack Passkey-Protected Accounts” · GBHackers — “Malware Can Steal Google’s Synced Passkeys Without Password or Fingerprint” · GridInSoft — “Pass-ta-key Attack Lets Malware Hijack Google Passkeys” · The420.in — “Three New Passkey Attack Techniques Expose Risks in Google Password Manager” · Techzine — “Malware exploits Google passkeys for account takeover” · GBlock — Technical analysis | Researcher: Palo Alto Networks Unit 42 (Arie Olshtein) | Techniques named: Pass-ta-key · Silver Pass-ta-key · Golden Pass-ta-key | Target: Google Password Manager cloud authenticator in Chrome on Windows | Privilege required: Ordinary user — no administrator rights | CVE assigned: None as of August 3, 2026 | Google response: Removed SDS from chrome://device-log/FIDO logs — two of three underlying issues remain unresolved | eBay response: Now validates UV flag (Attack 1 defeated for eBay) | Exploitation in wild: Not reported | Chromium issues filed: Three — SDS in plaintext log (fixed), missing attestation validation (open), absent signature counter check (open)
“The master key protecting every passkey in your Google account is 32 bytes. That sentence is longer than the key itself.” Malware at ordinary user privilege can pull it from Chrome’s process memory while it briefly sits there in plaintext. The cryptography is unbroken. The implementation is not.
On August 3, 2026, Palo Alto Networks Unit 42 researcher Arie Olshtein published “Pass the Passkey: A Novel Attack Surface in Passwordless Authentication” — a technical disclosure of three attack paths against Google Password Manager’s cloud authenticator in Chrome on Windows. None of the three techniques break WebAuthn’s underlying cryptography. All three work from malware already running at ordinary user privilege — no administrator rights, no UAC prompt, no visible indication to the user. The techniques target not the passkey standard itself, but the specific implementation choices Google made in Chrome for syncing passkeys across devices: how Chrome stores device identity keys, how it handles re-enrollment when that state is lost, and how it manages the master secret used to encrypt every synced passkey private key.
The disclosure arrives at a moment when the security industry has broadly committed to passkeys as the solution to phishing — a commitment reflected in FIDO Alliance guidance, NIST recommendations, and enterprise deployments at scale. The Pass-ta-key research does not reverse that commitment. Passkeys still defeat phishing outright — these attacks all require malware on the endpoint, which is a completely different threat model. What Unit 42’s research establishes is that a compromised Windows device running Chrome with synced passkeys is a more complete credential compromise than previously understood: not just the session, not just the password, but potentially every passkey private key synchronized to the Google account.
| Attack | Technique | What It Does | Privilege Required | Remediation Status |
|---|---|---|---|---|
| Pass-ta-key | TPM-backed device identity abuse — malware impersonates victim’s trusted device to send authentication requests to Google’s cloud authenticator | Silently obtain a valid authentication assertion — log into the victim’s passkey-protected accounts without password or biometric | Ordinary user — no admin | Defeated by relying parties enforcing userVerification = required and validating UV flag. eBay fixed. Many sites have not. |
| Silver Pass-ta-key | Re-enrollment window abuse — malware forces Chrome to re-enroll the device; Chrome does not create its user-verification key immediately, leaving a window for attacker to register their own instead | Install an attacker-controlled user-verification key, enabling reusable access from attacker’s own device | Ordinary user — no admin | Defeated by credential providers validating attestation on new device key registrations. Status: open Chromium issue, unresolved. |
| Golden Pass-ta-key | Security Domain Secret (SDS) extraction from Chrome process memory — malware forces re-enrollment, reads the 32-byte master key while it sits in plaintext in Chrome memory | Decrypt all synced passkey private keys — full account takeover, copy/reuse/sell every passkey, retain access even after victim re-enrolls devices | Ordinary user — no admin | Google removed SDS from FIDO logs. SDS still reaches Chrome memory. No rotation or revocation path exists. Open Chromium issue, unresolved. |
Attack 1 — Pass-ta-key: impersonating a trusted device
Google Password Manager’s cloud authenticator uses TPM-backed device identity to distinguish trusted devices from untrusted ones. When you authenticate with a passkey stored in Google Password Manager, Chrome presents the device’s TPM-backed identity to the cloud authenticator as part of proving the request originates from your registered device. Pass-ta-key abuses this mechanism.
The first technique, known as Pass-ta-key, allows malware running without administrator privileges to impersonate the victim’s trusted device. The attack abuses Chrome’s Trusted Platform Module (TPM)-backed device identity mechanism to send authentication requests to Google’s cloud authenticator as though they originated from the legitimate user’s computer. The result: the cloud authenticator issues a valid authentication assertion. From the relying party’s perspective — the website where the user is logging in — this looks like a successful passkey authentication from a trusted device.
The defense against Pass-ta-key is at the relying party level: Unit 42 recommends that websites enforce a userVerification = required policy and rigorously validate the UV flag. When a relying party requires and verifies user verification (the biometric or PIN step), impersonation by malware that doesn’t have the user’s biometric or PIN is blocked. eBay implemented this validation after Unit 42’s report. The status of every other passkey-enabled website is unknown — this is an ecosystem-wide open item, not a Chrome patch.
Attack 2 — Silver Pass-ta-key: hijacking the re-enrollment window
Chrome’s device key model creates a time window during re-enrollment that Silver Pass-ta-key exploits. Malware forces Chrome to re-enroll the device. Chrome does not create its user-verification key immediately, and in that window an attacker can register one of their own instead. Unit 42 said the service does not check whether a newly registered user-verification key is genuine.
The consequence of a successful Silver Pass-ta-key attack is more durable than Pass-ta-key: the attacker’s device key is now registered as a trusted authentication device. The attacker can authenticate as the victim from their own environment — not just during the window of endpoint compromise, but potentially indefinitely, from any location, without further access to the victim’s device. Unit 42 characterizes this as providing reusable access from an attacker’s own environment after the initial endpoint compromise is resolved.
The defense: credential providers validating attestation on new device key registrations. This is an open Chromium issue filed by Unit 42 — it has not been confirmed as resolved.
Attack 3 — Golden Pass-ta-key: extracting the 32-byte master key
Golden Pass-ta-key is the most significant of the three techniques. The third and most serious technique, Golden Pass-ta-key, targets the Security Domain Secret (SDS) — the master key used to encrypt all passkeys synchronized through Google Password Manager.
The Security Domain Secret is a 32-byte value that sits at the root of Google Password Manager’s synced passkey security model. Every synced passkey private key is encrypted using the SDS. Whoever holds the SDS can decrypt every synced passkey private key in the Google account. Unit 42’s primary research explains precisely why the SDS reaches Chrome’s process memory: in the current Chrome implementation, every device joining or rejoining an account’s security domain retrieves the SDS from the recovery key store, Google’s Trusted Vault service. Chrome appears to follow the same recovery model across platforms — even though the cloud authenticator could enable a more isolated approach — because iOS and Android implementations of Google Password Manager do not rely on the cloud authenticator and must obtain the master key to decrypt synced passkeys.
The attack chain: malware forces Chrome to trigger a fresh device onboarding via the same mechanisms used in Silver Pass-ta-key. During that onboarding, the SDS is retrieved from Google’s Trusted Vault and briefly sits in Chrome’s process memory in plaintext. Malware reads it from memory. “If the attacker forces the victim to re-register with the cloud authenticator and knows the pattern to look for, they can extract the SDS directly from memory.”
Google’s partial remediation: the SDS was previously visible in Chrome’s chrome://device-log/FIDO internal logging page in plaintext. Unit 42 reported this. Google removed it from the logs. The SDS itself still reaches Chrome memory — the logging change addresses discovery convenience, not the underlying exposure path. 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. Once the SDS is stolen, there is no architectural path to invalidate it without Google implementing SDS rotation — which does not currently exist.
What “no CVE” means — and why two of three issues remain open
Unit 42 filed three Chromium issues: the SDS appearing in plaintext in chrome://device-log/FIDO (fixed — removed from logs), missing attestation validation on new verification keys (open — Silver Pass-ta-key), and the absent signature counter check (open — related to Golden Pass-ta-key). A National Vulnerability Database search on August 3, 2026 found no CVE matching the three named techniques, and Google had not answered BleepingComputer’s request for comment at publication.
The absence of CVEs does not mean the issues are resolved — it means they have not been formally assigned. The two open Chromium issues represent the unresolved Silver and Golden attack paths. Until Google implements attestation validation on new device key registrations (Silver) and either prevents the SDS from reaching Chrome memory or implements SDS rotation (Golden), the underlying exposure paths described in the research remain present in Chrome’s architecture.
The correct enterprise response — neither panic nor dismissal
GBlock’s technical analysis captures the right framing precisely: “Two things are true at once, and most coverage picks only one. Passkeys still kill phishing outright. And on a compromised machine, the passkey is not the unbreakable object the marketing implies.” Enterprise security teams need to hold both truths simultaneously.
- Do not delete your passkeys. Passkeys defeat phishing. These attacks all require malware on the endpoint first. If your endpoint hygiene is adequate, these techniques are not your primary risk.
- Enroll a hardware security key alongside any synced passkey for high-value accounts. A YubiKey or equivalent hardware security key stores a device-bound credential that never syncs, never touches Chrome’s enclave state, and cannot be recovered from process memory. This is the strongest available mitigation and remains effective against all three Pass-ta-key techniques.
- Website operators: enforce userVerification = required and validate the UV flag. Pass-ta-key (Attack 1) is defeated by relying parties that correctly implement and validate user verification. This is an ecosystem-wide open item that requires action from every website deploying passkey authentication.
- Credential providers: validate attestation on new device key registrations. Silver Pass-ta-key (Attack 2) is defeated by attestation validation. This requires action from Google and other credential providers, not end users.
- If you observe indicators of Golden Pass-ta-key compromise — Chrome memory dumping, forced passkey re-enrollment events, passkeys appearing you did not create, access returning after password reset — involve your incident response team immediately. The SDS has no rotation path. Until Google implements one, a confirmed Golden compromise requires working with the affected services directly.
- Keep Chrome and Windows updated. None of these attacks work remotely. All require malware on the endpoint. The defense starts with keeping the endpoint clean.
Related DataWater Coverage
- → Device Code Phishing 37x Spike — The MFA Bypass That Survives Password Resets: The Identity Attack That Delivers the Endpoint Access Pass-ta-key Requires
- → Anthropic Disclosure — Mythos 5 Published Malicious PyPI Package: The Supply Chain Attack Class That Delivers Endpoint Malware Enabling Pass-ta-key
- → JADEPUFFER — First AI Agent Ransomware — Autonomous AI Agent With Endpoint Access: The Threat Class That Would Automate Pass-ta-key Credential Extraction
- → Certighost CVE-2026-54121 — The Unscoped Master Key Pattern: krbtgt in Active Directory, SDS in Google Password Manager — Same Architectural Risk, Different Platform
- → GPT-5.5 Offensive Benchmark — 92.4% — The AI Capability That Would Automate Pass-ta-key Memory Extraction at Scale Across Compromised Endpoints
- → Browse the full DataWater threat archive →
Sources and further reading
- Palo Alto Networks Unit 42 — “Pass the Passkey: A Novel Attack Surface in Passwordless Authentication” (Primary Research, Arie Olshtein)
- Bleeping Computer — “New Pass-ta-key attacks let malware hijack Google-synced passkeys”
- The Hacker News — “Google Password Manager Attacks Could Let Malware Hijack Passkey-Protected Accounts”
- GBHackers — “Malware Can Steal Google’s Synced Passkeys Without Password or Fingerprint”
- GBlock — Technical Analysis: “Google Password Manager Passkey Pass-ta-key Attacks 2026”
DataWater publishes daily cybersecurity intelligence for enterprise and government security leaders. Article #53 — August 4, 2026. Previous: Anthropic Disclosure (August 2) · CosmosEscape (July 31) · Copilot for Word AI Worm (July 30). Full archive →
