CVE-2026-124194: Outlook NTLM Zero-Day Explained

CISA gave federal agencies fourteen days to fix CVE-2026-124194, while Microsoft rates it Moderate. Both statements are accurate, and the gap between them is where defenders keep getting burned.

Microsoft’s November 2026 Patch Tuesday, released on November 10, was enormous even by recent standards. Tenable counted 1,093 Microsoft CVEs in the release, and BleepingComputer’s tally reached 1,235 once the 142 Chromium-based Edge fixes were included. Of all that, exactly one vulnerability carried the flag that matters most: exploitation detected.

That flaw, CVE-2026-124194, lives in classic Outlook for Windows. When a user opens a specially crafted message file, Outlook contacts an attacker-controlled server without showing the external-content warning that is supposed to gate that connection, and Windows hands the server the user’s NTLMv2 authentication response along the way. CISA added the bug to its Known Exploited Vulnerabilities (KEV) catalog the same day, one of six additions in that batch, with a remediation deadline of November 24 for federal civilian agencies.

The CVSS base score is 6.5. A patch queue that sorts by severity alone will file this bug below a hundred Important ones that nobody is exploiting, and that ordering is a mistake. The technical reasons are worth walking through carefully.

What Microsoft’s advisory says about CVE-2026-124194

Microsoft classifies the bug as spoofing with a maximum severity of Moderate and assigns it CWE-356, “Product UI does not Warn User of Unsafe Actions.” The weakness class is unusually literal here. There is no memory corruption and no injection, only a missing consent step. Outlook normally asks before it pulls content from a remote location, and in this code path the question never gets asked.

The published CVSS v3.1 vector is AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, which gives a base score of 6.5. Temporal metrics of E:H/RL:O/RC:C bring the adjusted figure to 6.2. Read slowly, the vector tells the whole story: reachable over the network, low attack complexity, no privileges required, user interaction required, scope unchanged, total loss of confidentiality, and no integrity or availability impact. E:H means exploit maturity is high, which matches Microsoft’s “exploitation detected” status. RL:O records that an official fix exists, and RC:C marks the report as confirmed.

Is CVE-2026-124194 a zero-click bug?

No. The advisory FAQ says an unauthenticated attacker must send the victim a specially crafted message file and convince them to open it in an affected version of Outlook. Exploitation needs network connectivity and that user action. The FAQ also says the Preview Pane is not an attack vector.

The KEV catalog titles the entry “Missing User Interaction for Potentially Unsafe Action Vulnerability,” which at a glance sounds like a zero-click flaw. The missing interaction is the absent warning dialog. The victim still has to open the crafted file itself, for example a .msg attachment saved to disk or a downloaded template. Glancing at it in the reading pane does nothing.

What Microsoft has not disclosed

Microsoft has not attributed the exploitation to any actor. It has not described the victims or the scale of the campaign, how the malicious files were delivered, or which part of the message file carries the remote reference. Neither the advisory nor the KEV entry includes indicators of compromise. Those gaps should stay empty in your reporting until someone fills them with evidence. Borrowing details from older Outlook attacks is tempting, and I would resist it.

One new detail did make it into the release. Microsoft credits the discovery to a researcher going by “nono” and to Benoit Sevens, and the credit line says Sevens used Claude, Anthropic’s AI model, in the research. BleepingComputer places that against a wider trend: Microsoft itself has been using AI to find and patch vulnerabilities while monthly CVE counts hit successive records, including 1,411 fixes in October. Discovery is speeding up on both sides of the vendor relationship, and the remediation side of the industry is the one now under time pressure.

How the Outlook NTLM leak works

Outlook message files (.msg, and its template sibling .oft) are OLE compound-file containers that can reference content outside the file. When Outlook opens a message that points at a remote resource, something has to decide whether the outbound fetch is allowed silently, allowed with a prompt, or blocked. CVE-2026-124194 is a failure at that decision point, and the connection goes ahead without the usual external-content warning. Everything after that is Windows working as designed, which is the real problem.

A connection to a remote path of the form \server\share normally travels over SMB on TCP port 445. If SMB fails or is blocked and the WebClient service is running, the same UNC-style reference can fall back to WebDAV over HTTP or HTTPS. Both protocols let the server issue an authentication challenge, and the Windows client answers automatically with the signed-in user’s credentials in NTLM form, because single sign-on to file resources is a feature. The attacker does not need to phish a password or drop an executable. They need the victim’s machine to connect to a host they control, and enough SMB or WebDAV on that host to issue an NTLM challenge. Responder-style capture servers and Impacket’s ntlmrelayx have covered this pattern for years.

What an NTLMv2 response contains

