Malware Can Hijack Passkey-Protected Accounts Through Google Password Manager Without Touching Your Screen

Passkeys were supposed to fix passwords. Malware running as a plain, unprivileged Windows user process can silently authenticate to passkey-protected accounts through Google Password Manager without triggering a fingerprint prompt, a PIN dialog, or any visible interaction on the victim's screen whatsoever.

That is the headline finding from Palo Alto Networks' Unit 42, which has mapped three distinct attack paths against Chrome's cloud-based passkey implementation. They have given them the imaginative names Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key. The last one is the most serious: it targets the 32-byte Security Domain Secret (SDS) that encrypts the user's synced passkey private keys.

None of this involves breaking the cryptography. The attacks go after the plumbing around passkeys rather than the underlying maths: how Chrome manages device keys, how it re-enrolls when that state disappears, and whether the website you are signing into actually bothers checking that a human was involved.

The research is scoped to Google Password Manager in Chrome on Windows machines with a Trusted Platform Module. Every attack path starts with malware already running on the device. These are post-compromise techniques, not initial access methods. They describe what an attacker can reach once a machine is already lost, which is still a meaningful escalation.

What each path actually does

The first technique begins with local reconnaissance. Chrome's synced credential records live in a LevelDB store under the user's AppData folder, readable by an unprivileged process. From there an attacker can identify which sites the victim has passkeys for, grab credential identifiers, and get hold of encrypted private-key material.

Pass-ta-key then extracts Chrome's wrapped device identity key and uses it to sign an attacker-controlled authentication request through standard Windows CNG calls. The current Chromium source explains the exposure: Chrome creates the TPM key without a persistent name, exports it as an opaque blob, and reloads it later under a flag that suppresses any user prompt. There is even a TODO comment in the code pointing to a Chromium issue that proposes fixing this by labelling the keys instead.

The assertion Chrome's cloud authenticator returns is technically valid. The only tell is that the User Verified flag is unset. The WebAuthn spec says any relying party that configured userVerification as required must reject a ceremony where that bit is absent. GitHub enforces this check. eBay did not, until Unit 42 disclosed the issue and the company patched its validation.

Silver Pass-ta-key targets device enrollment. Chrome does not generate its user-verification key immediately, and in that gap an attacker can register their own key instead. Unit 42 says the service does not check whether a newly registered key came from secure hardware. Assertions signed with the substituted key carry the UV flag set correctly, enabling logins from the attacker's own environment after the initial compromise. The Chromium source confirms Chrome can sit in a deferred UV key creation state, though whether the production service has since added hardware attestation checks is not publicly confirmed.

Golden Pass-ta-key goes after the SDS directly. Malware triggers re-enrollment, then reads the secret from Chrome's process memory while it briefly sits there in plaintext. With the SDS in hand, an attacker can decrypt synced passkey private keys. The Chromium source confirms the secret enters client-process memory in 32-byte data structures. Unit 42 notes that Google already removed an earlier SDS exposure from Chrome's FIDO logging, but says the secret still reaches the client and remains in memory, so the logging fix does not close this path.

What has actually been fixed

Honestly, it is hard to say. There are no CVE identifiers attached to any of the three techniques. A search of the National Vulnerability Database on 3 August 2026 found nothing matching the named attacks. Neither Google's Chrome materials nor eBay's public pages carry any notice documenting the changes Unit 42 credits them with making. The disclosure does not confirm whether all three paths have been closed in the current stable Chrome release.

Google's public support documentation does let users change their Password Manager PIN or delete all Password Manager data. What it does not describe is any SDS-specific rotation or revocation mechanism. Whether changing the PIN invalidates a secret an attacker already holds is precisely the question a compromised user would need answered, and right now there is no public answer.

What can actually be done

For website operators, the fix for the first attack path is straightforward: set userVerification to required and actually verify the returned UV flag rather than trusting the request setting alone. Two sites were tested; one failed the assertion, one did not. That is a server-side control that works regardless of how Chrome or Google's cloud service behaves.

For credential providers, Unit 42 recommends attesting newly enrolled keys, tightening re-registration and recovery flows, restricting access to local passkey state, and keeping master secrets out of client logs and memory.

For end users who suspect compromise, the situation is murkier. The reviewed sources do not say whether changing the Google Password Manager PIN or deleting Password Manager data actually invalidates a secret an attacker has already extracted. That gap in the remediation story is not a minor detail.