HIGH: Microsoft Outlook Zero-Day CVE-2026-124194 Leaks NTLMv2 Hashes

Pour one out for NTLM again. Microsoft has spent the better part of two years trying to retire the thing, and attackers keep finding fresh ways to pry hashes out of it anyway. This month the crowbar is Outlook.

Microsoft's November 2026 Patch Tuesday landed on November 10 with fixes for a staggering 1,259 vulnerabilities, the second month in a row the company has blown past the four digit mark. Buried in that avalanche is the one bug that actually deserves your morning. CVE-2026-124194 is a Microsoft Office Outlook flaw that Microsoft confirms is being exploited in the wild, and CISA wasted no time adding it to the Known Exploited Vulnerabilities catalog the same day. Federal civilian agencies have until November 24 to patch. Everybody else should treat that date as a ceiling, not a target.

What the bug actually does

On paper this one looks almost polite. Microsoft scores it a 6.5 on the CVSS 3.1 scale with a vector of AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, which translates to a network attack that needs no credentials, has low complexity, requires the victim to do something, and hits confidentiality hard while leaving integrity and availability alone. The weakness is classified as CWE-356, the somewhat sleepy sounding "Product UI does not warn user of unsafe actions." Microsoft's official description says the flaw allows an unauthorized attacker to perform spoofing over a network.

The plain English version is more alarming. An attacker crafts a malicious message file and convinces the target to open it in a vulnerable copy of Outlook. When that happens, Outlook reaches out to a network location the attacker controls, and it does so without throwing the external content warning that is supposed to stop exactly this behavior. That outbound connection hands over the user's authentication material, most notably a NetNTLMv2 hash, which the attacker can then crack offline or relay to another service to impersonate the victim.

Microsoft's temporal metrics on the advisory tell the rest of the story. The exploit code maturity is rated High, a remediation is officially available, and the report is confirmed. In other words, Microsoft knows it works, knows people are using it, and has shipped a fix. The company has not attributed the activity to any threat actor and has not published technical details of the attacks it observed, so we do not know who is behind it or how broad the campaigns are.

Credit for the discovery goes to a researcher identified as Nono and to Benoît Sevens of Anthropic, who found the issue with help from Claude. It is worth noting that Microsoft's advisory does not say whether the bug was reported before or after attackers started using it, so do not read the credit line as proof that the exploitation was a researcher's proof of concept escaping into the wild.

Why a "Moderate" bug gets a HIGH from me

If you triage purely by CVSS, CVE-2026-124194 slides comfortably into the "next maintenance window" pile. That would be a mistake, and I am not the only one saying it. Action1's team pointed out that the Moderate rating understates the real risk because the flaw is already being exploited, needs only a single click, and lives inside one of the most widely deployed applications on the planet. Jack Bicer of Action1 put it bluntly, noting that email remains the easiest way into a company and that this bug turns one opened file into a stolen identity.

Those of us who have been doing this a while have seen this movie before. CVE-2023-23397 let attackers grab NTLM hashes from Outlook with a malicious calendar reminder and was used by Russian state actors against European governments for months before anyone noticed. CVE-2024-21413, the MonikerLink bug, abused crafted hyperlinks to achieve the same kind of credential leak. Each time the pattern is identical. Outlook gets tricked into authenticating to a server it should never trust, the hash goes out the door, and the attacker gets a foothold that looks like a legitimate login.

A captured NetNTLMv2 hash is not a theoretical prize. Weak and moderate passwords fall to modern GPU cracking rigs in hours. Even strong passwords do not help if the attacker skips cracking entirely and relays the authentication to an Exchange server, a file share, an LDAP endpoint without channel binding, or an AD CS web enrollment page. That last path has produced domain compromise from a single relayed hash in more incident reports than I care to count.

Who is affected

The affected products are Microsoft 365 Apps for Enterprise, Office LTSC 2021, and Office LTSC 2024, in both their 32 bit and 64 bit editions. According to the NVD record, Office LTSC 2021 is fixed in build 16.0.14334.21048 and later, and Office LTSC 2024 is fixed in build 16.0.17932.21140 and later. Microsoft 365 Apps customers get the fix through their normal Click to Run update channel, and Microsoft points administrators to its Office Security Releases page for the exact build that applies to each channel.

Office 2016 and Office 2019 do not appear in the advisory. Those products left support in October 2025, so their absence should not be read as a clean bill of health. If you still have them in production, you have a bigger problem than this CVE, and this is a very good week to have that conversation with whoever owns the budget.

Organizations running Outlook on the web or the new Outlook for Windows are not listed among the affected products, but most shops I talk to still have classic Outlook installed on the majority of desktops, especially in finance, legal, and healthcare where add ins and shared mailboxes keep people anchored to the old client.