The cryptography decides what an attacker can do with the capture, so it is worth spelling out. NTLMv2 is a challenge-response protocol. The client’s long-term secret, NTOWFv2, is computed as HMAC-MD5 keyed by the NT hash (the MD4 of the UTF-16LE password) over the uppercased username concatenated with the domain. During authentication the server sends an 8-byte random challenge. The client builds a blob holding a timestamp, its own client challenge, and the server’s target information, then computes NTProofStr as HMAC-MD5 of the server challenge plus that blob, keyed by NTOWFv2. The response is NTProofStr plus the blob.

An attacker who captures this exchange holds the username, the domain, the server challenge they issued themselves, and the response. That tuple is the “NetNTLMv2 hash” circulating after this bug, catalogued as hashcat mode 5600. It is neither the password nor the NT hash you would get from credential dumping, so it cannot be used for pass-the-hash. It supports two follow-on techniques, and both are serious.

Because the credential emission is standard Windows behavior rather than part of the vulnerability, network-layer controls break the attack chain even on machines where the Outlook patch has not landed. The bug removes the prompt, and blocking the connection or the authentication removes the payoff. That is why every credible mitigation list for this CVE starts with egress filtering and NTLM restrictions instead of waiting for patch compliance to reach 100 percent.

What attackers do with a captured NTLMv2 response

Offline password cracking

Because the attacker chose the server challenge, they can test candidate passwords against the captured response at full speed. There is no lockout, no logging on the victim’s side, and no further network contact. Modern GPU rigs handle weak and medium-strength passwords quickly, while long random ones stay impractical to recover. A recovered password is worth much more than the hash, because it works anywhere the account authenticates interactively. If the on-premises account syncs to Entra ID through password hash sync, the same password opens Microsoft 365, subject to whatever MFA and Conditional Access the tenant enforces.

NTLM relay and the AD CS ESC8 path

Relay is the option that makes a 6.5 look absurd. Instead of cracking anything, the attacker forwards the authentication in real time to another server and logs in as the victim. NTLMv2’s cryptography does not stop this. Protections on the receiving service do. Relay works against SMB servers that do not require signing, LDAP on domain controllers without signing and channel binding, AD Certificate Services web enrollment endpoints without Extended Protection for Authentication (EPA), and Exchange servers without EPA enabled. It also sidesteps MFA, since NTLM to an on-premises service never consults Entra ID’s interactive sign-in policies. Password length defeats cracking and does nothing against relay.

The AD CS path turns a transient leak into lasting compromise. Relaying a victim’s authentication to an HTTP certificate enrollment endpoint (the technique tracked as ESC8) can yield a certificate issued in the victim’s name, and that certificate keeps working after the user resets their password. One opened file and one silent connection can leave an attacker with a credential that lasts months or years unless someone hunts for it and revokes it. The worst realistic case is a domain administrator or helpdesk operator who reads email on the same machine they administer from. Their leaked response can be relayed toward directory services or certificate infrastructure with privileges that end the engagement in the attacker’s favor.

Microsoft’s C:H/I:N/A:N impact assessment is therefore honest but incomplete, and the gap is structural. CVSS scores a vulnerability in isolation. This bug discloses authentication data and does not modify anything or execute code by itself. The score says nothing about the decade-old ecosystem of relay targets and cracking rigs waiting downstream. The KEV listing covers the other half of reality, which is that someone is already exploiting it. When the two signals disagree, act on the observed adversary behavior.

CVE-2026-124194 compared with earlier Outlook NTLM bugs

CVE-2023-23397, patched March 14, 2023, abused the reminder sound path property (PidLidReminderFileParameter) in calendar items. Pointing it at a UNC path made Outlook fetch the “sound” from the attacker’s SMB server when the reminder fired, with no click and no preview required. It scored 9.8. Microsoft attributed the exploitation to the Russian state actor Forest Blizzard (APT28), and CERT-UA was among the parties that surfaced the campaign. CVE-2024-21413, the MonikerLink bug reported by Haifei Li of Check Point and patched in February 2024, abused a crafted file:// moniker to bypass Outlook’s Protected View and leak NTLM credentials, and it could reach code execution through composite monikers. The Preview Pane was a valid attack vector there, which made it especially dangerous.

CVE-2026-124194 sits lower on that ladder in one respect: the victim must open the file, and the Preview Pane is explicitly safe. That single UI:R metric accounts for most of the difference between this bug’s 6.5 and its predecessors’ 9.8. The payload at the end of the chain is the same as in 2023, a captured NTLMv2 response followed by cracking or relay. So the outcome deserves the urgency the 2023 incident got, even though the trigger is tamer.

