Threat reportVulnerabilityTL-2026-1852
Pass-ta-key Attacks Enable Malware to Hijack Google-Synced Passkeys via Chrome/TPM/Google Cloud Authenticator Weaknesses
Pass-ta-key Attacks Enable Malware to Hijack Google-Synced (TL-2026-1852), also tracked as Pass the Passkey, is a high-severity software vulnerability, first published 2026-08-03. It has no confirmed attribution, affects Google Chrome Browser, maps to 10 MITRE ATT&CK techniques (T1005, T1055, T1071), and is covered by 9 detection rules and 8 indicators of compromise.
- Severity
- HIGHAssessed severity
- CVEs
- 0None referenced
- Techniques
- 10MITRE ATT&CK
- Actors
- 0Not attributed
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 8Indicators of compromise
Key facts for TL-2026-1852
- Threat ID
- TL-2026-1852
- Also known as
- Pass the Passkey, Pass-the-Passkey attack family
- Severity
- HIGH
- Status
- ACTIVE
- Category
- VULNERABILITY
- First published
- Last reviewed
- Motivation
- UNKNOWN
- Target sectors
- technology, ecommerce, finance, government administration, health, all
- Target regions
- Global
- Detection rules
- 9
- Indicators of compromise
- 8
How Pass-ta-key Attacks Enable Malware to Hijack Google-Synced works
Unit 42 (Palo Alto Networks) disclosed three novel post-compromise attacks collectively called 'Pass-ta-key' targeting Google Password Manager (GPM) in Chrome on Windows devices with a Trusted Platform Module (TPM). The attacks — Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key — allow unprivileged malware on an already-compromised device to impersonate a trusted device (bypassing user verification), register attacker-controlled keys with the cloud authenticator, and extract the Security Domain Secret (SDS) master key from Chrome process memory to decrypt all synced passkey private keys. The SDS has no rotation or revocation mechanism, exposing all current and future synced passkeys. eBay was confirmed vulnerable (UV flag validation bypass, since fixed); GitHub properly validated the flag and was not vulnerable. No CVEs were assigned as of publication.
On August 3, 2026, Palo Alto Networks' Unit 42 published 'Pass the Passkey: A Novel Attack Surface in Passwordless Authentication,' the third installment in a research series examining the security of passwordless authentication. The research identifies three attack classes against Google's synced passkey ecosystem, specifically targeting Google Password Manager in Chrome on Windows platforms with TPM-equipped devices. All three attacks are post-compromise techniques requiring malware already running on the victim's device with no elevated privileges needed.
The first attack, Pass-ta-key (device identity impersonation), exploits the Google Cloud Authenticator's inability to distinguish between requests signed with the TPM-backed identity key versus the user verification (UV) key. Chrome creates the TPM identity key via NcryptCreatePersistedKey without a key name (pszKeyName == NULL, Chromium issue #398125799), making the key ephemeral and exportable. Chrome exports the key as an opaque blob via NcryptExportKey (NCRYPT_OPAQUE_KEY_BLOB, encrypted by a TPM-resident key) and stores it as wrapped_identity_private_key in the passkey_enclave_state file. Malware extracts this blob from disk or Chrome process memory and invokes standard Windows CNG APIs (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) to sign authentication requests — all without privilege escalation, mimicking Chrome's own API pattern. The cloud authenticator returns a valid assertion regardless of whether the identity key or UV key signed it; the only difference is the UV flag bit in the authenticator data (0 for identity key, 1 for UV key). Relying parties that fail to validate the UV flag accept the assertion. The researchers demonstrated this against eBay, which configured userVerification=required but did not validate the UV flag in the authenticator data, allowing full account takeover without user interaction, biometrics, or device unlock. eBay fixed the issue after disclosure. GitHub properly validates the UV flag and rejects such assertions with an error message.
The second attack, Silver Pass-ta-key (user verification bypass), exploits gaps in the device re-registration workflow. The attacker forces Chrome to re-onboard the device by either issuing a device/forget command to the cloud authenticator (signed with the identity key the attacker already controls) or directly deleting the victim's passkey_enclave_state file — which has no built-in protections against removal. On Windows, device onboarding completes in two stages: the first passkey use creates TPM keys and starts background onboarding while prompting for the GPM recovery PIN, but Chrome defers UV key creation to avoid confusing users with back-to-back PIN prompts, entering a uv_key_pending state. The cloud authenticator accepts a UV key registration without hardware attestation during this window. The attacker generates an asymmetric key pair in their own environment and sends a device/add_uv_key command to the cloud authenticator, registering their own public key. The cloud authenticator does not validate whether the new UV key originates from secure hardware; it simply stores the attacker's public key. After registration, the attacker can sign assertion requests with their forged UV key, setting the UV flag to 1, and authenticate from their own environment without further access to the victim's device. This enables full automated account takeover across all passkey-protected accounts.
The third and most severe attack, Golden Pass-ta-key (master key extraction), targets the Security Domain Secret (SDS) — a 32-byte symmetric master key used to encrypt all synced passkey private keys. When a device joins or rejoins an account's security domain, Chrome retrieves the SDS from Google's Trusted Vault service. The cloud authenticator includes a mechanism allowing Chrome to facilitate recovery where the key cannot be decrypted on the client device, but Chrome does not use this mechanism — it recovers the SDS in accessible form. The researchers initially found the SDS in plaintext in Chrome's FIDO logs at chrome://device-log/FIDO (Chromium Issue #464305542). After disclosure, Google removed the SDS from logging output. However, the SDS still reaches the client during device onboarding and remains in Chrome's process memory. An attacker who forces re-registration by deleting passkey_enclave_state can monitor the filesystem for recreation, dump Chrome's process memory, and extract the SDS. With the SDS, the attacker reads WebauthnCredentialSpecifics proto-encoded records from Chrome's sync database at %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB and decrypts the encrypted private key fields. This recovers all passkey private keys. Critically, Google's implementation provides no mechanism to rotate or revoke the SDS — all current and future synced passkeys remain protected by the same master key. Even if compromise is detected, remediation is limited. The attacker can authenticate from any device as a fully verified user to any service where the victim uses passkeys.
Root cause analysis spans multiple layers: the cloud authenticator's trust model does not validate UV key attestation (Silver); the SDS is unnecessarily exposed to the client environment (Golden); Chrome stores sensitive passkey state in files accessible to unprivileged processes (all attacks); Chrome's TPM identity key is created without a persistent name, enabling opaque blob extraction (Pass-ta-key); and the cloud authenticator does not enforce user verification at the cryptographic level, relying on a single UV flag bit whose validity depends on the relying party's validation. The Chromium source code reference for the enclave manager is at chrome/browser/webauthn/enclave_manager.h. The cloud authenticator operates at enclave.ua5v.com over WebSocket (wss://enclave.ua5v.com/enclave) using the Noise_NK_P256_AESGCM_SHA256 protocol, with OAuth2 tokens scoped to https://www.googleapis.com/auth/secureidentity.action. The protocol uses the NK pattern (client unauthenticated, server has a known static public key hard-coded in Chrome), P256 ECDH, AES-GCM encryption, and SHA256 hashing. No evidence of in-the-wild exploitation was found at publication.
MITRE ATT&CK techniques used in TL-2026-1852
Collection
Defense Evasion
Command and Control
T1071 Application Layer Protocol
Initial Access
Persistence
Credential Access
T1528 Steal Application Access Token; T1552 Unsecured Credentials; T1555 Credentials from Password Stores
Lateral Movement
T1550 Use Alternate Authentication Material
defense-impairment
Affected products and versions in Pass-ta-key Attacks Enable Malware to Hijack Google-Synced
- Google — Chrome Browser
Vulnerable versions: All versions using Google Password Manager with passkey sync on Windows
Fixed in: No comprehensive fix available as of August 2026 - Google — Google Password Manager (Cloud Authenticator)
Vulnerable versions: All versions using enclave.ua5v.com cloud authenticator
Fixed in: Partial: SDS removed from FIDO logs (Chromium #464305542) - Google — Trusted Vault
Vulnerable versions: SDS recovery mechanism during device onboarding exposes master key to client
Fixed in: No fix for SDS exposure in process memory as of August 2026 - Microsoft — Windows (TPM 2.0)
Vulnerable versions: Windows 10, Windows 11 with TPM 2.0
Fixed in: No platform fix required — CNG API behavior is by design - eBay — WebAuthn Authentication
Vulnerable versions: All versions prior to August 2026 fix
Fixed in: Fixed after Unit 42 disclosure — UV flag now properly validated - GitHub — WebAuthn Authentication
Vulnerable versions: Not vulnerable — properly validates UV flag
Fixed in: N/A
Remediation for Pass-ta-key Attacks Enable Malware to Hijack Google-Synced
Patches
- Google: Remove SDS exposure from Chrome process memory during device onboarding by using server-side decryption
- Google: Implement SDS rotation mechanism so compromised master keys can be invalidated
- Google: Add attestation verification for newly registered UV keys at the cloud authenticator
- eBay: Validate UV flag in WebAuthn assertion responses (completed after disclosure)
Immediate actions
- Relying parties must require userVerification=required and strictly validate the UV flag in every WebAuthn assertion response
- Monitor for unexpected GPM recovery PIN prompts during normal passkey usage as potential re-onboarding manipulation
- Audit for non-Chrome processes accessing Chrome process memory or the passkey_enclave_state file
- Detect Chrome sync database (LevelDB) access by non-browser processes
- Deploy EDR rules to detect Windows CNG API calls (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) from non-browser processes targeting Chrome identity key blobs
Workarounds
- Users who suspect compromise should change passwords on all passkey-protected accounts and consider unregistering/re-enrolling their device
- Use hardware-bound FIDO2 security keys (not synced passkeys) for high-value accounts
- Organizations should deploy EDR rules to detect non-browser processes accessing Chrome's passkey_enclave_state and LevelDB files
- Monitor for authentication assertions with constant signCount=0 values indicating potential passkey cloning
- Audit Google account devices for unexpected enrollments and remove unknown devices
- Regularly review authentication logs for unusual access patterns from unfamiliar IPs or devices
Longer-term hardening
- Google must implement SDS rotation and revocation mechanisms to invalidate compromised master keys
- Google should implement hardware attestation validation for newly registered UV keys at the cloud authenticator
- Chrome should protect passkey_enclave_state and sync database with platform-level access controls
- Cloud authenticator should restrict device/forget and device/add_uv_key commands with additional verification
- Chrome should use named/labeled TPM keys (Chromium issue #398125799) to prevent opaque blob extraction
- Credential manager providers should adopt designs where cryptographic operations are performed server-side without transferring underlying key material to the client
Weaknesses (CWE) in Pass-ta-key Attacks Enable Malware to Hijack Google-Synced
CWE-287, CWE-522, CWE-200, CWE-276, CWE-863, CWE-306, CWE-602, CWE-525
Timeline of Pass-ta-key Attacks Enable Malware to Hijack Google-Synced
- Unit 42 responsibly discloses the SDS logging exposure (Chromium Issue #464305542), the three attack vectors, and UV flag validation gaps to Google, eBay, GitHub, and other affected relying parties
- Unit 42 discovers the 32-byte Security Domain Secret (SDS) exposed in plaintext in Chrome's FIDO device logs at chrome://device-log/FIDO. The SDS is the master key protecting all synced passkey private keys
- Unit 42 publishes 'The Hidden Mechanisms of Passwordless Authentication' documenting the Google Cloud Authenticator architecture: Noise_NK_P256_AESGCM_SHA256 protocol, TPM identity/UV keys, the Security Domain (SDS + member keys + wrapping keys), and the GPM PIN recovery flow
- Unit 42 begins multi-part research series examining Google Cloud Authenticator and passkey security architecture, starting with the undocumented enclave.ua5v.com cloud authenticator domain
- Google removes the SDS from Chrome's FIDO device logging output (Chromium #464305542). However, the SDS remains accessible in Chrome's process memory during device onboarding as Chrome still retrieves and temporarily holds the secret in plaintext. No SDS rotation or revocation mechanism is implemented
- eBay fixes UV flag validation after Unit 42 disclosure — eBay required userVerification=required but did not validate the UV flag in authenticator data, allowing the Pass-ta-key attack to succeed. GitHub is confirmed to properly validate the UV flag and is not vulnerable
- Chromium source code confirms the enclave_manager.h architecture, webauthn_credential_specifics.proto for LevelDB records, and the unexportable_key_win.cc TODO (issue #398125799) proposing labeled TPM keys to prevent opaque blob extraction
- BleepingComputer and The Hacker News publish articles on the Pass-ta-key attacks. CISA KEV database shows no related entries. No CVEs assigned to the three attack techniques. No evidence of in-the-wild exploitation at publication
- Unit 42 publishes 'Pass the Passkey: A Novel Attack Surface in Passwordless Authentication' (Part 3) disclosing all three Pass-ta-key attack variants: Pass-ta-key (device impersonation), Silver Pass-ta-key (UV key substitution), and Golden Pass-ta-key (SDS master key extraction)
Sources cited for Pass-ta-key Attacks Enable Malware to Hijack Google-Synced
- Pass the Passkey: A Novel Attack Surface in Passwordless Authentication (Unit 42)
- Google Cloud Authenticator: The Hidden Mechanisms of Passwordless Authentication (Unit 42)
- New Pass-ta-key attacks let malware hijack Google-synced passkeys (BleepingComputer)
- Google Password Manager Attacks Could Let Malware Hijack Passkey-Protected Accounts (The Hacker News)
- Google Authenticator's Hidden Passkey Architecture Could Open New Passwordless Attack Paths (CyberSecurity News)
- Google Cloud Authenticator & Passkey Attack — Detection Guidance (cyfar.ca)
- Chromium Issue #464305542 — SDS exposure in Chrome FIDO device logs
- Chromium Issue #398125799 — Labeled TPM keys (unexportable_key_win.cc TODO)
- Chromium Source — enclave_manager.h (enclave/cloud authenticator manager)
- Chromium Source — webauthn_credential_specifics.proto
- Microsoft NCryptCreatePersistedKey function (CNG API)
- Advancing Key Protection in Windows Using VBS (Microsoft Tech Community)
Detection coverage for TL-2026-1852
As of 2026-08-03, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1852 across Splunk SPL, Microsoft KQL and Sigma, covering 8 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.