Threat reportVulnerabilityTL-2026-1843
Google Password Manager — Three Post-Compromise Attack Paths Against Chrome Cloud Authenticator (Pass-ta-key / Silver Pass-ta-key / Golden Pass-ta-key)
Google Password Manager (TL-2026-1843), also tracked as Pass-ta-key, is a high-severity software vulnerability, first published 2026-08-03. It has no confirmed attribution, affects Google Chrome, maps to 11 MITRE ATT&CK techniques (T1003, T1005, T1078), and is covered by 9 detection rules and 12 indicators of compromise.
- Severity
- HIGHAssessed severity
- CVEs
- 0None referenced
- Techniques
- 11MITRE ATT&CK
- Actors
- 0Not attributed
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 12Indicators of compromise
Key facts for TL-2026-1843
- Threat ID
- TL-2026-1843
- Also known as
- Pass-ta-key, Silver Pass-ta-key, Golden Pass-ta-key, Pass the Passkey
- Severity
- HIGH
- Status
- ACTIVE
- Category
- VULNERABILITY
- First published
- Last reviewed
- Motivation
- UNKNOWN
- Target sectors
- all
- Target regions
- Worldwide
- Detection rules
- 9
- Indicators of compromise
- 12
How Google Password Manager works
Unit 42 (Palo Alto Networks) disclosed three attack paths (Pass-ta-key, Silver Pass-ta-key, Golden Pass-ta-key) targeting Chrome's Google Password Manager cloud authenticator on Windows with TPM. The strongest path recovers the 32-byte Security Domain Secret (SDS) from Chrome process memory to decrypt synced passkey private keys. All paths require prior device compromise. No in-the-wild exploitation observed.
Unit 42 (Palo Alto Networks) published research disclosing three novel attack paths collectively called the 'Pass-ta-key' family, targeting Google Password Manager's cloud authenticator implementation in Chrome on Windows devices with a Trusted Platform Module (TPM). The attacks were responsibly disclosed to Google prior to publication via issues.chromium.org and issuetracker.google.com.
Architecture Background: Google Password Manager on Chrome uses a cloud authenticator service at enclave.ua5v.com that establishes encrypted WebSocket sessions via the Noise_NK_P256_AESGCM_SHA256 protocol. Devices maintain two TPM-backed key pairs: an identity key ('something you have') for device authentication, and a User Verification (UV) key ('something you are') gated by Windows Hello biometrics/PIN. All synced passkey private keys are encrypted under a 32-byte Security Domain Secret (SDS), a symmetric master key generated during first-device onboarding and stored wrapped per-device. The cloud authenticator runs under AMD SEV-SNP using the Oak framework with reproducible builds.
Attack Path 1 — Pass-ta-key (Device Identity Impersonation): Malware extracts the TPM-wrapped identity private key from Chrome's passkey_enclave_state file (stored at %LocalAppData%\Google\Chrome\User Data\<Profile>\passkey_enclave_state) or from Chrome's process memory. It then uses standard Windows CNG APIs — NCryptOpenStorageProvider, NCryptImportKey, and NCryptSignHash — to sign authentication request hashes using the victim's TPM, all without elevated privileges or user interaction. The cloud authenticator returns a valid authentication assertion signed with the device identity key, which differs from a user-verified assertion only by the UV flag (a single bit in WebAuthn authenticator data). Relying parties that set userVerification to 'preferred' rather than 'required' accept this assertion. eBay initially accepted test assertions without the UV flag and fixed the validation gap after disclosure; GitHub correctly enforced the UV check from the start.
Attack Path 2 — Silver Pass-ta-key (Persistent UV-Bypassing Takeover): Rather than skipping UV verification, the attacker invalidates the legitimate UV key and registers their own. The attacker sends a device/forget command (signed with the stolen identity key) to the cloud authenticator, or simply deletes the passkey_enclave_state file — both methods force Chrome to re-onboard with the cloud service. During re-onboarding, Chrome enters a uv_key_pending state that defers UV key creation to avoid presenting two PIN prompts back-to-back. The attacker exploits this gap by generating their own asymmetric key pair and sending a device/add_uv_key command to the cloud authenticator. Critically, the cloud authenticator does not validate hardware attestation of newly registered UV keys, accepting arbitrary public keys. The attacker can then authenticate from their own environment without the victim's device being online, producing assertions fully indistinguishable from legitimate user-verified responses (UV flag = 1). This enables persistent, reusable access across all victim accounts.
Attack Path 3 — Golden Pass-ta-key (Master Key Extraction): The most severe attack targets the 32-byte Security Domain Secret (SDS) — the symmetric master key protecting all synced passkey private keys for the victim's Google account. Unit 42 discovered that the SDS was exposed in plaintext in Chrome's device log at chrome://device-log/FIDO during registration, simply by opening the diagnostic page. After disclosure (issuetracker.google.com/issues/464305542), Google removed the SDS from logging output, but the fundamental exposure remains: the SDS is still sent to the client in accessible form via Google's Trusted Vault service during device join/recovery, and it briefly resides in plaintext within Chrome's process memory. By forcing re-onboarding (via state file deletion), dumping Chrome's process memory to extract the SDS, then reading WebauthnCredentialSpecifics records from the Chrome sync database at %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB, an attacker can decrypt all current and future synced passkey private keys. Critically, Google's implementation provides no mechanism to rotate or revoke the SDS, meaning a stolen SDS grants permanent access to all passkeys past, present, and future.
Chromium source code corroboration: The current Chrome source confirms that newly registered devices can retain a deferred_uv_key_creation state (enclave_local_state.proto) and that 32-byte security domain secrets are created in client-process memory data structures (enclave_manager.cc). A TODO in Chromium source references issue 398125799 proposing that TPM keys be labelled rather than created without names.
Remediation Status: Google removed the SDS from Chrome's device logs. eBay fixed its UV flag validation. Chromium has a pending fix for labelling TPM keys (issue 398125799). However, the SDS still reaches client memory, no SDS rotation mechanism exists, and the cloud authenticator still does not validate UV key attestation. No CVE was assigned as of publication, and no Chrome patch version has been confirmed to fully address all three paths.
MITRE ATT&CK techniques used in TL-2026-1843
Credential Access
T1003 OS Credential Dumping; T1552 Unsecured Credentials; T1555 Credentials from Password Stores; T1606 Forge Web Credentials; T1649 Steal or Forge Authentication Certificates
Collection
stealth
Persistence
defense-impairment
T1556 Modify Authentication Process; T1685 Disable or Modify Tools
Command and Control
Affected products and versions in Google Password Manager
- Google — Chrome
Vulnerable versions: All versions on Windows with TPM prior to SDS log fix and TPM key labelling patch
Fixed in: Partial: SDS removed from device logs post-disclosure - Google — Google Password Manager
Vulnerable versions: All versions on Chrome/Windows with cloud authenticator (current) — no full fix confirmed - Google — Google Cloud Authenticator
Vulnerable versions: All versions — UV key attestation not validated; SDS delivered to client in accessible form - Microsoft — Windows (TPM 2.0)
Vulnerable versions: Windows 10, Windows 11 with TPM 2.0 — CNG APIs available to unprivileged users
Remediation for Google Password Manager
Patches
- Chromium TPM key labelling fix (issue 398125799)
- Google SDS log removal (issuetracker.google.com/issues/464305542) — already deployed
- eBay UV flag server-side validation — already deployed
Immediate actions
- Enforce userVerification=required server-side on all relying party passkey integrations
- Validate the UV flag bit in WebAuthn authenticator data on every assertion, not just the request setting
- Monitor for unexpected Google Password Manager recovery PIN prompts during routine passkey use
- Deploy EDR rules detecting non-Chrome process access to %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB
Workarounds
- Relying parties should validate signCount as a detection signal; treat constant counters as suspicious
- Layer passkey assertions with additional risk signals for high-value transactions
- Maintain general endpoint hygiene (anti-malware, least privilege, application control)
Longer-term hardening
- Implement SDS rotation/revocation mechanism in Google Password Manager
- Move cryptographic operations to cloud authenticator without transferring SDS to client memory
- Implement hardware attestation validation for newly registered UV keys
- Label TPM keys so they persist properly and cannot be silently reloaded under different flags
- Harden re-registration and recovery flows with additional verification requirements
Weaknesses (CWE) in Google Password Manager
Timeline of Google Password Manager
- Unit 42 begins research into Google Password Manager cloud authenticator architecture and the security properties of Chrome's synced passkey ecosystem
- Unit 42 discovers Golden Pass-ta-key attack: the 32-byte Security Domain Secret (SDS) is exposed in plaintext in Chrome's device log at chrome://device-log/FIDO and remains accessible in Chrome process memory during registration
- Unit 42 discovers Pass-ta-key attack: Chrome's TPM-wrapped identity key can be extracted and used to sign authentication requests via CNG APIs without privilege escalation or user interaction
- Unit 42 discovers Silver Pass-ta-key attack: the cloud authenticator does not validate hardware attestation of newly registered UV keys, enabling attacker-controlled key substitution during re-enrollment
- Unit 42 responsibly discloses all three attack paths to Google via issues.chromium.org (issues 464996836, 465359916) and issuetracker.google.com (issue 464305542)
- Google removes Security Domain Secret (SDS) from Chrome's device log output following Unit 42's report; the SDS remains accessible in Chrome process memory and Trusted Vault recovery flow
- eBay addresses UV flag validation gap following Unit 42's disclosure, implementing server-side enforcement of userVerification=required for passkey authentication assertions
- SpecterOps publishes independent analysis of the 'Pass-the-Passkey Family of Attacks', providing broader attack taxonomy on passkey system vulnerabilities
- The Hacker News publishes article summarizing the three attack paths and their implications for passkey-based authentication security
- Unit 42 publishes full technical research detailing all three Pass-ta-key attack paths against Chrome's Google Password Manager cloud authenticator on Windows with TPM
Sources cited for Google Password Manager
- Pass the Passkey: A Novel Attack Surface in Passwordless Authentication
- The Hidden Mechanisms of Passwordless Authentication
- Google Password Manager Attacks Could Let Attackers Decrypt Your Passkeys
- Chromium Issue — SDS Exposure in Chrome Device Logs
- Chromium Issue — Enclave Authenticator Design Response
- Chromium Issue — Signature Counter Challenges in Synced Passkey Systems
- Chromium Source — enclave_manager.cc (Cloud Authenticator Client Manager)
- Chromium Source — enclave_local_state.proto
- Chromium Source — webauthn_credential_specifics.proto
- Chromium Issue — TPM Key Naming/labelling (TODO ref)
- Pass-the-Passkey Family of Attacks — SpecterOps Analysis
- Vaultjacking: Phishing the Google Password Manager Vault
Detection coverage for TL-2026-1843
As of 2026-08-03, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1843 across Splunk SPL, Microsoft KQL and Sigma, covering 12 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.