What to do right now

Patching is the first and best answer. Push the November Office updates to every endpoint running classic Outlook, and verify the build numbers rather than trusting that Click to Run did its job. Devices sitting on a deferred or semi annual channel are the ones most likely to lag, so check your channel configuration in Intune or your configuration management tool of choice and force an update on anything still behind.

While the patch rolls out, there is a lot you can do to take the teeth out of NTLM leakage in general. Blocking outbound SMB on TCP port 445 at the perimeter has been best practice for years, and it stops the most common way these hashes leave the building. Do not forget WebDAV, which attackers use as a fallback over ports 80 and 443 when SMB is blocked. Disabling the WebClient service on workstations that do not need it closes that door. Adding privileged and high value accounts to the Protected Users security group prevents them from using NTLM at all, which means there is no hash to steal in the first place.

For organizations further along in their hardening, the group policy setting "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers" lets you audit and then deny NTLM authentication to destinations outside an approved list. Start in audit mode, review the results for a week or two, and then flip it to deny. On the relay side, enforce SMB signing, require LDAP signing and channel binding on domain controllers, and enable Extended Protection for Authentication on Exchange and AD CS web enrollment. Each of those controls breaks a relay chain that a stolen hash would otherwise enable.

Hunting for exploitation

Because Microsoft has not shared indicators, detection has to focus on behavior. The most useful signal is OUTLOOK.EXE initiating outbound connections to external IP addresses over SMB or WebDAV. Your EDR should be able to surface network events where the parent process is Outlook and the destination port is 445, or where the WebClient service spins up immediately after a user opens a message. Any of those hitting an internet address is worth an immediate look.

On the identity side, look at Windows Security event 4624 logons using NTLM from unexpected source hosts, and event 8001 in the NTLM operational log if you have enabled NTLM auditing. A user whose account suddenly authenticates via NTLM from a machine they have never touched, shortly after receiving an external email with a message file attachment, is the textbook pattern. Mail gateway logs can help too. Inbound .msg attachments from external senders are uncommon in most environments and are worth flagging or quarantining until you are fully patched.

If you find evidence of a hash leak, rotate the affected user's password immediately, review their sign in history for relayed authentications, and check whether the account had access to anything that would make it a useful pivot point.

The rest of November's pile

The Outlook bug is the only flaw flagged as actively exploited this month, but it is far from the only thing worth patching. The release includes remote code execution fixes for Windows Search (CVE-2026-116928), LDAP (CVE-2026-119958), Windows Schannel (CVE-2026-119952), the Windows Virtual Filtering Platform (CVE-2026-95962), and the Xbox Live Networking Service (CVE-2026-112967), along with a privilege escalation issue in Azure OpenAI (CVE-2026-119990). More than 500 of this month's flaws are elevation of privilege bugs, and Tenable's Satnam Narang notes that Microsoft has now patched more than 5,100 CVEs in 2026 alone.

With volumes like that, prioritization is the whole game. Jake Knott of watchTowr offered sensible advice, suggesting teams start with internet exposed assets, move to actively exploited vulnerabilities, and then work through everything else while checking whether vulnerable components are actually in use. This month that order puts the Outlook fix, the Schannel and LDAP bugs on exposed systems, and then the long tail.

The bottom line

CVE-2026-124194 is a reminder that CVSS scores measure technical severity, not real world risk. A 6.5 that is being actively exploited through the most popular email client in business beats a 9.8 nobody is touching every single time. Patch Outlook this week, block outbound SMB and WebDAV if you have not already, and use this as the push you needed to finally start restricting NTLM across the environment. Microsoft is going to kill it eventually. There is no reason to wait for them.

If an IT provider manages your systems

Microsoft confirms that attackers are already exploiting CVE-2026-124194. If someone at your company opens one malicious message file in classic Outlook, an attacker can get that person's login. Raise this with whoever runs your IT this week.

• Have the November Office updates been installed and checked on every computer running classic Outlook? That means build 16.0.14334.21048 or later for Office LTSC 2021 and 16.0.17932.21140 or later for Office LTSC 2024.
• Is outgoing SMB on port 445 and WebDAV blocked, so Outlook cannot send our credentials to outside servers?
• Are you watching for Outlook connecting to internet addresses, or for unusual NTLM logins?

A good answer is specific: confirmed build numbers, named firewall rules and a clear finding on suspicious activity. If your provider is unsure, or finds signs that a password hash leaked, bring in incident response before one stolen login turns into a wider breach.

If you are an IT provider yourself, see how we partner with MSPs.