Pass-ta-key breaks Chrome's device trust, not WebAuthn: harden the endpoint, keep the rollout

Palo Alto Networks' Unit 42 published three techniques on 3 August 2026 that let malware take over accounts protected by Google-synced passkeys with no fingerprint, no PIN and no prompt on screen ^[1]. Every one of them starts from the same precondition, which Unit 42 states plainly: malware already running on the victim's device during the initial stage ^[7]. That single condition is the difference between a protocol failure and an endpoint failure, and it decides what you should actually change.

The three variants pull on different links in the same chain. The base technique extracts Chrome's device identity key and uses it to sign a request, with no admin rights, no device unlock and no user action ^[3]. Silver Pass-ta-key forces Chrome to re-register the device, then registers the attacker's own user-verification key with Google's cloud authenticator; afterwards the attacker signs in from their own machine and the cloud authenticator believes a fingerprint check happened ^[4]. Golden Pass-ta-key reads the Security Domain Secret, a 32-byte master key protecting every synced passkey, out of Chrome's process memory during onboarding, at which point all of them decrypt. BleepingComputer described that variant as the one that turns a single infection into a saleable bundle ^[5].

The thing being attacked is the Google Cloud Authenticator behind Google Password Manager and the trust it places in a device that malware is now imitating, according to The Hacker News ^[6]. It is not WebAuthn and not FIDO2, and none of it runs from a phishing page or a bad link alone ^[10]. On the same infected PC, an infostealer takes saved passwords and session cookies immediately, and phishing takes passwords with no malware at all ^[11]. Passkeys removed phishing as a path, and this research does not put it back ^[11].

Scope matters as much as mechanism. Unit 42 limited the work to Chrome on Windows with a TPM and said so ^[8]. The techniques exploit how one sync system bootstraps device trust, so they do not transfer mechanically to another vendor's design, but nobody has published the equivalent audit of Apple's or 1Password's implementations ^[9]. Untested is not secure.

There is one real regression. Chrome stores synced passkey metadata locally in readable form, which hands malware a directory of every service where the user has a passkey ^[12]. That is free reconnaissance an attacker did not previously get.

Google's post-disclosure response removed the Security Domain Secret from Chrome's logging output, closing the easiest route to it ^[13]. The secret still transits process memory during device onboarding and account recovery, which is exactly where Golden Pass-ta-key reads it ^[14]. The loudest variant is harder, not gone, and a fix that ends the class means redesigning how synced passkeys bootstrap trust rather than shipping a version bump ^[16].

All three published variants operate against Chrome's process memory or local profile state on a machine the attacker already controls ^[17]. So the work is endpoint execution control, memory-read protection around the browser process, and treating the browser profile directory as sensitive material. The credential rollout is not the problem to pause.

Watch for two things. Several outlets, including 9to5Google, reported a fourth variant that the research does not describe, so check counts against Unit 42's own paper before briefing anyone ^[2]. And watch for published audits of Apple's and 1Password's sync designs ^[9]. In the meantime, Unit 42's own recommendation is a device-bound hardware key for email, password manager and bank, which never syncs, never enters Chrome's enclave state and cannot be read from process memory; register two so a loss is not a lockout ^[15].