Passkey Bypass: Three Attacks Demolish Phishing-Resistant…

Three independent studies published in August 2026 demonstrate post-compromise attack chains that bypass passkey-based phishing-resistant authentication on Windows. The flaw isn't the cryptography—it's the surrounding infrastructure.

Three independent studies published in August 2026 have demonstrated post-compromise attack chains that bypass phishing-resistant authentication based on passkeys. SpecterOps, Palo Alto Networks Unit 42, and researcher Dirk-jan Mollema each identified a distinct vector: replay of WebAuthn assertions exposed by Windows logging, extraction of the Google Password Manager sync master key, and abuse of Windows Hello for Business without a PIN or biometric prompt. All three attacks require malware already present on the endpoint and do not require privilege escalation.

The common thread is architectural: none breaks FIDO2/WebAuthn cryptography, but all exploit the assumption that the endpoint device is trusted. When that assumption fails, the chain of trust between user, device, and cloud collapses.

Key Takeaways

CVE-2026-34348, CVSS 6.5, exposes signed WebAuthn assertions in cleartext in the Windows Event Logging Service; Microsoft has released patches and mitigations
Unit 42 isolated the "Golden Pass-ta-key," a 32-byte master key protecting Google-synced passkeys, temporarily present in plaintext in Chrome process memory
Dirk-jan Mollema demonstrated that an Entra ID WebAuthn challenge is valid for 5 minutes and not bound to session, user, or tenant, enabling relay and acquisition of a Primary Refresh Token
All three attacks operate from low-privilege processes on already-compromised sessions: the distinction between "device-bound" and "synced" passkeys does not protect against infected endpoints

Windows Logging Talks Too Much: CVE-2026-34348

SpecterOps demonstrated a Windows-to-Entra ID chain that allows impersonation of privileged users, bypassing phishing-resistant MFA. The entry point is the Windows Event Logging Service, which stores previous YubiKey signatures in cleartext. Authenticated users with standard privileges, including remote users, can read these assertions.

The vulnerability is tracked as CVE-2026-34348. According to the NVD record, the CVSS 3.1 score is 6.5 (MEDIUM) with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N and classification CWE-693 Protection Mechanism Failure. Microsoft has released security updates for the Windows 10, Windows 11, and Server editions covered by the CVE.

SpecterOps assesses the full chain as "broken" after the mitigations Microsoft applied in the July 2026 updates. However, the research does not establish whether the chain works identically across all Windows releases listed in the CVE. A Microsoft spokesperson, quoted by The Hacker News, stated: "We appreciate the work of SpecterOps for reporting this through a coordinated vulnerability disclosure. We have applied mitigations for the reported issue involving passkey relay assertions and continue investing in security enhancements across authentication methods."

The Golden Key in the Browser: When Sync Becomes Risk

Unit 42 identified three attack variants against Google Password Manager in Chrome on Windows: Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key. The third is the most severe. Golden Pass-ta-key targets the Security Domain Secret (SDS), a 32-byte master key that protects passkeys synced across devices.

According to Unit 42, the SDS is temporarily present in plaintext in Chrome process memory during re-registration. With this key, an attacker can recover the victim's synced private keys. The problem is structural: Unit 42 explicitly states that Google's implementation provides no way to rotate or revoke the SDS.

Google has removed the SDS from Chrome logs, but the key remains exposed in process memory. It is unclear whether all three Unit 42 paths have been fully closed. Unit 42 developed and validated the proofs of concept on Chrome 142.

The research prompted eBay to fix validation of the UV (User Verification) flag after disclosure; GitHub already enforced the check. The number of vulnerable relying parties beyond eBay was not provided.

"No CVE was assigned. Google rarely assigns CVEs to issues that require the device to already be compromised by malware." — Arie Olshtein, senior staff security researcher at Palo Alto Networks

Windows Hello for Business: Ticketing That Bypasses the User

Dirk-jan Mollema demonstrated that a low-privilege process in an already-compromised Windows session can use the Windows Hello for Business key via Windows cryptographic interfaces without producing a new PIN or biometric prompt. The technique is a consequence of how Windows Hello for Business works, not a vulnerability with an assigned CVE.

Mollema also found that the Entra ID WebAuthn challenge is valid for 5 minutes and is not bound to session, user, or tenant. This allows challenge relay. The resulting token may lack the device ID claim, opening the path to registering a new device and obtaining a Primary Refresh Token with a documented lifetime of 90 days.

It is unknown whether Microsoft has acknowledged or will acknowledge this technique as a vulnerability warranting a CVE. SpecterOps has not heard of its own research being used outside of test environments.

What to Do Now

Organizations that have adopted passkeys as phishing-resistant authentication must reassess endpoint controls. Compromise of a Windows machine with standard-user malware can now lead to complete MFA bypass, persistent recovery of synced credentials, or cloud impersonation.

Patch CVE-2026-34348 through Microsoft security updates and verify application of mitigations for passkey relay assertions
Relying parties must rigorously validate the UV flag in WebAuthn assertions, as already enforced by GitHub and fixed by eBay after disclosure
Monitor for anomalous device registrations in Entra ID, particularly tokens missing the device ID claim or showing timing patterns compatible with 5-minute challenge relay
Prefer hardware-backed passkeys for privileged accounts, reducing reliance on cloud sync mechanisms that centralize trust in a single point

The Architectural Loop the Industry Hasn't Closed

The industry is replicating with passkeys the same mistakes that made password managers an attractive target: centralization of trust in a single point. Browser, operating system, and cloud become conjoined links in a chain that, if one is compromised, collapses entirely.

The distinction between "device-bound" and "synced" passkeys is no longer sufficient to guarantee security if the surrounding infrastructure is fragile: OS logging, browser memory management, cloud challenge validation. Phishing-resistant authentication promised to shift risk from the user to the device, but the device remains attackable with standard techniques.

Ars Technica, cited in aggregation, summarized: "The attacks demonstrated in the post are neither novel nor unique to passkeys." The point isn't novelty, but scale: passkeys are becoming the default, and infrastructure flaws multiply with adoption.

Frequently Asked Questions

Has FIDO2/WebAuthn cryptography been broken?

No. No source claims the cryptography is broken. The attacks target the supporting infrastructure: OS logging, browser process memory, cloud challenge validation.

Why didn't Google assign a CVE for Pass-ta-key?

According to Arie Olshtein of Palo Alto Networks, Google rarely assigns CVEs to issues that require pre-existing device compromise by malware. This does not diminish the impact for already-infected enterprise endpoints.

Are Mollema's techniques patchable?

The dossier does not specify corrective measures from Microsoft for the Windows Hello for Business technique. Microsoft has applied mitigations specific to the SpecterOps/CVE-2026-34348 chain, but it is unclear whether it will recognize Mollema's research as a vulnerability.

Information has been verified against cited sources and is current as of publication.

Sources

Sources and references