CVE-2026-34348 Fixed; Windows Passkey Spoofing Unverified

Cyber Kendra reported on August 10 that Microsoft Security Response Center closed a proof of concept from SpecterOps researcher Michael Grafnetter as low-severity “Defense in Depth” on June 4. The report says the weakness lets a malicious local program invoke the native Windows WebAuthn interface and make the passkey consent window appear to belong to Microsoft Edge, Outlook, or another trusted application. If correct, it creates an uncomfortable gap: Windows users are being trained to trust a system prompt whose claimed requesting application may not be authenticated by the system.

The public record supports the broader Pass-the-Passkey research and the event-log flaw. It does not yet independently substantiate the detailed prompt-spoofing case. SpecterOps’ Black Hat USA 2026 program description confirms Grafnetter presented research covering passkey phishing, tampering, spoofing, fuzzing, and prompt flooding. His DSInternals announcement also says the work involves malware and compromised terminal hosts or virtual machines. But neither public page supplies the technical proof, Microsoft case outcome, severity assessment, or a downloadable white paper cited by Cyber Kendra.

That distinction is important for administrators deciding whether this is a patch-now incident, a design limitation to contain, or both. The patched issue has an identifier and a clear update path. The alleged prompt spoofing issue has neither.

CVE-2026-34348 is real, patched, and broader than Windows 11​

The verified Windows vulnerability is CVE-2026-34348, which Microsoft describes as a protection-mechanism failure in Windows Event Logging Service that allows an authorized attacker to disclose information over a network. NVD records it with a 6.5 CVSS score and lists affected Windows 10, Windows 11, and Windows Server releases — not Windows 11 alone.

Cyber Kendra, citing Grafnetter’s research, says the flaw involved full WebAuthn assertions appearing in the

log. An assertion is not the passkey’s private key. It is a signed authentication response that normally should be usable only once, in the right session, against the right challenge. That difference matters: the event-log bug did not turn Windows Hello or a FIDO2 key into a trivially exportable private key.

The risk became more consequential, according to Cyber Kendra and earlier reporting by Dark Reading, because Entra ID allegedly failed to enforce several server-side anti-replay checks for certain authentication flows. In that chain, an attacker with limited access to a system could collect a prior signed assertion and replay it under conditions where Entra accepted it. SpecterOps’ Black Hat description says the researchers used the chain to impersonate privileged users, bypass phishing-resistant MFA enforcement, and evade popular endpoint detection products in their tests.

Microsoft shipped the Windows fix in its July 14, 2026 security updates. For Windows 11 24H2 and 25H2, that is KB5101650, bringing systems to builds 26100.8875 and 26200.8875 respectively. Microsoft’s published update notes do not call out the WebAuthn logging change by name, which is routine for security fixes; the CVE record provides the authoritative confirmation that the vulnerability was addressed.

Administrators should not treat “July patched” as equivalent to “environment remediated.” The CVE affects older supported Windows client and server versions as well. Enterprises with Windows 11 23H2, Windows 10 22H2, Windows Server 2019, Windows Server 2022, or Windows Server 2025 should verify their specific July 2026 cumulative update deployment rather than assuming KB5101650 covers their fleet.

Microsoft’s own API documentation leaves the trust question unanswered​

The alleged unpatched issue centers on

, the native Win32 function applications can call to request a passkey assertion. Microsoft’s documentation says its

parameter is “the handle for the window that will be used to display the UI.” It does not say Windows verifies that the caller owns that window, that the window belongs to the foreground process, or that the name presented to the user comes from a code-signing identity.

Cyber Kendra says Grafnetter’s proof of concept supplies another program’s window handle and controls the publisher label through the calling executable’s version-resource metadata. In the reported demonstration, malware could present a passkey dialog as a modal child of Edge or Outlook and display a familiar-looking requester identity. The report further says the native API caller can provide its own relying-party origin instead of receiving browser-generated WebAuthn request data.

Those are material technical claims. Yet no Microsoft documentation presently states that the

