# Passkeys Have a UV Problem: How Malware Can Silently Borrow Your Identity on Chrome
The authentication ceremony is supposed to feel like a lock clicking open. You press your finger to a sensor, the device confirms you're you, and a cryptographic proof goes to the server. What Unit 42 published this week describes something different: an attacker skipping the ceremony entirely, borrowing Chrome's TPM-backed signing capability, and walking through the door while you're doing something else — no biometric prompt, no PIN dialog, nothing on your screen at all.
The flaw isn't in the elliptic curve math. It never is. It's in the bits that surround the crypto.
## What "User Verified" Is Actually Worth
WebAuthn — the protocol behind passkeys — has a field called the User Verified flag. One bit. Set it, and you're telling the relying party that a human being was authenticated to the authenticator before the private key was used. Leave it unset, and you're saying the opposite. The specification is clear: if a site requires user verification, it must reject ceremonies where that bit is absent.
Unit 42's first technique, which they call Pass-ta-key, extracts Chrome's wrapped device identity key from local storage and uses it to request a signing assertion through Windows' Cryptography API. Chrome exports this key as an opaque blob and reloads it under a flag that suppresses prompts — a design decision documented in the source code, with a TODO comment pointing to a Chromium issue that would label the key differently. The resulting assertion is cryptographically valid. The UV flag is unset. Whether that matters depends entirely on who's checking.
GitHub checked. eBay didn't — not until Unit 42 disclosed the finding.
That split is the real story here. You can design a passkey system with careful key management, hardware attestation, and sound cryptography, and your security posture still depends on every relying party enforcing a single bit correctly. Most of them aren't thinking about it.
## Three Paths Into the Same House
The research describes a progression of techniques, each reaching deeper into Chrome's passkey infrastructure.
Pass-ta-key is the opportunistic move: use the TPM-backed key that's already enrolled, generate a valid assertion, and hope the site doesn't check the UV bit. It works only against sites with lax verification enforcement — but based on eBay's initial behavior, that's not a small population.
Silver Pass-ta-key is more surgical. Chrome doesn't create its user-verification key immediately at enrollment time. That gap — between when a device re-enrolls and when the UV key is set — is a window an attacker can step into. Malware forces a re-enrollment, registers an attacker-controlled key in that window, and from then on can generate fully UV-set assertions. The researchers noted that Google's service doesn't verify whether a newly registered key came from secure hardware. The attacker's key is treated the same as one born inside a TPM.
Golden Pass-ta-key is the one that keeps security teams up at night. Chrome synchronizes passkeys across devices using a 32-byte value called the Security Domain Secret. That secret lives in memory. An attacker who extracts it can decrypt the entire synced passkey vault — and take that capability off the victim's machine entirely. This is no longer a post-compromise technique bounded to the compromised endpoint. It's the compromised endpoint as a stepping stone.
## The Post-Compromise Asterisk That Isn't Really an Asterisk
Every path here starts with malware already running on the target machine. That caveat gets repeated in coverage like a disclaimer, as if "post-compromise" should reassure us. It shouldn't.
The point of passkeys — the specific promise that made them attractive as a credential-theft defense — was that stealing credentials from a compromised machine would yield nothing useful. You might capture a password, but without the device's private key and the biometric check, the password is inert. The passkey ecosystem was supposed to break the loop where initial compromise automatically becomes account takeover becomes lateral movement.
What Unit 42 showed is that loop isn't broken. An attacker who lands on a Windows machine with Chrome and a TPM can now silently authenticate to the victim's passkey-protected accounts. The Silver and Golden paths go further: they can establish reusable footholds that persist after the victim's machine is remediated. That changes the incident response calculus significantly.
## What Hasn't Been Said Yet
There are no CVE identifiers for any of these techniques. Google hasn't confirmed which Chrome versions remain affected or outlined a remediation timeline in the public record. Unit 42 appears to have coordinated disclosure with Google and specific relying parties — eBay's fix is mentioned — but the broader ecosystem is flying blind.
The TODO comment in Chrome's source code pointing to Chromium issue 398125799 is particularly telling. Engineers knew the key labeling approach was provisional. The question of whether the latest stable Chrome release is still exploitable as described remains publicly unresolved as of this writing.
---
## HackWire Analysis
The UV flag enforcement gap isn't new as a concept. Researchers flagged the potential for relying parties to skip UV checks in early FIDO2 deployments, and it showed up again in enterprise SSO passkey rollouts where compatibility pressure pushed vendors toward userVerification: preferred over required. What's new is the demonstration of a practical, post-compromise exploitation chain that makes this ecosystem-level failure concrete rather than theoretical.
The deeper issue is that passkeys were marketed as a replacement for passwords with an implicit promise: the endpoint being compromised no longer automatically compromises your accounts. That promise was always conditional on proper implementation throughout the chain — device key management, re-enrollment protocols, UV flag enforcement, and relying party validation. Unit 42's research shows at least three places where that chain currently has slack.
For defenders, the immediate action isn't waiting on Google. Operators running services that accept passkeys should audit their userVerification settings right now and enforce UV flag checks at the ceremony validation layer — not just the parameter declaration. Enterprises should evaluate whether Chrome sync should be permitted on unmanaged endpoints at all, given that the SDS can be extracted by an unprivileged process. Organizations processing sensitive data should treat any Windows endpoint running Chrome with synced passkeys as a credential store that needs the same protection as a secrets manager.
The harder conversation is about the FIDO ecosystem's reliance on relying party compliance for its security properties. Cryptographic guarantees are clean. Ecosystem enforcement is not. Until UV checks are universally enforced — or the spec makes rejection mandatory regardless of the userVerification parameter — this is a systemic gap, not a Chrome bug.
— HackWire Editorial
---
## Related Coverage