Malware affecting Google Password Manager runs as a regular user on a Windows computer and can log in to a victim's passkey-protected accounts without a fingerprint, PIN, or anything displayed on the victim's screen.
See also: Google Password Manager: Passkeys will automatically sync across all devices
The Unit 42 team analyzed three attack vectors against Google Password Manager's cloud authenticator in Chrome, referred to as Pass-ta-key, Silver Pass-ta-key , and Golden Pass-ta-key. The most powerful targets the master key that protects a user's synchronized passkeys.
None of these attacks break the cryptography. Instead, they exploit the code surrounding the passkey: how Chrome stores its device keys, how it re-enrolls a device after that state disappears, and whether the website being accessed checks whether a human has been authenticated.
Attacks can silently obtain a valid identity statement, install a user authentication key controlled by the attacker, or extract the 32-byte Security Domain Secret (SDS) used to decrypt synchronized private passkeys.
The researchers noted that the latter two routes can provide reusable access from the attacker's environment after the initial endpoint compromise. The report does not describe an exploit in the wild and does not provide CVE IDs, Chrome versions affected, or full remediation status.
A search of the National Vulnerability Database on August 3, 2026, found no CVEs matching the three named techniques.
The investigation is limited to Google's Password Manager in Chrome on Windows systems equipped with a Trusted Platform Module (TPM), and each path begins with malware already running on the victim's device.
See also: New Tab: Chrome extensions with new Google defense
The attack starts with local authentication. Chrome stores synchronized credential files under %LocalAppData%\Google\Chrome\User Data\
The first technique, Pass-ta-key, extracts Chrome's wrapped device identity key and asks the same TPM to sign a request controlled by the attacker via Windows Cryptography API: Next Generation (CNG).
The current Chromium source code shows why this blob is reusable: Chrome creates the TPM key without a key name, which prevents it from being stored on disk. Chrome then exports the key as an opaque blob and reloads it later under a flag that suppresses any prompting. A TODO in the same file points to Chromium issue 398125799, suggesting that these keys be marked.
Google Cloud Authenticator returns a valid claim, and the only difference from the one produced after actual user verification is a single bit, the User Verified (UV) flag, which remains unset. The current Web Authentication specification states that a dependent entity that defines userVerification as required must fail the ceremony when this bit is absent.
The researchers noted that GitHub enforced the check, while eBay accepted its test statement until the company fixed the validation gap after the disclosure. Of the three paths, this is the one that triggers a dependent entity-controlled check, allowing a website to fail it regardless of how the cloud service behaves.
Silver Pass-ta-key takes it to the next level. The malware forces Chrome to re-enroll the device. Chrome doesn't generate its user authentication key immediately, and during that window, an attacker can register one of their own.
🔑 Secure your passwords with Proton Pass
Password manager from Proton — end-to-end encryption, passkeys, built-in 2FA, and monitoring for leaks of your credentials.
- ✔ Encrypted storage of passwords & passkeys
- ✔ Notification if any of your passwords are leaked (Dark Web Monitoring)
- ✔ Free version — on all devices
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
See also: Google can't stop its data collection
Unit 42 said the service does not check whether a newly registered key came from secure hardware. Statements signed with that key carry the UV flag, which allows future connections without the victim's device.