parameter is deliberately untrusted, nor does it explain what security guarantee the requester label is meant to provide. The documentation describes a UI-placement parameter, not an anti-spoofing boundary.

Microsoft’s apparent silence therefore cuts in two directions. It does not disprove the research, and it does not confirm that Microsoft reviewed the exact proof of concept or intentionally accepted the behavior as a residual risk. The only assertion that MSRC closed the report as “Defense in Depth” comes from Cyber Kendra. No independent outlet has reported the case number, Microsoft’s rationale, an MSRC response, or the prompt-spoofing severity score.

That absence should temper the most categorical version of the story: WindowsForum could verify the patched event-log CVE, but not independently verify that Microsoft has formally declined to fix the prompt-spoofing technique.

September 1 is a migration trigger, not a universal Entra passkey mandate​

The timing remains significant. Microsoft’s Entra documentation says that, starting September 1, 2026, users enabled for SMS or voice authentication are automatically enabled for passkeys and nudged to register one after completing MFA. Microsoft frames the move as part of retiring its native SMS and voice delivery service on February 1, 2027.

But “passkeys become the default sign-in experience” needs a more precise reading than some coverage has given it. The September change initially targets users in scope for SMS or voice in the Entra Authentication Methods Policy or legacy MFA settings. It does not instantly convert every Entra tenant and every employee to passkeys on September 1.

Microsoft also offers a temporary opt-out for the automatic passkey enablement and registration campaign between September 1, 2026 and February 1, 2027. The opt-out does not extend the final SMS and voice retirement deadline. On February 1, 2027, users still dependent on Microsoft-provided SMS or voice will face a blocking passkey-registration requirement unless their organization has moved them to another phishing-resistant method or configured a customer-managed telecom provider.

For IT teams, the practical consequence is that passkey deployment is no longer a future architecture discussion. It is a near-term rollout, help-desk, endpoint-management, and privileged-access project. The alleged UI-spoofing weakness matters most in that context because broad registration campaigns will condition more users to expect and approve passkey prompts.

A prompt that appears unexpectedly should remain a cancel event, not an approval event — even if it appears attached to a familiar Microsoft application.

Treat native passkey prompts as a local attack surface​

Passkeys still improve materially on passwords, SMS codes, and push-notification approvals. A passkey’s private key stays on the authenticator, and normal WebAuthn flows bind authentication to a relying party and challenge. The research does not establish that passkey cryptography is broken.

It does reinforce a harder operational reality: phishing-resistant authentication does not make a compromised Windows endpoint trustworthy. If malware runs in a user’s session, it can watch the desktop, abuse accessible APIs, steal browser sessions, request credentials, or exploit weak server-side validation. The useful security boundary is the combination of authenticator, endpoint integrity, user interaction, and relying-party verification.

Organizations using Windows Hello for Business, FIDO2 keys, or Entra passkeys for administrators should take several actions now:

• Deploy the applicable July 2026 Windows security updates and confirm that devices are above the affected build thresholds for CVE-2026-34348.
• Restrict access to Microsoft-Windows-WebAuthN/Operational logs, particularly on shared administration systems, jump hosts, Remote Desktop Session Hosts, and virtual desktop infrastructure.
• Keep privileged Entra administration on hardened privileged access workstations rather than ordinary user workstations or multi-user jump boxes.
• Use application-control policies, attack surface reduction rules, and endpoint detection to reduce unapproved executable code in administrator sessions.
• Review Conditional Access policy assumptions. A requirement for phishing-resistant MFA is a strong control, but it does not replace endpoint controls, session protections, least privilege, or monitoring.
• Prefer device-bound, attested credentials for privileged roles where operationally feasible, and review who can add or manage authentication methods through Microsoft Graph or third-party identity platforms.

The immediate patch action is straightforward: verify July 2026 coverage for CVE-2026-34348. The unresolved action is behavioral and architectural: do not teach users that a Windows passkey dialog is proof that a named application requested it. Until Microsoft documents and, if warranted, changes that trust model, the safe rule is simpler — approve a passkey prompt only when the user initiated the sign-in and recognizes the service being accessed.