Medium cybersecurity update: Google Password Manager Attacks Could Let Malware Hijack Passkey-Protected Accounts. NetworkFix reviewed the available source material to summarize the security issue, its potential impact and the defensive actions administrators should prioritize.
What Happened
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 Google Password Manager Attacks Could Let Malware Hijack Passkey-Protected Accounts Reach out to get featured—contact us to send your exclusive story idea, research, hacks, or ask us a question or leave a comment/feedback! Swati Khandelwal Aug 03, 2026 Authentication / Web Security 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. 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.
Technical Details
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. 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. 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. 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 researchers said GitHub enforced the check, while eBay accepted its test assertion until the company fixed the validation gap following disclosure.
Security Impact
Organizations using the affected technology should treat the report according to its medium severity classification. 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. 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. 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. The researchers said Google removed an earlier SDS exposure from Chrome's FIDO logs and that eBay now validates the UV flag.
Recommended Actions
- Identify whether the affected product, service or software is present in the environment.
- Review the original vendor or research advisory and verify affected versions before making configuration changes.
- Apply vendor-provided security updates or mitigations as soon as operationally practical.
- Review relevant security logs and monitoring alerts for signs of suspicious activity associated with the reported issue.
- Use the CVE identifiers, where available, to validate exposure through vulnerability-management and asset-inventory tools.
Security Details
- Severity: Medium
- Original source: The Hacker News
Why This Matters
Cybersecurity teams should use reports like this as an input to risk-based vulnerability and threat management rather than relying on headline severity alone. Exposure depends on whether the affected technology is deployed, reachable by an attacker and protected by compensating controls. Confirming asset ownership, affected versions and available vendor fixes helps teams prioritize remediation while avoiding unnecessary emergency changes.
Original Report
NetworkFix recommends reviewing the complete original report from The Hacker News for the authoritative technical context, affected versions, indicators and vendor-specific remediation details: Read the original report.
