AI Lab Blog

The Outlook Zero-Day That Hands Over Your Hash, and Why the Score Undersells It

November 13, 2026

Tags: Threat Intelligence, Vulnerability, Identity, Microsoft, NTLM

Andy Surujnarine writes about cloud operations, identity, and the unglamorous controls that actually hold.

A message file arrives. A user double-clicks it because that is what people do with files that look like email. Outlook, which is supposed to warn before it reaches out to the network on your behalf, does not warn. It connects to a host the attacker controls, presents the user’s NTLMv2 hash, and the attacker now holds a credential that can be relayed into another system or cracked offline at leisure.

That is CVE-2026-124194. It was fixed in Microsoft’s November Patch Tuesday release, and CISA added it to the Known Exploited Vulnerabilities catalog on November 10, which means someone is using it in the wild rather than admiring it.

What we can actually verify

The NVD record, published November 10 and updated the next day, describes the flaw plainly: “Product ui does not warn user of unsafe actions in Microsoft Office Outlook allows an unauthorized attacker to perform spoofing over a network.” No prior access, no credentials, no elevation. The attacker needs one thing, which is a recipient willing to open a file.

The scoring is where the conversation gets interesting. Under CVSS v3.1 this is 6.5, medium. The vector explains why: network reachable, no privileges required, but user interaction required, scope unchanged, and the impact assessed as confidentiality only. Under the older CVSS v2 scale it reads 7.8, high. Both numbers describe the same bug. Tenable’s entry lists it as medium while flagging it as a known exploited vulnerability, which is an accurate summary of the awkwardness: our scoring system prices a credential theft as a confidentiality problem.

It is not a confidentiality problem. A leaked NTLMv2 hash is authentication material. Relay it against a host that accepts NTLM without requiring signing, and you are that user. Crack it offline and you have their password, which is probably valid on three other systems. The reason the score looks mild is that CVSS measures the vulnerability in front of you, not the two weeks of lateral movement it unlocks.

Affected products, per Microsoft’s guidance and the reporting around it: Microsoft 365 Apps for Enterprise, Office LTSC 2021, and Office LTSC 2024. The fix ships in the Office update for your channel, not in the Windows cumulative update. That detail is doing a surprising amount of work in real environments.

The precedent is three years old

In March 2023, Microsoft patched CVE-2023-23397, an Outlook elevation-of-privilege flaw with the same shape: a crafted message, a property that Outlook resolved automatically, an outbound authentication to an attacker-controlled server, and the user’s Net-NTLMv2 hash on the wire. APT28, the GRU unit also tracked as Forest Blizzard, had been exploiting it against European targets for close to a year before the patch. CISA put it in the KEV catalog within weeks and gave federal agencies a deadline.

The 2023 fix added a warning and blocked the underlying behavior. The 2026 flaw, as described, is the same primitive getting past the warning path again. That should be the part that stops people, more than the CVSS number. Three years, one patch cycle per month, and a class of bug that keeps returning because the thing it abuses has not been removed.

The abuse is not exotic. Windows will happily perform an outbound NTLM authentication when asked, and Outlook is a program that resolves external references in messages in order to render them. Put those two facts together and you get a client-side coercion primitive. The attacker is not breaking authentication. They are asking politely and being answered.

Where the patch goes wrong in practice

The single most useful operational fact about CVE-2026-124194 is that it is an Office-serviced vulnerability. If your patching story is “Windows Update handles Patch Tuesday”, your Outlook may still be vulnerable while your compliance dashboard turns green, because the client is serviced through Click-to-Run channels rather than the operating system.

Three things to check this week.

First, which channel your Microsoft 365 Apps installs are on. Current Channel gets builds fastest. Monthly Enterprise Channel lags by roughly a month by design. Semi-Annual Channel can be several months behind. None of that is a scandal, it is a servicing model, but it means the same CVE has three different patch dates depending on where a given machine sits, and your reporting usually averages them into one comforting number.

Second, whether Office LTSC is in scope in your estate. LTSC installs get security updates, but they do not pick up the channel servicing timeline people assume, and they live on the machines nobody thinks about: jump hosts, thin-client images, clinical workstations, kiosks, the laptop an executive keeps for a single vendor portal.

Third, whether your inventory even names the Office build. Most CMDBs track Windows versions well and Office versions badly.

Four controls that close the class

Patching closes this envelope. The next one arrives in a few years with a new number. These are the controls that make the class uninteresting to attackers, roughly in order of return on effort.

Enforce SMB signing, and Extended Protection for Authentication, on anything that accepts NTLM. Signing breaks relay. EPA binds the authentication to the channel it was requested on, which breaks the redirect. If these are not on for your file servers and your domain controllers, a leaked hash is a live credential, and this CVE is a path to your file shares.

Reduce and restrict NTLM where the estate allows it. Microsoft’s own policy settings allow you to audit NTLM usage, then restrict outbound NTLM to a defined allowlist, then block it. Most organizations discover that after the audit, NTLM is confined to a short list of legacy appliances that can be remediated one at a time. That work is unglamorous and it is the actual fix.

Block outbound SMB from workstations, and alert on attempts. Port 445 leaving a workstation subnet should be an exception with a ticket attached, not background traffic. Block it at the perimeter and at the host firewall, then treat every alert as an intelligence event rather than noise.

Hunt for it, because prevention always has a gap. Look for network connections from outlook.exe to external addresses on 445, and for WebDAV paths if that is enabled. Look for authentication events, including 4624 type 3 and the NTLM-specific operational logs, originating from hosts that should never be authenticating to anything outside your network. Look for a spike in failed authentications against a single account across multiple systems, which is what relay attempts look like from the receiving end.

Detection detail worth having

The attacker’s server has to be reachable. That gives you two chances: block the path, or catch the attempt. In most enterprises the second is more realistic in the short term, because the first requires knowing every application that legitimately speaks SMB to an outside host, and something always does.

Two rules earn their keep. Alert when a process that should not open a network connection to an external address does so, with Outlook at the top of that list. And baseline NTLM authentication by source and destination for a week, then alert on anything new. Both are cheap, both are boring, and both catch more identity attacks than most of what sits in a modern detection stack.

The uncomfortable part

We keep treating credential theft as a secondary consequence of a display bug. The vulnerability here is described in the language of user interface: the product failed to warn. Strip that framing away and the finding is that a mail client can be induced to authenticate to an arbitrary host, and the operating system will hand over cryptographic material that functions as a password.

That is not a UI problem. It is an authentication design problem that happens to surface through a UI. Until NTLM stops being ambient authority on Windows networks, every Outlook rendering issue is a potential credential leak, and every credential leak is lateral movement waiting for a quiet weekend.

Patch the envelope. Then turn off the post office.

Sources

• NVD and CVE record for CVE-2026-124194, published November 10, 2026.
• CISA Known Exploited Vulnerabilities catalog, entry added November 10, 2026.
• Tenable CVE entry, scoring and EPSS detail.
• Microsoft November 2026 Patch Tuesday coverage, affected products and servicing detail, including PCWorld, The Hacker News, and SecurityWeek.
• Microsoft guidance and public reporting on CVE-2023-23397, the March 2023 Outlook NTLM leak exploited by APT28.