Passkeys Under Siege: How Malware Turns Passwordless Promise Into New Attack Vector

Passkeys were supposed to end the password nightmare. No more weak credentials. No more phishing successes. Yet fresh research reveals a different story. Malware running on compromised Windows machines can silently hijack Google-synced passkeys. It does so without user prompts, without biometric checks, and without breaking the underlying cryptography.

The details come from a report published just yesterday by Palo Alto Networks’ Unit 42 team. Researchers demonstrated three distinct attacks they call Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key. Each exploits gaps in how Chrome, Google Password Manager, and cloud-based authenticators handle device trust signals, recovery flows, and key synchronization. Unit 42 published the findings on August 3, 2026.

Short version: endpoint compromise still matters. A lot.

Passkeys rely on public-key cryptography. The private key stays on the user’s device or in a synced, protected store. Services verify signatures instead of checking shared secrets. This design eliminates many classic credential-theft techniques. But it introduces new dependencies on the client device, the browser, the operating system, and the sync provider. Attackers who control any of those pieces gain powerful options.

And control the endpoint they do. Unit 42 showed how malware already present on a Windows PC can abuse legitimate workflows. The Pass-ta-key attack, for instance, mimics normal Google Cloud Authenticator behavior. It generates valid signatures without needing device unlock or user interaction. Services that fail to strictly check the userVerification flag accept these signatures. eBay was one such service until the researchers reported the issue. The company fixed its validation afterward.

But the attacks go further. Silver Pass-ta-key tricks the cloud authenticator into accepting a forged biometric verification state. The malware invalidates the existing user verification key, registers its own, and assumes full control. No live access to the victim’s unlocked device required. Golden Pass-ta-key extracts a critical master secret — the security domain secret, or SDS — from Chrome’s memory or logs during registration or recovery operations. With that secret, attackers decrypt all synced passkey private keys. Persistence achieved.

Google responded during the disclosure process. “The (cloud) enclave authenticator’s primary function is to make it difficult to steal passkey private data, which would be an obvious target for malware if it were locally available,” the company told the researchers. After the report, Google removed the SDS from Chrome’s logging output. Yet Unit 42 notes the secret still reaches the client process and remains accessible in memory during certain flows. “Although Google removed this secret from Chrome’s logging output following our report, the SDS is still sent to the client and remains accessible in Chrome’s process memory,” the team wrote. “If the attacker forces the victim to re-register with the cloud authenticator and knows the pattern to look for, they can extract the SDS directly from memory.”

These findings landed amid growing enterprise adoption of passkeys. Major platforms pushed the technology hard as a phishing-resistant alternative. Google itself promotes passkeys with language that highlights their advantages: “Unlike passwords, passkeys can’t be shared, copied, written down, or accidentally given to someone else. This makes them more secure against phishing.” That statement still holds in many scenarios. But the new attacks show the threat model must include sophisticated endpoint malware.

The Endpoint Remains the Battleground

Passkeys shift risk rather than eliminate it. Traditional password attacks often succeed through phishing or credential stuffing. Passkeys blunt those methods. Yet they heighten the importance of device security. Malware that achieves initial access can abuse onboarding, recovery, and synchronization mechanisms that rely on signals from the compromised machine.

Unit 42 demonstrated successful takeovers against messaging apps, GitHub (which properly enforced verification and blocked one variant), eBay before the fix, and even crypto exchanges. The attacks don’t require privilege escalation. They work by operating within expected browser and authenticator behaviors. Signature counters that should detect reuse sometimes remain constant across synced devices, reducing their effectiveness as a detection signal.

News of the research spread quickly on X. Multiple accounts shared the Unit 42 link and summaries within hours of publication. One post noted that the attacks “challenge the ‘phishing-resistant’ marketing around passkeys and highlight a critical gap in device-bound security assumptions.” Another highlighted that malware can extract passkeys without any password, PIN, or biometric prompt. The conversation reflects a familiar pattern: new technology arrives with bold claims, then real-world testing uncovers the gaps.

BleepingComputer covered the disclosure the same day. Lawrence Abrams reported that the attacks succeed against services not enforcing strict user verification. He quoted the researchers’ warning that while passkeys improve security over passwords, “malware risks persist.” The article also noted GitHub resisted one attack vector due to proper flag validation. BleepingComputer published its story on August 3, 2026.

Organizations evaluating or deploying passkeys face a clear set of choices. They can require hardware-backed keys where possible. They can demand userVerification set to “required” and validate the UV bit in every assertion. They can harden recovery and device enrollment processes. And they must maintain strong endpoint protection, memory access controls, and behavioral detection for browser processes.

Credential managers and browser vendors also carry responsibility. Unit 42 recommends they validate the origin and attestation of device-bound keys, avoid exposing key material to client-side code, and implement coordinated signature counters across synced environments. Some of these changes require coordination across the FIDO ecosystem. Others fall to individual relying parties.

The research does not suggest abandoning passkeys. On the contrary. It shows they raise the bar for attackers compared with passwords. But assumptions about device trust and user consent need scrutiny. Cloud isolation helps. Hardware security modules help more. Neither removes the need for layered defenses.

Passkeys represent one piece of a larger identity strategy. Enterprises that treat them as a complete solution risk surprise when determined adversaries combine initial access with these new techniques. The Unit 42 team puts it plainly: passkey deployments form one layer in a broader security strategy. Malware that reaches the endpoint can manipulate the very signals those deployments trust.

So what comes next? Vendors will patch the specific issues disclosed. Google already adjusted logging. eBay corrected its validation logic. Expect browser updates, updated guidance from the FIDO Alliance, and revised NIST recommendations over time. Yet the core insight will remain. Authentication technology evolves. Attackers evolve with it. The organizations that succeed will combine strong cryptographic primitives with vigilant endpoint hygiene and continuous validation of every signal in the authentication chain.

The passwordless future looks more complicated than the marketing once suggested. That’s not a reason to retreat. It’s a call to implement these systems with eyes wide open to their actual threat surface. The research from Unit 42 provides exactly that clarity at a critical moment in adoption.