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 detailed three attack paths against Chrome's Google Password Manager cloud authenticator, which it calls Pass-ta-key, Silver Pass-ta-key and Golden Pass-ta-key; the strongest targets the master key protecting the user's synced passkeys.

None of this breaks the cryptography. The attacks go after the code around the passkey: how Chrome stores its device keys, how it re-enrolls a device after that state disappears, and whether the site you are signing into bothers to check that a human was verified at all.

The attacks can silently obtain a valid authentication assertion, install an attacker-controlled user-verification key, or extract the 32-byte Security Domain Secret (SDS) used to decrypt synced passkey private keys.

The researchers said the last two paths can provide reusable access from an attacker's own environment after the initial endpoint compromise. The report does not describe exploitation in the wild and gives no CVE identifiers, affected Chrome versions, or complete remediation status.

A search of the National Vulnerability Database on August 3, 2026, found no CVE matching the three named techniques.

The research is limited to Google Password Manager in Chrome on Windows systems equipped with a Trusted Platform Module (TPM), and every path begins with malware already running on the victim's device.

Chromium source as of August 3 corroborates parts of the architecture, not that the latest stable Chrome release remains exploitable. These are post-compromise techniques. They describe what an attacker reaches on a machine already lost, not how the machine was lost.

The attack begins with local reconnaissance. Chrome stores synchronized credential records under %LocalAppData%\Google\Chrome\User Data\\Sync Data\LevelDB. The researchers said an unprivileged process can read enough metadata to identify the relying parties and usernames tied to the victim's passkeys, along with credential identifiers and encrypted private-key material.

First Attack Path

The first technique, Pass-ta-key, extracts Chrome's wrapped device identity key and asks the same TPM to sign an attacker-controlled request through Windows Cryptography API: Next Generation (CNG) calls.

Current Chromium source shows why that blob is reusable: Chrome creates the TPM key without a key name, which a comment in the code says stops it being persisted to disk. Chrome then exports the key as an opaque blob and reloads it later under a flag that suppresses any prompt. A TODO in the same file points to Chromium issue 398125799, proposing that those keys be labelled instead.

Google Cloud Authenticator returns a valid assertion, and the only thing separating it from one produced after a real user check is a single bit, the User Verified (UV) flag, left unset. The current Web Authentication specification says a relying party that sets userVerification to required must fail the ceremony when that bit is absent.

The researchers said GitHub enforced the check, while eBay accepted its test assertion until the company fixed the validation gap following disclosure. Of the three paths, this is the one that turns on a check the relying party controls, so a site can fail it regardless of how the cloud service behaves, and of the two Unit 42 names, one did.

Second Attack Path

Silver Pass-ta-key targets the next layer. 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 key came from secure hardware. Assertions signed with that key carry the UV flag, which the researchers said enables later logins without the victim's device. Current Chromium source independently confirms that newly registered devices can retain a deferred_uv_key_creation state, but the public code alone does not verify the reported server-side key-substitution attack against the latest stable Chrome release.

The disclosure does not say whether the production service now checks hardware attestation before accepting a replacement key, a check Unit 42 recommends to mitigate this path.

Third Attack Path

Golden Pass-ta-key goes after the SDS itself. Unit 42 said malware can trigger re-enrollment, read the secret out of Chrome's process memory while it briefly sits there in plaintext, and use it to recover synchronized passkey private keys.

Current Chromium source corroborates the underlying exposure: Chrome creates or receives 32-byte security-domain secrets in client-process data structures. That confirms the secret enters Chrome memory, though reliable extraction, account takeover, and persistence across future secret epochs remain sourced to Unit 42 or unresolved.

The researchers said Google removed an earlier SDS exposure from Chrome's FIDO logs and that eBay now validates the UV flag. It said the secret still reaches the client and stays in Chrome's memory, so the logging change does not close the path it describes.

The disclosure does not establish whether all three attack paths have been closed. As of August 3, 2026, searches of Google's public Chrome materials and eBay's support and press pages found no notice documenting either reported change, and none of them describes a way for a user to check whether an SDS was exposed.

Google's public support documentation lets users change their Google Password Manager PIN or delete all Password Manager data, but it does not describe an SDS-specific rotation or revocation 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 on the research, and will update this story with any response.

Relying parties should set userVerification to required and verify the returned UV bit rather than trusting the request setting alone. Credential providers should attest newly enrolled keys, strengthen re-registration and recovery checks, restrict access to local passkey state, and keep master keys out of client logs and memory.

The reviewed sources do not say whether changing the Google Password Manager PIN or deleting Password Manager data invalidates a secret an attacker already holds, which is what a user who suspects compromise would need in order to act.