What The Research Actually Says
This story is not claiming that passkeys are broken in the abstract. Unit 42 described three attack paths against Chrome's Google Password Manager on Windows that all begin after malware is already running on the victim's machine. The target is the implementation around the passkey flow, not the underlying cryptography itself.
According to the research summarized by The Hacker News, the attacks focus on how Chrome stores and reloads device keys, how a device can be re-enrolled into Google's cloud authenticator flow, and whether the relying party enforces user verification correctly. In other words, the problem is not that an attacker can remotely guess a passkey. It is that local malware on an already-compromised Windows endpoint may be able to abuse trusted browser state to sign in as the victim.
The Three Attack Paths, In Plain English
The first path, Pass-ta-key, reportedly lets malware reuse Chrome's wrapped device identity key through the local TPM and obtain a valid authentication assertion without showing the victim a fingerprint or PIN prompt. The key technical catch is that the returned assertion should have the User Verified (UV) bit unset, which means a site that correctly requires user verification should reject it.
Stay Current on Cyber Policy and Guidance
Track new CISA actions, regulations, guidance, and risk trends in a quick daily format.
Free. Weekday mornings. Unsubscribe anytime.
The second path, Silver Pass-ta-key, goes after device re-enrollment. The researchers said malware can force Chrome to re-register the device and slip in an attacker-controlled user-verification key during a deferred key-creation window. If the service accepts that substitute key, later logins can carry the UV signal even though the attacker controls the path.
The third path, Golden Pass-ta-key, is the most serious because it targets the 32-byte Security Domain Secret used to decrypt synced private keys. Unit 42 said malware can trigger re-enrollment, grab that secret from Chrome process memory while it is briefly present in plaintext, and then use it to recover synchronized passkey private keys for reuse outside the original victim device.
What This Does And Does Not Mean
There are two important limits here. First, this is Windows-and-Chrome-specific research centered on Google Password Manager's cloud authenticator model, not a universal break of every passkey implementation. Second, these are post-compromise techniques. The attacker already needs code execution on the victim endpoint before any of these paths matter.
That limit should not be used to wave the issue away. Passkeys are often sold as a way to dramatically reduce account-takeover risk, and they do help against phishing and credential theft. But if local malware can still turn an endpoint compromise into silent or reusable account access, security teams need to treat endpoint integrity and relying-party verification logic as part of the passkey threat model, not as a separate conversation.
Why The First Path Matters To Defenders Right Now
One of the clearest operational lessons is that relying parties cannot assume that requesting user verification is enough. They need to validate that the returned assertion actually contains the UV signal. The Hacker News reported that GitHub enforced that check, while eBay reportedly accepted a test assertion until the gap was disclosed and fixed.
That makes this more than a browser story. Any organization that offers passkey login should ask whether its own WebAuthn implementation requires user verification and whether it explicitly checks the returned UV bit instead of trusting the browser request alone.
What Security Teams Should Check Next
If your organization uses passkeys internally or offers them to customers, there are two tracks to look at immediately: endpoint exposure and application-side validation. Endpoint controls still matter because every path in this research begins with malware already on the device. At the same time, application owners should verify that their own passkey implementation fails authentication when user verification is absent.
For organizations standardizing on Google Password Manager in Chrome, this is also a reminder to watch for vendor guidance on hardware attestation during re-enrollment, stronger recovery checks, and any future control that can rotate or invalidate a previously exposed Security Domain Secret.
- Review WebAuthn settings on customer-facing and internal applications to confirm
userVerificationis required where appropriate and that the returned UV bit is actually enforced. - Treat Chrome-on-Windows endpoints that store synchronized passkeys as sensitive identity assets, not just ordinary browsing environments.
- Harden malware prevention and endpoint detection around browser process access, suspicious local credential-store reconnaissance, and unusual re-enrollment behavior.
- Ask whether your incident-response playbook includes a passkey-specific recovery path if a device is compromised, especially if synced credentials may have been exposed.
- Track Google and Chromium guidance closely for any remediation, attestation, memory-handling, or secret-rotation changes related to these attack paths.
What Remains Unclear
The public reporting does not establish that all three paths remain exploitable in the latest Chrome stable release, and it does not identify CVEs for the named techniques. It also leaves an uncomfortable recovery question unresolved: whether changing a Google Password Manager PIN or deleting Password Manager data fully invalidates a Security Domain Secret that malware may already have stolen.
That unresolved piece is part of why the article needs to stand on its own. Readers do not just need a headline that says malware can bypass passkeys. They need to understand the scope, the preconditions, and the still-open questions that determine how worried they should actually be.
Source Context
CyberExperts used The Hacker News summary of Unit 42's research as the primary source for this article and preserved the key implementation details that matter operationally: the three named attack paths, the Windows-and-Chrome scope, the post-compromise requirement, the UV-bit validation issue, and the exposure of the Security Domain Secret.
Related In The Daily Brief
See this item in The 5-Minute Cyber Brief
