Passkeys promise strong security: instead of passwords, users must prove they are really who they claim to be. Yet new research shows that malware already running on a Windows system can take a completely different route—namely through Google Password Manager in Chrome. The core idea is that the attack doesn’t “break” cryptography itself, but instead targets the software layer around it—specifically how authentication information is stored, re-enrolled, and validated.
It’s important to know what the researchers describe: techniques for scenarios where the device is already compromised. No CVEs are mentioned, and the publication doesn’t specify which exact Chrome versions would be affected. That said, the lessons are relevant for anyone using passkeys—or for any site where verification plays a role.
What researchers discovered
The Unit 42 study describes three attack paths against Chrome’s cloud authenticator, dubbed Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key. The attacks are built around the master key that protects user passkeys that are synchronized.
According to the report, the mathematical security remains intact; the attacks focus on the context around passkeys: how Chrome processes device data, how re-enrollment works when a certain state disappears, and whether the site (the relying party) truly checks that the user has been verified.
Three attack paths in plain language
All three routes start with local reconnaissance on the device. On Windows, among other things, Chrome looks at synchronized credential records stored in a directory such as %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB. From this, malware can infer metadata about which relying parties and usernames are linked to the passkeys, as well as credential IDs and encrypted private-key material.
1) Pass-ta-key: signing without real user verification
The first path revolves around using a device identity key that Chrome “wraps” and then uses via the Trusted Platform Module (TPM) to sign a request. In doing so, the malware tries to obtain a signature that, in practice, looks like what a genuine user check would produce—except that exactly one important bit is missing: the User Verified (UV) flag.
In the attack, the researchers say the difference is ultimately small: a ceremony outcome that marks the system as “user verified” disappears. They point out that some relying parties (sites) were less strict in test or implementation variants. That can create a validation gap that only becomes noticeable after disclosure.
The researchers also say this route depends most on a check the relying party is supposed to perform itself. In other words: even if the cloud authenticator returns a valid assertion, the site should fail when UV is missing.
2) Silver Pass-ta-key: Chrome allows re-enrollment with an “attacker-owned” key
The second path targets the next layer. Malware forces Chrome to re-enroll a device. In such a window—when Chrome has not yet built the user verification key right away—an attacker may try to register a key they control.
The report indicates that later use can include claims/assertions with the UV flag. The researchers note that the service behavior didn’t check whether the newly registered key originated from secure hardware. Because the certificate or attestation aspect is missing or insufficiently checked, an attacker can later attempt logins without the victim PC (at that moment) necessarily performing real user verification.
Again: the report does not state with certainty whether and how this has already been fully fixed for all current Chrome scenarios. It does mention that hardening via hardware attestation is considered a mitigation for this scenario.
3) Golden Pass-ta-key: extracting the Security Domain Secret (SDS) from memory
The third attack path goes even deeper into internal secrets. The researchers claim that malware can trigger Chrome to re-enroll, then read out the Security Domain Secret (SDS) while Chrome has it briefly in plaintext in memory, and use that secret to recover synchronized passkey private keys.
Chrome, the researchers say, generates or receives an SDS of 32 bytes and places it into the data structures of the client process. The report says earlier logging-related issues were addressed, and that some relying parties (such as eBay) would now handle UV validation better. Still, according to Unit 42, the main point remains: the secret reaches the client and can live in memory. A logging change doesn’t necessarily eliminate that type of risk.
The research also doesn’t fully clarify whether all paths are already closed, and it doesn’t describe a “user check” that would let organizations independently verify whether the SDS was exposed.
Why this doesn’t mean passkeys are “broken”
It’s tempting to read this as: “then the entire passkey concept doesn’t work.” That’s not what’s described here. The researchers emphasize that cryptography isn’t broken. The attacks are post-compromise: the malware must already be running on the computer.
This distinction is crucial. It shows that passkeys are particularly strong against normal phishing and password theft, but a fully compromised endpoint can still be abused to influence authentication logic. In such a scenario, the question shifts from “can I steal the key?” to “can I make the system believe the verification step succeeded?”
What relying parties and users can do
The report ends with recommendations aimed mainly at who the relying party is (websites and credential providers) and at how you design your recovery and re-registration process.
- Relying parties: set userVerification to required and validate the UV bit when the assertion returns, instead of trusting only what the request says.
- Credential providers: verify/attest newly enrolled keys from secure hardware and improve checks around re-enrollment and recovery.
- Limit local passkey state: access restrictions on local passkey data can help if a process is already trying to gain access.
- Keep master keys out of logs and memory: avoid sensitive material ending up in client logs; reduce the chance that secrets remain available in process memory for long.
For users, the practical follow-up question is: “If I secure my account, does an already stolen secret become invalid?” The research doesn’t provide a definitive answer. However, Google Password Manager’s public support documentation says, for example, that you can change your PIN or delete all Password Manager data, but it doesn’t describe SDS-specific rotation or revocation controls.
Connection to earlier research: endpoint-first is a trend
This finding fits a broader pattern we see more often in security news: attacks don’t just target the “outside world”; they also target the logic and workflow around authentication once an attacker has access to a device. See, for example, how researchers look at exploit timelines and prioritization—what you cover first in a chain often determines what impact you can still prevent: AI exploit timelines: focus on prioritization.
There have also been signals in earlier incidents that credentials or access are sometimes used via unexpected components or detours. Think of research showing how malicious actors can “bypass” existing security layers by exploiting implementation differences. That makes it even more important not only to have technical protection, but also to pay attention to implementation quality on the side of sites and authenticators.
What does this mean for you right now?
If you use passkeys through Chrome and Google Password Manager, this research mainly means you should tighten your threat model. The biggest benefit is preventing malware on the endpoint: once an attacker is already running as a “normal user” on your Windows system, authentication logic can be abused.
It’s also wise to keep an eye on updates and recommended hardening for your browser and operating system. The report doesn’t list a complete set of remediations and doesn’t mention the exact affected Chrome versions. That makes “waiting for confirmation” dangerous: once security updates are released, updating is often the most important step.
In summary
Unit 42 describes three attack paths in which malware on a Windows system may attempt to use passkey-protected accounts via Google Password Manager in Chrome. The attacks don’t break cryptography; instead, they aim to bypass user verification, push re-enrollment with attacker-controlled keys, or (in one route) extract a secret from Chrome memory.
For relying parties, the message is clear: validate the UV bit and build more robust re-enrollment and recovery checks. For users, the main takeaway is: prevent endpoint compromise, stay up to date, and treat a potentially compromised device as an incident that requires more than just “changing passwords”.
Source: https://thehackernews.com/2026/08/google-password-manager-attacks-could.html
