# Passkeys Aren't Bulletproof: Malware Can Now Silently Hijack Google-Synced Credentials


## The Threat


The security industry spent years telling users that passkeys were the answer — phishing-resistant, credential-stuffing-proof, and fundamentally more secure than passwords. That message remains mostly true. But Palo Alto Networks researchers have now demonstrated something the passkey narrative never addressed: what happens when the device itself is compromised.


Their research, published August 5, 2026, details a family of attacks collectively named "Pass-ta-key" — techniques that allow malware already running on a Windows machine to authenticate as the victim to passkey-protected accounts without triggering any biometric prompt, requesting elevated privileges, or requiring the user to do anything at all. The attack exploits how Chrome syncs passkeys to Google's cloud infrastructure, turning the sync mechanism from a convenience feature into an attack surface.


The attack chain is surgical. Malware on an infected Windows host reads Chrome's local synchronization database to enumerate which accounts are passkey-protected and collect encrypted credential material. It then recovers a device identity key — stored either on disk or in Chrome's process memory — and uses Windows' native cryptographic APIs to forge a signed authentication challenge response. Google's cloud authenticator sees a valid signature from what looks like a trusted enrolled device and hands back a legitimate authentication assertion. The attacker forwards that assertion to the target site and walks in. No popup. No MFA prompt. No login notification that looks unusual to the victim.


## Severity and Impact


Palo Alto Networks published this as a research disclosure rather than a patched CVE. No formal CVE numbers had been assigned at publication time. The severity framework below reflects the researchers' characterization of each technique.


| Technique | Attack Complexity | Privileges Required | User Interaction | Impact | Status |

|---|---|---|---|---|---|

| Pass-ta-key (baseline) | Medium | None (user-level) | None | Full account takeover | Google mitigations deployed |

| Silver Pass-ta-key | Medium | None (user-level) | None | Persistent attacker device enrollment | Google mitigations deployed |

| Golden Pass-ta-key | High | None (user-level) | None | Full passkey key material exfiltration, future passkey compromise | Partially mitigated |


The baseline and Silver variants require only an established malware foothold — no administrator access, no UAC prompt, no credential theft. Golden Pass-ta-key is more technically demanding but delivers a dramatically worse outcome: it extracts a master secret from Chrome's process memory during a re-enrollment window, giving the attacker the ability to decrypt every synced passkey private key on the account, including ones created afterward.


## Affected Products


  • Google Chrome on Windows — any version using Google Password Manager passkey sync
  • Google's cloud authenticator service — the server-side component that validates device-bound passkey assertions
  • Any website accepting Google-synced passkeys for authentication

  • The attack does not affect device-bound passkeys stored in hardware security keys (e.g., FIDO2 hardware tokens) that do not sync to the cloud. Platform passkeys on iOS and macOS using Apple's iCloud Keychain sync follow a different architecture and were not demonstrated to be vulnerable in this research.


    ## Mitigations


    For end users:

  • Google has deployed server-side mitigations — keep Chrome updated to ensure you receive client-side hardening as it rolls out
  • Consider using hardware security keys (YubiKey, etc.) for high-value accounts rather than synced passkeys — hardware-bound keys don't have an extractable sync secret
  • Treat endpoint security as the real perimeter: if malware runs on your machine, your passkeys are not safe

  • For security teams and organizations:

  • Prioritize EDR coverage and behavioral detection on Windows endpoints — this attack requires an active malware presence; stopping the foothold stops the technique
  • Audit passkey adoption policies: if your organization uses Google-synced passkeys for internal resources, evaluate whether the sync feature is appropriate for high-sensitivity accounts
  • Monitor for unusual Chrome process memory access patterns and unexpected cryptographic API calls from non-Chrome processes
  • Review incident response playbooks — a compromised endpoint now means compromised passkey-protected accounts, not just password-based accounts

  • Developers and relying parties:

  • Do not treat a valid passkey assertion as proof of a clean device — layer additional signals (IP reputation, behavior baselines, anomaly detection) for high-risk operations like financial transactions or admin actions

  • ## References


  • Palo Alto Networks Unit 42 research blog (Pass-ta-key disclosure) — published August 5, 2026
  • Google passkey documentation: [passkeys.dev](https://passkeys.dev/)
  • FIDO Alliance passkey overview: [fidoalliance.org/passkeys](https://fidoalliance.org/passkeys/)
  • Related prior research: "Passkey Login Bypassed via WebAuthn Process Manipulation" (SecurityWeek)

  • ---


    ## HackWire Analysis


    The timing here matters. The industry is in the middle of a major passkey push — Google, Apple, Microsoft, and essentially every major platform have been evangelizing passkeys as the successor to passwords, and adoption has accelerated meaningfully over the past two years. The security argument was simple: passkeys are phishing-resistant and can't be credential-stuffed. Both claims remain true. What this research surfaces is a third threat vector that the marketing never mentioned: post-compromise credential abuse.


    This is a classic example of a security control that solves the problem it was designed for while creating a new problem adjacent to it. Passwords could be phished; passkeys can't. But passwords, even if stolen, often can't be used without knowing which accounts they're tied to, and defenders can rotate them. A Golden Pass-ta-key extraction gives an attacker a permanent key to every synced passkey on the account — including ones the user creates after the compromise. That's a materially worse outcome than traditional password theft for a sophisticated attacker.


    The Silver variant deserves specific attention from enterprise defenders. Registering an attacker-controlled device as a legitimate enrolled authenticator during a re-enrollment window is a persistent foothold — even if the victim's machine is wiped, the attacker retains authentication capability from a separate device. That's the kind of persistence that can survive an incident response.


    The practical upshot: endpoint security is the real passkey defense layer. Passkeys don't protect you from malware on the signing device; they protect you from attackers who don't have access to the device at all. Organizations should communicate this clearly as they roll out passkey policies, and should invest in behavioral controls that can detect the memory access and API call patterns this research describes.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)