The mechanics are not interchangeable, though. Detection logic written for malicious reminder properties or moniker strings in message bodies does not prove coverage for this flaw, and the TTPs and indicators from those older campaigns say nothing about who is exploiting this one or how. Microsoft has not said which component of the message file holds the remote reference, so behavioral detection has to target the one observable that is certain: Outlook starting outbound authentication to infrastructure that is not yours.

Fixed Office builds for CVE-2026-124194

The patch is an Office patch, not a Windows patch. A device can show every Windows cumulative update installed and still run a vulnerable Outlook, because the fix ships through Office’s own servicing stack, Click-to-Run or the volume-licensed update process, and not through Windows Update. “Are we patched?” is a software inventory question. Answering it means reconciling which machines run classic Outlook, which channel each installation follows, and which build it is actually running.

The advisory’s affected list covers Microsoft 365 Apps for Enterprise, Office LTSC 2024, and Office LTSC 2021, in 32-bit and 64-bit editions. The fixed builds for the November 10 release are:

• Current Channel: Version 2610, build 20527.20196
• Monthly Enterprise Channel: build 20527.20194
• Semi-Annual Enterprise Channel: build 20527.20192
• Office LTSC 2024: 16.0.17932.21140
• Office LTSC 2021: 16.0.14334.21048

Microsoft’s Office security release notes confirm the Semi-Annual build and list CVE-2026-124194 among twenty Outlook fixes in the release. Microsoft also serviced older supported versions on the enterprise channels, with distinct builds for versions 2609 and 2608. A single “minimum build” cutoff applied across the fleet will therefore give wrong answers in both directions. Compare each device against the fixed build for its own channel and version. Version 2607 reached end of service on the enterprise channels on November 10, so rings pinned to it receive nothing until they move.

Two populations get no fix at all. Office 2016 and Office 2019 left support on October 14, 2025, and do not appear in the advisory. Treat any copy still in use as exposed, schedule its replacement, and let the network mitigations carry the load until then. The new Outlook for Windows, Outlook on the web, Outlook for Mac, and the mobile apps are not listed as affected, so this is a classic desktop Outlook problem.

How to force and verify the Outlook update

Click-to-Run stages updates but applies them only when Office applications close, so machines that never sign out can sit on a downloaded, inactive fix for days. Administrators can force the update on a single machine with "C:\Program Files\Common Files\microsoft shared\ClickToRun\OfficeC2RClient.exe" /update user, or push update deadlines through Microsoft 365 Apps policy or Intune so deferral stops being an option.

Then verify what is on disk instead of trusting the deployment console. In the client, File, Office Account, About Outlook shows the version and build. At scale, the Click-to-Run configuration key is scriptable:

powershell

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration" |
    Select-Object VersionToReport, CDNBaseUrl, UpdateChannel

VersionToReport returns values like 16.0.20527.20196, and UpdateChannel tells you which fixed build to compare against. Defender Vulnerability Management can also be filtered on the CVE to list exposed devices. Whichever route you take, the acceptance test is the build number observed on the endpoint, whatever color the ring shows in a deployment report.

How to mitigate Outlook NTLM leaks before patching

Every mitigation here targets the Windows behavior and not the Outlook defect, so they hold even against unpatched clients.

1. Block outbound TCP 445 and 139 from workstations and servers to the internet, and enforce the same rule in host firewalls so laptops on hotel and home networks are covered. SMB has no legitimate reason to cross your egress boundary. This has been standard advice since the 2023 campaign, and the number of environments that still do not enforce it is the main variable in how much this zero-day will cost.
2. Stop and disable the WebClient service on machines that do not use WebDAV. With port 445 blocked, Windows can retry the fetch over HTTP or HTTPS if WebClient is running.
3. Restrict outgoing NTLM. The Group Policy setting “Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers” (registry value RestrictSendingNTLMTraffic under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0) should be set to audit first, value 1, then moved to deny, value 2, with exceptions only for the legacy servers the audit reveals. Audit before denying, because NTLM still underpins older applications in most estates, and a blind deny turns a security fix into a Monday-morning outage.
4. Put your most valuable accounts in the Protected Users group. Those accounts cannot authenticate with NTLM at all, so there is no response to leak.
5. Close the relay destinations so a hash captured by some future trick is worthless on arrival. Require SMB signing, require LDAP signing and channel binding on domain controllers, and enable Extended Protection for Authentication on AD CS web enrollment and Exchange.
6. As an interim measure at the mail gateway, hold inbound .msg and .oft attachments from external senders until patch coverage is complete. This is a practitioner recommendation, and Microsoft has not published it as an official workaround.

None of this replaces the update. It shrinks the window in which one curious double-click becomes a domain incident.

