Outlook leaks your hash, and Microsoft calls it "moderate"

On Tuesday Microsoft shipped patches for 1,095 vulnerabilities. Exactly one of them is already being exploited, and it happens to carry the lowest severity label in the batch. If your patching queue is sorted by "critical first", that one went last. It is called CVE-2026-124194, it lives in Outlook, and what escapes when somebody opens the file is not the contents of the email: it is their NTLMv2 hash.

One out of 1,095, and it is the one at the bottom

This week's headlines say 1,094. We prefer to count, so we went to the Security Update Guide API and asked for the whole 2026-Nov release. As of today it returns 1,511 entries, of which 1,095 have Microsoft as the CNA; of the rest, 219 come from Chromium —those are the Edge ones—, 196 from Azure Linux (Mariner) and one is left over. The figure wobbles by a point depending on the day you look, because the catalogue keeps moving after Tuesday: we publish ours with the method attached, not on faith.

There are two "moderate" entries in the whole month and one of the two is the one being used. None of the 64 criticals is. None of the 1,029 importants either. And in case you think the label at least tracks the score: CVE-2026-113864, a Hyper-V elevation of privilege, is flagged Critical with a CVSS of 6.4; the Outlook one, at 6.5 —higher, that is— is flagged Moderate. The highest score of the month is a 10.0 in Entra Device Registration and nobody is exploiting it. Sort by score and 930 of the 1,095 tie or beat the only one that is actually happening.

This is not a Microsoft mistake. Severity measures potential damage in the worst imaginable scenario, and a credential leak looks, on paper, quieter than taking over a hypervisor. The mistake is ours, when we use that label as a work order. They are two different lists: one says how much this could hurt and the other says what is happening right now. We have spent years sorting by the first.

What it does, in Microsoft's own words

The advisory classifies it as spoofing and gives it a CWE that tells the whole story: CWE-356, "Product UI does not Warn User of Unsafe Actions". The FAQ puts it like this, verbatim: "An unauthenticated attacker could send a specially crafted message file and convince a user to open it in an affected version of Microsoft Outlook. Opening the file could cause Outlook to connect to an attacker-controlled network location without displaying the usual external-content warning, potentially disclosing authentication information that could be used to impersonate the user."

And what that "authentication information" is, another FAQ answer says flatly: "This vulnerability discloses a user's NTLMv2 hash to the attacker who could use this to authenticate as the user." It pays to be precise, because precision here changes what you do about it: an NTLMv2 response is not the NT hash you replay straight into a classic pass-the-hash. With a captured NTLMv2 response you do one of two things: relay it live against a service that still accepts NTLM, or take it home and crack it at your leisure. Microsoft's own SMB documentation sums up the catalogue in one line when it explains why you should cut outbound NTLM: "counteracting brute force, cracking, and pass-the-hash attacks".

What comes after that we have already told with a stopwatch in hand: two hours from a captured credential to attempting domain admin. The jump is not made by the bug; it is made by the three or four design decisions sitting between the user's machine and the directory.

The patch does not arrive through Windows Update

Here is the operational detail that turns this into an estate problem rather than a security note. The affected products are six rows: Microsoft 365 Apps for Enterprise (32 and 64 bit) and Office LTSC 2021 and 2024 (32 and 64 bit). None of the six carries a KB; the article column just says "Release Notes". That is not an oversight: this Office updates itself from the Office content delivery network, per channel, and not down the same road as Windows. An estate with 100% of Windows up to date can have 100% of Outlook unpatched, and the update dashboard will stay green.

These are the builds Microsoft published on 10 November that carry this CVE. The number you will see on the machine lives under File → Account, next to the channel name:

Three things worth knowing about that table. First: the default channel, if nobody chose anything at deployment time, is Current Channel, which gets security on the second Tuesday like the others but also unscheduled drops through the month. Second: Monthly Enterprise keeps three versions alive at once, so a machine on 2608 was not out of support —it was supported right up to this Tuesday— but it needs its own build, 20326.20320, and nobody is going to push it forward early. And third, for those running Semi-Annual precisely so that nothing moves: since July 2026 that channel receives feature and security updates every month, with a two-month rollback window. The "slow" channel is not that slow any more.

Three conditions, and two of them are yours

For that hash to end up in somebody's hands, three things have to line up. The first is the trigger: an Outlook bug that skips the warning. That one is not yours to control, and it is already patched —until the next one, because this family of bugs has been resurfacing for years with different triggers; back in October we counted seven documented ways for the external-origin warning not to decide anything—. The second is that the user's machine is willing to speak NTLM to a server outside. The third is that the connection finds its way out. The last two are your decisions, and both can be changed today.

One honesty note before we go on: Microsoft says "an attacker-controlled network location" and does not say over which protocol. The switch coming next covers SMB, which is the classic road for this kind of leak. If the location is reached another way, it does not cover it. Which is why egress control —what an office laptop may open towards the internet and what it may not— is the layer that does not depend on guessing the protocol, and why in our deployments outbound 445 is closed from day one, with no exceptions negotiated over the phone.

