What happened
Microsoft published CVE-2026-34348 on July 14, 2026, for a Windows Event Logging Service information-disclosure flaw reachable by an authorised attacker over a network. NVD records a Microsoft CVSS score of 6.5 and states that CISA’s assessment showed no active exploitation at publication.
Black Hat scheduled Pass-the-Passkey for August 5, 2026, from 3:35 to 4:15 PM Pacific. SpecterOps characterises the research as attacks analogous to Pass-the-Hash and NTLM relay against real-world passkey implementations.
SpecterOps says past YubiKey signatures were stored in cleartext and readable by authenticated unprivileged users, including remote users. The researchers report impersonation of privileged users while bypassing phishing-resistant MFA enforcement and remaining undetected by popular XDR products.
NVD lists affected builds below 10.0.17763.9020 for Windows 10 1809 and Windows Server 2019; below 10.0.19044.7548 for Windows 10 21H2; below 10.0.19045.7548 for Windows 10 22H2; below 10.0.22631.7376 for Windows 11 23H2; below 10.0.26100.8875 for Windows 11 24H2; below 10.0.26200.8875 for Windows 11 25H2; below 10.0.20348.5386 for Windows Server 2022; and below 10.0.26100.33158 for Windows Server 2025. NVD’s change history shows conflicting Windows 11 26H1 thresholds of 10.0.28000.2269 and 10.0.28000.2525, so this edition does not resolve that branch and directs teams to the current MSRC matrix process for correct fixed build selection by platform owners using authoritative vendor guidance before closure. NVD’s change history shows conflicting Windows 11 26H1 thresholds of 10.0.28000.2269 and 10.0.28000.2525, so this edition does not resolve that branch and directs teams to the current MSRC matrix.
Why this matters now
Passkeys remain materially stronger than reusable passwords against conventional phishing, but the research shows that phishing resistance is not equivalent to resistance against endpoint compromise, replay, implementation errors or theft of authenticated state.
The WebAuthn validation process described by the researchers has 22 steps. That complexity places responsibility on identity providers and application implementers to validate challenges, origins, transactional state and assertions correctly rather than assuming the cryptographic primitive makes every surrounding implementation safe.
The enterprise risk is concentrated where privileged users authenticate from shared terminal servers, virtual machines or compromised endpoints. Those environments can expose authentication artefacts or permit manipulation even when the private passkey itself is not exported.
The decision for security leaders
Continue passkey adoption, but remove any programme assumption that phishing-resistant MFA closes post-compromise identity paths. Endpoint trust, session controls, authenticator lifecycle monitoring and implementation-specific verification remain part of the control design.
Apply the Microsoft fix and verify exact build compliance before declaring the Windows component closed. Treat the conflicting Windows 11 26H1 thresholds in NVD as a reason to use the live MSRC matrix, not to select either number locally.
Prioritise testing around privileged identities and shared access systems. Security teams should attempt controlled replay, inspect who can read relevant logs and confirm that identity alerts recognise abnormal assertion reuse rather than only failed password or MFA activity.
Evidence of closure
- Build compliance reports match the applicable MSRC fixed version for every in-scope endpoint.
- An access-control test prevents low-privilege retrieval of protected passkey-related log material.
- A controlled replay test fails and produces an actionable identity alert.
- A privileged passkey inventory has an approved owner and expected authenticator for each registration.
The Security.io assessment
The research changes the interpretation of a medium-severity information-disclosure CVE because the disclosed material may participate in a higher-consequence identity chain. That is why CVSS alone is not an adequate prioritisation mechanism for identity infrastructure.
The cited originals did not publish the name or repository of the promised open-source passkey tooling. Defenders therefore have enough evidence to patch and reassess architecture, but not yet enough to reproduce every technique or deploy tool-specific detections.
Attribution posture: The cited sources describe research and a patched vulnerability; they establish no in-the-wild exploitation or threat-actor attribution. Security.io does not treat the demonstration as evidence that passkeys are broadly broken or cloneable.
Questions for the morning meeting
- Are privileged passkeys used from shared terminal hosts or broadly accessible virtual machines?
- Can identity telemetry distinguish legitimate assertion use from replayed authentication material?
- Which application teams implement WebAuthn verification outside the primary identity provider?
- Does the passkey rollout measure endpoint and session compromise risk as well as phishing reduction?