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.
Reading an older article? Use the brief to stay current.
This Article Gives You the Background. The Brief Gives You What Changed Next.
Get the weekday cyber brief for new policy moves, CISA actions, and risk developments this article could not cover when it was published.
By subscribing you agree to our Privacy Policy.
Free. Weekday mornings. 5 minutes or less.
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.
Reading an older article? Use the brief to stay current.
This Article Gives You the Background. The Brief Gives You What Changed Next.
Get the weekday cyber brief for the developments, risk shifts, and new signals that changed the picture after this article was published.
By subscribing you agree to our Privacy Policy.
Free. Weekday mornings. 5 minutes or less.
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
Newer CyberExperts coverage on this topic
This article still works as background. If you want the current picture, start with the freshest related coverage below and today's brief.
Coder’s registry infrastructure compromised to push malicious modules
The Coder incident is a supply-chain lesson in miniature: once attackers can tamper with trusted module distribution, defenders are no longer verifying...
Attackers Turn Trusted Node.js Runtime Into Malware Delivery Tool in Targeted Attacks
The useful lesson in this campaign is not that Node.js is bad. It is that adversaries keep choosing legitimate runtimes defenders already...
HPE patches critical ArubaOS-CX remote code execution flaw
ArubaOS-CX deserves attention because switching software rarely gets treated with the same urgency as identity or edge security until exploitation arrives. A...
The 5-Minute Cyber Brief: September 18, 2026
The fastest way to catch up on what changed after this article was published.
Start your morning with the signal that matters.
Get the biggest cybersecurity developments, why they matter, and where to go deeper on CyberExperts.
By subscribing you agree to our Privacy Policy.
Free. Weekdays. Built for operators.