The switch you already have, and it is off

Since Windows 11 24H2 and Windows Server 2025, the Windows SMB client knows how to refuse NTLM outbound. The documentation says it with unusual clarity: "The SMB client now supports blocking NTLM authentication for remote outbound connections. Blocking NTLM authentication prevents bad actors from tricking clients into sending NTLM requests to malicious servers." That is, literally, a description of what we just read in the Outlook FAQ. And it ships off.

Via group policy it sits under Computer Configuration → Administrative Templates → Network → Lanman Workstation, named "Block NTLM (LM, NTLM, NTLMv2)". Via PowerShell it is one line: Set-SmbClientConfiguration -BlockNTLM $true. There is a per-server exception list —"Block NTLM Server Exception List"— designed for exactly the case you are going to hit, and which the documentation itself names: "when the SMB server you're trying to connect to isn't joined to an Active Directory domain". And it can be applied to a single share at mount time: NET USE \\server\share /BLOCKNTLM or New-SmbMapping -RemotePath \\server\share -BlockNTLM $true.

The version requirement is not a minor detail for a smaller company: if your estate never reached 24H2, this switch does not exist on your machines. And it is worth reading alongside the other date, because 24H2 support on Home and Pro ended on 13 October while on Enterprise and Education it runs to October 2027. Same version number, two calendars. Whoever did that inventory in October already knows today on how many machines they can turn this on.

When NOT to do this

If you have just read the above and you are about to push the policy to the whole domain this afternoon, stop. Blocking outbound NTLM all at once in a real estate breaks things, and it breaks the usual ones: the storage array that is not domain-joined, the NAS in the office upstairs, the multifunction printer scanning to a shared folder, the 2011 line-of-business app that authenticates however it can. Those are exactly what the exception list exists to save. The order that works is boring and it is the usual one: inventory which SMB shares each group of machines reaches, a written exception list, a pilot in one department, and the general block last.

And the most honest "when not" of all: if nobody in your company uses desktop Outlook —only the browser one— this particular CVE does not apply to you. That is a five-minute check and it saves you the afternoon. What does apply, whichever client you use, is the question underneath: why can a laptop of yours authenticate against an internet server you have never laid eyes on?

What CISA says, and what it does not

On that same 10 November, CISA added this CVE to its known exploited vulnerabilities catalogue with a deadline of 24 November: fourteen days. In the catalogue (version 2026.11.10) the ransomware-campaign field reads "Unknown": it is happening, but there is no documented extortion crew behind it yet. How those deadlines are worked out today, and why they have stopped working as a severity thermometer, is what we wrote about this morning, comparing two advisories for the same appliance three years apart.

That deadline binds US federal agencies, not a company in Sabadell. We say so because some people sell the catalogue as if it were regulation here, and it is not. Its value to us is different: when a batch arrives with 1,095 patches, what is missing is not scoring, it is an ordering criterion. And the criterion has been published since Tuesday, just not where we usually look for it.

Where this fits into what we do

We do not sell Microsoft licences and we have no quota to hit with anyone. What we do with a managed workplace is unglamorous: knowing which Office version each machine runs and on which channel, choosing that channel on purpose instead of inheriting it, and having it written down what a laptop may open towards the outside. That last line is the boring kind of cybersecurity, the one that never makes it into a demo. The first is estate maintenance, which is almost entirely about knowing what you have before somebody asks whether you are affected.

Failure is inevitable; an outage is a design decision. Here the failure is a mail client skipping a warning: it happens, it has happened before and it will happen again. The outage is that, when it does, somebody's credential can walk out of your building with nothing in the way. Between those two things sit a switch already installed on your machines and an egress rule that costs nothing. Neither of them appears on the list of 1,095.

Sources (verified 12 Nov 2026): Microsoft Security Update Guide, the CVE-2026-124194 advisory and its public API (severity Moderate, CVSS 6.5 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N/E:H/RL:O/RC:C, CWE-356, "Exploitation Detected", publicly disclosed "No", the three quoted FAQ answers and the six affected-product rows with no KB); our own count against the same endpoint for the 2026-Nov release (1,511 entries, 1,095 with Microsoft as CNA, 64 Critical, 1,029 Important, 2 Moderate, a single exploited one, CVE-2026-113864 as Critical at 6.4 and CVE-2026-109469 as the month's highest at 10.0). CISA, KEV catalogue, version 2026.11.10 downloaded raw (added 10 Nov, due 24 Nov, ransomware "Unknown"). Microsoft Learn, "Release notes for Microsoft Office security updates" (the 10 Nov 2026 builds in the table) and "Overview of update channels for Microsoft 365 Apps" (default channel, security on the second Tuesday, three live versions in Monthly Enterprise and the Semi-Annual change from July 2026). Microsoft Learn, "Block NTLM connections on SMB" (the outbound-blocking quote, the Windows 11 24H2 and Windows Server 2025 requirement, the Lanman Workstation policy, the exception list and the commands) and "Guidance about how to configure protected accounts" (NTLM under Protected Users, the warnings and the 240 minutes). The readings and the cross-checks are ours.