"Malware running as an ordinary user on a Windows machine can sign into a victim's passkey-protected accounts without a fingerprint, a PIN, or anything at all appearing on the victim's screen," Unit 42 reports.
Three named attack paths and what they target
Researchers at Unit 42 described three post-compromise techniques against Google Password Manager as implemented in Chrome on Windows systems with a Trusted Platform Module (TPM). They gave the techniques memorable names — Pass-ta-key, Silver Pass-ta-key and Golden Pass-ta-key — and said the strongest of the three targets the 32-byte Security Domain Secret (SDS) that protects a user's synced passkeys.
None of the techniques breaks the underlying cryptography, the report stresses; rather, they exploit how Chrome manages device keys, how it re-enrolls devices, and how some relying parties validate whether a human was verified.
How each path works, in the researchers' description
- Pass-ta-key: Malware extracts Chrome's wrapped device identity key and asks the TPM to sign an attacker-controlled request through Windows CNG calls. Unit 42 said Chrome creates the TPM key without a persistent name, exports it as an opaque blob and later reloads it under a flag that suppresses prompts. The authentication assertion returned by Google Cloud Authenticator is valid except for the User Verified (UV) bit, which the researchers said is left unset.
- Silver Pass-ta-key: Malware forces Chrome to re-enroll the device during a window before Chrome creates its user-verification key. Unit 42 said an attacker can register their own key in that interval; the service, they reported, does not check whether newly registered keys came from secure hardware, and assertions signed with the substitute key can carry the UV flag.
- Golden Pass-ta-key: Malware triggers re-enrollment and reads the SDS out of Chrome's process memory while it briefly exists in plaintext, then uses that secret to recover synchronized passkey private keys. Unit 42 said the extracted SDS would enable recovery of private keys and could permit reusable access from the attacker's environment.
Built by Nubivance.
OSINTSights' secure edge-first architecture, AI content pipeline, and serverless ops are designed by Nubivance. We do this for clients too.
Talk to us →What current Chromium source confirms — and what it does not
Unit 42’s write-up is cross-checked against Chromium source as of August 3, 2026. The public code corroborates several architectural facts the researchers relied on: Chrome stores synchronized credential records under %LocalAppData%\\Google\\Chrome\\User Data\\<Profile>\\Sync Data\\LevelDB, client-process data structures do receive 32-byte security-domain secrets, and the implementation creates TPM keys without a persistent name in at least some code paths.
Chromium source independently shows a deferred_uv_key_creation state for newly registered devices. However, the public code alone does not confirm exploitability of every reported server-side key-substitution attack against the latest stable Chrome release, nor does the disclosure claim exploitation in the wild. The researchers and the Chromium code together describe what an attacker can reach on a machine already compromised by local malware; they do not describe how that initial compromise occurs.
Relying parties and service responses: GitHub and eBay
Unit 42 said where the UV bit is left unset, the WebAuthn specification requires a relying party that set userVerification to required to fail the ceremony. The researchers reported that GitHub enforced the UV check, while eBay accepted Unit 42’s test assertion until it fixed the validation gap following disclosure. Unit 42 also reported that eBay now validates the UV flag and that Google removed an earlier SDS exposure from Chrome's FIDO logs — although the researchers said the SDS still reaches the client and remains in Chrome memory.
What the report says users and operators can (and should) do
Unit 42 and the disclosure recommend concrete mitigations that rest with different actors. They advised relying parties to set userVerification to required and to verify the returned UV bit rather than trusting the request setting alone. For credential providers, the report recommends attesting newly enrolled keys, strengthening re-registration and recovery checks, restricting access to local passkey state, and keeping master keys out of client logs and memory.
Google's public support documentation, the report notes, lets users change their Google Password Manager PIN or delete all Password Manager data but does not describe an SDS-specific rotation or revocation control. The disclosure does not establish whether changing the Password Manager PIN or deleting Password Manager data invalidates an SDS an attacker already holds.
Practical state of disclosure and next steps
Unit 42’s disclosure did not include CVE identifiers, affected Chrome versions, or a complete remediation status, and the researchers reported no evidence of exploitation in the wild. A search of the National Vulnerability Database on August 3, 2026, found no CVE matching the three named techniques. As of the same date, searches of Google's public Chrome materials and eBay's support and press pages found no notice documenting the reported changes or a user-facing SDS rotation control.
The Hacker News has reached out to Google for comment on whether a stolen security domain secret survives a Password Manager PIN change, and to Palo Alto Networks for further detail, and will update the story with any response.
Unit 42's findings are a reminder that even strong cryptography can be undermined by the software around it. These are post-compromise techniques — powerful for an attacker who already runs code on a machine, and fixable only through coordinated changes across browsers, credential providers and relying parties.