How to hunt for CVE-2026-124194 exploitation without IOCs

With no indicators from Microsoft or CISA, detection has to be behavioral. Fortunately the behavior is anomalous: Outlook has no normal reason to open SMB connections to public IP addresses, so any hit is a lead worth pulling.

Endpoint and network telemetry

In Defender XDR advanced hunting, filter DeviceNetworkEvents for InitiatingProcessFileName equal to outlook.exe, RemotePort in 445 or 139, and RemoteIPType of Public. The Sysmon equivalent is Event ID 3 network connections initiated by the Outlook process.

For the WebDAV route, the fingerprint is the WebClient service driving rundll32.exe with davclnt.dll,DavSetCookie and the remote host on the command line. That is unusual enough to alert on for any external destination.

To reconstruct the trigger, look for outlook.exe launches with a .msg or .oft path on the command line, which is what opening a message file from Explorer or a download folder produces. Then join those launches against outbound SMB or WebDAV connections from the same device in the following minutes.

Firewall logs give a coverage-independent version of the same question, and they double as an audit of your egress rules. Any internal source reaching a public destination on port 445 with an “allow” verdict is a policy failure to fix before it becomes an incident to investigate.

Identity logs

On the client, the Microsoft-Windows-NTLM/Operational log records outgoing NTLM attempts in event 8001 with the target server named. An external server in that log on a workstation is direct evidence of a leak attempt. On the receiving end, baseline NTLM network logons (Event ID 4624, logon type 3, authentication package NTLM) per account and source address, then alert on new account and source pairs. Domain controllers’ 4776 credential-validation events add corroboration. A relayed or cracked credential almost always shows up as the user authenticating from somewhere they never authenticate from.

Incident response if a machine looks compromised

The forensic footprint is small but real. Retrieve the message file from the user’s Downloads folder, the mailbox, or Outlook’s attachment staging area under %LOCALAPPDATA%\Microsoft\Windows\INetCache\Content.Outlook, identify the sender, and sweep every mailbox for the same message.

Then respond on the assumption that the hash was captured:

• Reset the password. This kills the future value of the captured response but not anything the attacker already did with it.
• Revoke sessions and refresh tokens in Entra ID for synced accounts, and review recent MFA registrations.
• Audit AD CS for certificates issued to that account since the leak, and revoke any you cannot account for. A relayed certificate survives the password reset.
• Block the remote address, and search proxy and firewall history for other machines that reached it.
• Install the Office update before the user goes back to work.

CISA’s November 24 deadline and what to patch first

CISA’s deadline falls on November 24, fourteen days after listing, under the risk-based framework of BOD 26-04. The directive prioritizes rapid remediation of KEV-listed flaws on exposed, high-impact assets, and it sets expectations for agencies to check whether systems were compromised before the patch went on. That compromise-check clause matters most for a credential-disclosure bug exploited before a fix existed: patching closes the door without telling you who already walked through it.

Private organizations are not bound by the directive, but the two-week clock makes a sensible internal deadline, and the order of operations it implies is sound:

1. Patch the privileged mailboxes first.
2. Verify build numbers instead of deployment reports.
3. Filter SMB and NTLM at the boundary.
4. Hunt the identity logs for the days before the patch.

Keep the Moderate label in the CVSS field and out of the prioritization meeting. The score describes the bug, and the KEV entry describes the adversary.

Frequently asked questions about CVE-2026-124194

What is CVE-2026-124194?

CVE-2026-124194 is an exploited spoofing vulnerability in classic Outlook for Windows. When a user opens a crafted message file, Outlook connects to an attacker-controlled server without the usual external-content warning, and Windows sends the user’s NTLMv2 authentication response to that server. Microsoft rates it Moderate with a CVSS score of 6.5, and CISA added it to the KEV catalog on November 10, 2026.

Does patching Windows fix CVE-2026-124194?

No. The fix ships through Office servicing, either Click-to-Run or the volume-licensed update process. A fully updated Windows machine can still run a vulnerable Outlook, so check the Office build on each endpoint against the fixed build for its channel.

Can an attacker exploit it through the Preview Pane?

No. Microsoft’s advisory says the Preview Pane is not an attack vector. The user has to open the crafted message file in an affected version of Outlook.

How do I reduce the risk before the patch is installed?

Block outbound TCP 445 and 139 at the perimeter and on hosts, disable the WebClient service where WebDAV is not needed, audit and then restrict outgoing NTLM, and add privileged accounts to the Protected Users group. Require SMB signing, LDAP signing with channel binding, and Extended Protection for Authentication on AD CS web enrollment and Exchange to blunt relay attacks.