Outlook zero-day CVE-2026-124194 and the Microsoft 365 outage: two separate events, one hard week

Short answer. Two Microsoft stories landed in the same week, and they are not connected. On 10 November 2026, Microsoft patched CVE-2026-124194, an Outlook spoofing flaw that attackers were already exploiting. If a user opens a crafted message file, Outlook can connect to an attacker's server without its usual external-content warning, and that leaks the user's NTLMv2 hash. CISA added it to the Known Exploited Vulnerabilities catalog the same day. Then, on 12 November, Microsoft 365 suffered a large outage that took down Exchange Online mailboxes and disrupted Teams, SharePoint and Copilot. Microsoft says there is no indication that the outage was malicious, and it has not yet published a root cause.

Part one covers the Outlook flaw: how NTLM works, how a leaked hash becomes a cracked password or a relayed login, who is exposed, and how to hunt for it and shut it down. Part two covers the outage, the concentration risk behind it, and the phishing that follows every big outage. The two are separate events. Nothing Microsoft or any credible outlet has published links them, and we don't either.

At a glance

Part one: CVE-2026-124194, the Outlook NTLM leak

What Microsoft published

Microsoft's Security Update Guide entry titles the bug "Microsoft Outlook Spoofing Vulnerability". The official description reads: "Product ui does not warn user of unsafe actions in Microsoft Office Outlook allows an unauthorized attacker to perform spoofing over a network." The weakness class is CWE-356, Product UI does not Warn User of Unsafe Actions.

The record's key fields, as Microsoft published them on 10 November 2026 at 08:00 Pacific:

• Severity: Moderate.
• Impact: Spoofing.
• CVSS 3.1 base score: 6.5, with temporal score 6.2. The vector is AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N/E:H/RL:O/RC:C: network attack, low complexity, no privileges needed, user interaction required, high confidentiality impact, and exploit maturity rated High.
• Exploited: Yes ("Exploitation Detected").
• Publicly disclosed: No.
• Customer action required: Yes.

The FAQ is the useful part. Microsoft says 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."

Three more details from the same FAQ narrow the risk:

1. The Preview Pane is not an attack vector. Selecting the message in the list is not enough. The user has to open the file.
2. User interaction means opening a file. Microsoft's wording: "An attacker must send a user a malicious Office file and convince them to open it."
3. What leaks is the NTLMv2 hash. In Microsoft's words, the flaw "discloses a user's NTLMv2 hash to the attacker who could use this to authenticate as the user."

So this is not code execution. The flaw is narrower and older in kind: Windows hands an identity proof to a server it should never have trusted.

Why a "Moderate" bug is on CISA's exploited list

CISA added CVE-2026-124194 to its KEV catalog on 10 November 2026. The KEV entry names it "Microsoft Office Outlook Missing User Interaction for Potentially Unsafe Action Vulnerability" and records known ransomware use as "Unknown". The entry links back to the MSRC record and to NVD.

A Moderate rating and a KEV listing don't contradict each other. The severity rating asks how bad the bug is in isolation, and a spoofing flaw that needs a user to open a file scores lower than wormable code execution. KEV asks whether someone is using it right now, and CISA says yes. What leaks is a credential, and in a Windows domain a credential is often the first link in a longer chain. Treat the patch as urgent.

Patch Tuesday context

CVE-2026-124194 shipped in a huge November release. Outlets don't agree on the total. SecurityOnline counts 1,093 vulnerabilities and notes the total includes CVEs Microsoft republished for third-party code such as Chromium and OpenSSH. Qualys gives 1,235 in its headline, while its product-family table adds up to 1,094. Action1 also reports 1,094. The gap comes mostly from whether Edge and other republished third-party CVEs are counted. Safe to say: more than 1,000 vulnerabilities, and CVE-2026-124194 is the only one marked exploited.

In a release that size, a Moderate Outlook bug is easy to miss in triage. KEV status is the filter that should pull it to the top.

NTLM in plain terms

What NTLM is

NTLM (NT LAN Manager) is Microsoft's older challenge-response authentication protocol. Windows still falls back to it when Kerberos can't be used, for example when a client connects by IP address or the server is outside a trusted domain (NTLM overview). Microsoft's deprecated features list says "All versions of NTLM, including LANMAN, NTLMv1, and NTLMv2, are no longer under active feature development and are deprecated", and that calls to NTLM "should be replaced by calls to Negotiate, which tries to authenticate with Kerberos and only falls back to NTLM when necessary."

How the handshake works

NTLM is a three-message exchange. The client sends a negotiate message. The server replies with a random challenge. The client then authenticates without sending the password: in NTLMv2 it derives a key from the user's NT hash (a hash of the password), user name and domain, computes an HMAC over the server challenge, a client challenge and a timestamp, and sends the result. The server, or a domain controller for it, recomputes and checks it.

Two different things get called "the hash":

• The NT hash is stored on the domain controller and cached on endpoints. If an attacker steals it, they can often use it directly ("pass the hash").
• The NTLMv2 response, often called a Net-NTLMv2 hash, is what goes over the wire during a login. It's bound to one challenge and can't be replayed later as-is, but it can be cracked offline or relayed in real time.

CVE-2026-124194 leaks the second kind, the NTLMv2 response, to a server the attacker controls.

Why Windows sends it at all

When a program opens a UNC path (\\server\share\file), the SMB client contacts the server and, if asked, authenticates as the signed-in user, often with no prompt. WebDAV, which carries file access over HTTP through the WebClient service, can do the same depending on zone and policy settings. So if an attacker can get a Windows application to reach their server, Windows may authenticate to it for the user. Outlook's external-content warning exists partly to stop that. In CVE-2026-124194 the warning didn't appear.

What an attacker does with a leaked NTLMv2 response

Offline cracking. The attacker holds the challenge and the response, guesses passwords, and compares. There's no lockout and no contact with the victim's network. Short or common passwords fall quickly on commodity GPUs, while long random passphrases resist. A cracked password works anywhere it isn't backed by phishing-resistant MFA.

Relay. The attacker forwards the victim's authentication in real time to another service that accepts NTLM, which sees a valid login. Microsoft's security policy reference puts it directly: "NTLM and NTLMv2 authentication is vulnerable to various malicious attacks, including SMB relay, man-in-the-middle attacks, and brute force attacks." Relay works against services that don't bind the login to the session or channel: SMB without required signing, LDAP without signing or channel binding, and HTTP services without Extended Protection for Authentication (EPA).

Reconnaissance. Even a failed crack reveals the user name, the domain and the fact that the victim opened the bait.

This class has been here before

CVE-2026-124194 belongs to a well-known family of Windows and Outlook bugs that coax a client into authenticating to an attacker. Earlier cases include the Outlook elevation-of-privilege flaw CVE-2023-23397, which we analysed in our CVE-2023-23397 write-up. There was also the Outlook "Moniker Link" bug CVE-2024-21413, covered in our analysis, and the Windows NTLM hash disclosure CVE-2025-24054, covered here. Each finds a new way past a client-side check. The defence that holds across all of them: stop NTLM leaving the network, and make relayed NTLM useless where it lands.

The attack chain, step by step

This is a conceptual walk-through built from Microsoft's FAQ and from how this class of bug has worked historically. It contains no exploit code or payloads. Microsoft has not published the exact file structure, the protocol the connection uses, or indicators of compromise, and we don't guess at them.

1. Preparation. The attacker stands up a server on the internet that will accept a connection and request NTLM authentication. They build a message file that references a resource on that server in a way Outlook should warn about but, before the patch, did not.
2. Delivery. The file reaches the target, most plausibly by email. Microsoft describes it as "a specially crafted message file" and, in the user-interaction answer, "a malicious Office file". The surrounding message gives the user a reason to open it.
3. The user opens the file. This step is required. Previewing is not enough, per Microsoft.
4. Outlook reaches out without warning. Instead of showing the external-content prompt, Outlook connects to the attacker-controlled network location.
5. Windows authenticates. The server asks for authentication, and Windows answers with the user's NTLMv2 response.
6. Capture, then one of two paths.
   • Crack: the attacker takes the response offline and guesses passwords.
   • Relay: the attacker forwards the authentication straight away to a service that accepts NTLM without signing or channel binding, and acts there as the user.
7. Follow-on activity. With a password or an authenticated session, the attacker moves to whatever that identity can reach: mailboxes, file shares, internal web apps or, in the worst case, directory changes.

Every step is a place to break the chain. Patching removes step 4. Blocking egress keeps step 5 off the internet, and restricting NTLM stops it entirely. Signing, EPA and channel binding defeat the relay branch. Strong passwords slow the crack branch.

Who is exposed

Affected products

Microsoft's affected-product list for CVE-2026-124194 contains six entries, all marked fixed:

Other Outlook clients do not appear in Microsoft's affected list for this CVE. Don't assume they're safe from the broader NTLM problem, but for this specific bug, the six entries above are the scope Microsoft states.

Who should worry most

• Desktop Outlook users on the products above without the November update. Click-to-Run updates aren't instant, and deferred channels or a lagging update source hold them back further.
• Users whose credentials are worth most: administrators who read mail on privileged machines, finance and executive staff, and service desk staff who can reset credentials.
• Laptops off the corporate network, where the perimeter firewall's SMB block doesn't apply.
• Domains with relay targets: SMB signing not required, LDAP channel binding not enforced, or enrolment web services without EPA.
• Accounts with weak or reused passwords, which offline cracking recovers.

Who is better placed

• Members of the Protected Users group, who can't authenticate to the domain with NTLM (Protected Users).
• Networks that block outbound TCP 445 at every exit, including on roaming hosts.
• Endpoints where outgoing NTLM is restricted to an allow list of internal servers.

Timeline

All times are as published by the cited source. IST is UTC plus 5:30.

The patch and its servicing channels

Microsoft fixes CVE-2026-124194 through the regular Office security updates, not a Windows update. That catches teams out every time. Patching Windows doesn't fix Outlook.

Microsoft's Microsoft 365 Apps security updates page lists CVE-2026-124194 under Outlook in the 10 November 2026 release. These are the builds:

In practice:

• Find out what you actually run. Collect the Office build from every Windows endpoint through device management and compare it with the table. In Outlook, it's under File, Office Account, About Outlook.
• Check your update source. If clients update from a local share or a management tool instead of the Office content delivery network, make sure that source has the November builds. A stale source is the usual reason a "patched" fleet isn't.
• Shorten deferrals for this one. An exploited flaw with a public patch is worth pulling forward to days, not the usual monthly ring.
• Restart Outlook. Office updates apply when the apps close. Use a forced-restart deadline, then re-collect build numbers 48 hours later and chase stragglers.

Detection: how to hunt for this

Microsoft has not published indicators of compromise for CVE-2026-124194. Hunting therefore focuses on the behaviour the bug produces, an Outlook-initiated connection to an untrusted server followed by an NTLM authentication, and on what an attacker does with the stolen credential afterwards.

1. SMB and WebDAV egress to the internet

The cleanest signal is outbound SMB (TCP 445, and legacy 139) from a user endpoint to a public IP address. In most organisations that traffic has no business reason, so every hit deserves a look.

• Firewall and proxy logs: allowed or denied connections from client subnets to the internet on 445 or 139. Denied attempts still matter, because the host that tried is the one to investigate.
• WebDAV: when SMB fails, Windows can fall back to WebDAV over HTTP or HTTPS through the WebClient service. Look for PROPFIND and OPTIONS requests to unfamiliar external hosts, and for WebClient starting on machines that don't normally use it.
• DNS: lookups for unfamiliar domains just before an outbound 445 or WebDAV attempt.

2. Outlook process network events

OUTLOOK.EXE connecting directly to an external IP on port 445 is highly suspicious. WebDAV traffic usually appears under the service host process that runs WebClient instead, so correlate by time and user.

Useful sources:

• Sysmon Event ID 3 (network connection) with Image ending in OUTLOOK.EXE and DestinationPort 445, or with any public destination you don't recognise. Sysmon Event ID 22 (DNS query) from the same process.
• Windows Security Event ID 5156 (Windows Filtering Platform permitted a connection), filtered for the Outlook application path and remote port 445. This requires the Filtering Platform Connection audit subcategory to be enabled.
• Microsoft Defender for Endpoint advanced hunting, if you use it. A starting point:

// Outlook making outbound SMB connections to public addresses (last 14 days)
DeviceNetworkEvents
| where Timestamp > ago(14d)
| where InitiatingProcessFileName =~ "outlook.exe"
| where RemotePort in (445, 139)
| where RemoteIPType == "Public"
| project Timestamp, DeviceName, InitiatingProcessAccountName, RemoteIP, RemotePort, RemoteUrl, ActionType
| order by Timestamp desc

Widen the window to cover the period before 10 November. The bug was exploited before the patch, so the interesting hits may be weeks old.

3. NTLM audit events

Windows can log every outgoing NTLM authentication. If you turn on only one thing this week, make it this.

• Microsoft-Windows-NTLM/Operational log. With "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers" set to Audit all, the client logs each outgoing NTLM authentication and names the target server. Microsoft says "Audit and block events are recorded on this computer in the operational event log located in Applications and Services Log\Microsoft\Windows\NTLM" (reference). Event ID 8001 records outgoing NTLM from the client, and 8002 to 8004 cover incoming NTLM on servers and domain controllers. An 8001 event naming an external host is a red flag.
• Event ID 4776 on domain controllers (credential validation). An NTLM validation for a user from a host they don't normally use can be a relay landing.
• Event ID 4624 with authentication package NTLM, package name NTLM V2 and logon type 3, on plausible relay targets. Compare the source with where the user actually was.
• Event ID 4625 bursts against one account soon after a suspicious egress event, which suggest someone is testing a cracked password.
• ProtectedUserFailures-DomainController Event ID 100, if enabled, shows an NTLM sign-in refused because the account is in Protected Users.

4. What to do with a hit

Treat a confirmed outbound NTLM authentication to an untrusted host as a credential exposure. Reset the password to a long, unique passphrase and revoke sessions. Check sign-ins and likely relay targets for that identity since the event. Find the triggering message and search for siblings by sender, subject or attachment hash. Patch the device before it goes back to the user.

Mitigations that outlast this CVE

The patch closes this gap. The measures below close the class.

Block outbound TCP 445 everywhere

Microsoft's guidance on securing SMB traffic is to block outbound SMB to the internet. Do it at the perimeter and again in the host firewall, so roaming laptops are covered. Allow only internal ranges and any approved cloud file endpoints, with explicit, logged exceptions. You can't block HTTPS, but you can stop the WebClient service where it isn't needed, which removes the WebDAV fallback.

Put privileged and high-value users in Protected Users

Protected Users members can't authenticate with NTLM to the domain, and their devices stop caching the NT one-way function. Follow Microsoft's cautions. Never add service or computer accounts. Members need AES keys for Kerberos, so old or migrated accounts may need a password reset first. Members lose offline sign-in, and their tickets last four hours. Test with a few administrators before adding whole groups, because Microsoft warns that can lock accounts out.

Audit, then restrict, outgoing NTLM

The policy "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers" (registry value RestrictSendingNTLMTraffic under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0) has three useful states:

• Allow all (the default when undefined): no restriction.
• Audit all: every outgoing NTLM request is logged, nothing is blocked.
• Deny all: outgoing NTLM is refused, except to servers in "Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication".

Microsoft's own best practice is to start with Audit all, review the operational log, build the exception list from the internal servers that still need NTLM, and then move to Deny all. The change takes effect without a restart.

On Windows 11 version 24H2 and Windows Server 2025, there's also a narrower control: the SMB client can block NTLM for outbound SMB connections, either through the "Block NTLM (LM, NTLM, NTLMv2)" policy under Lanman Workstation or with Set-SmbClientConfiguration -BlockNTLM $true, plus an exception list. Microsoft says this "prevents bad actors from tricking clients into sending NTLM requests to malicious servers" (SMB NTLM blocking). It's a strong fit for exactly this class of bug.

Require SMB signing

SMB signing ties each message to the session key, and Microsoft notes it helps "protect their deployments from relay and spoofing attacks" (SMB signing). Windows 11 version 24H2 Enterprise, Pro and Education require inbound and outbound signing, and Windows Server 2025 requires outbound signing. Older servers and many third-party storage devices don't, unless configured. Require signing on every server that hosts shares and check it with Get-SmbServerConfiguration.

Enforce EPA, LDAP signing and LDAP channel binding

Relay needs a target that accepts a forwarded NTLM login. Take those targets away.

• LDAP: enforce LDAP signing and channel binding on domain controllers, following Microsoft's LDAP signing guidance and advisory ADV190023.
• HTTP services that accept Windows authentication: turn on Extended Protection for Authentication, which binds the login to the TLS channel so a relayed login fails. Microsoft's KB5005413 gives the steps for certificate enrolment web services, where it recommends "enabling EPA and disabling HTTP".
• On-premises Exchange and other internet-facing services: prefer modern authentication, and remove NTLM from external endpoints where you can.

Move off NTLM toward Kerberos

The lasting answer is to need NTLM less. Microsoft has said its "end goal is eliminating the need to use NTLM at all" (The evolution of Windows authentication), and NTLMv1 is already removed in Windows 11 version 24H2 and Windows Server 2025 (deprecated features). Use the audit data to find what still depends on NTLM. Fix the usual causes: connections by IP address, missing service principal names, and applications that call NTLM directly instead of Negotiate. Then move each dependency to Kerberos and shrink the exception list. Every server you remove is one less relay target.

Passwords still matter

Long, unique passphrases make a captured NTLMv2 response far less useful. Pair them with phishing-resistant MFA, so a cracked password alone doesn't open the mailbox or the VPN.

Fix it without waiting for upstream

The vendor fix exists. It doesn't protect devices that haven't taken it yet, or stop the next bug in this class. Here is what a team can do today, alongside the update, without waiting on anyone.

1. Measure the gap tonight. Compare Office builds on every Windows endpoint with the table above. That list is your real exposure.
2. Force the update with a deadline for deferred rings, measured in days rather than weeks.
3. Add a host firewall rule blocking outbound TCP 445 to non-corporate addresses on every Windows endpoint. It protects remote laptops whatever their patch state.
4. Turn on outgoing NTLM auditing fleet-wide. Audit all blocks nothing, and within a day it shows where NTLM goes.
5. Move your most exposed people into Protected Users this week, after a short test.
6. Stop the WebClient service where it isn't needed.
7. Require SMB signing and EPA on the relay targets you already know.
8. Hunt backwards over the weeks before 10 November, and reset any credential that went somewhere it shouldn't.
9. Tell users to report unexpected message files and Office attachments instead of opening them.
10. Check your own code for the same pattern. If your software opens a path or URL taken from untrusted input on Windows, it can trigger the same automatic NTLM authentication. Make it reject remote locations, or warn, before any connection is made.

None of these steps depends on Microsoft, and all of them outlast this CVE.

Part two: the Microsoft 365 outage of 12 and 13 November 2026

This is a separate event. Microsoft says it was not a cyberattack, and nothing links it to CVE-2026-124194.

What happened

On Thursday 12 November, users began losing access to their Exchange Online mailboxes. Microsoft's Exchange Online incident EX1550543 records mailbox connection failures beginning at 16:17 UTC, or 11:17 a.m. Eastern, according to BankInfoSecurity's reporting of Microsoft's Exchange portal. Impact widened through the early afternoon Eastern time. BleepingComputer reports that the broader incident MO1550821 began at 1:26 p.m. ET. In that incident, Microsoft warned that customers may be unable to connect to Exchange Online, Microsoft Teams, SharePoint Online, Microsoft 365 Copilot and Microsoft Defender XDR. CNBC puts the start of widespread connectivity problems shortly before 1 p.m. ET, and Al Jazeera reports users in 74 countries and territories on Downdetector within about an hour.

Microsoft first reported problems in the Americas, then said users in any region could be affected. Outlook was hit hardest. Teams was partly disrupted, with chats and calls largely continuing, per Al Jazeera.

What Microsoft has said about the cause so far

Microsoft has not published a root cause. It said it "will share a full Post-Incident Report with root cause and defense-in-depth actions after mitigation is complete" (SecurityWeek). What it has described so far is the shape of the failure, not its origin:

• A number of servers became "unexpectedly unavailable", which strained the remaining infrastructure. Microsoft said "the elevated load isn't driven by an increase in traffic" (BleepingComputer).
• Affected servers were failing automated health checks. Microsoft said it had "validated an alternative service health check method" that brought some servers back (CNBC).
• A process that establishes secure connections on the affected servers became overwhelmed, and Microsoft began rolling back a recent network configuration change that coincided with the start of the disruption (SecurityWeek). Microsoft has not said that this change caused the outage.
• Microsoft paused deployments, redistributed traffic and restarted servers (CNBC).

Until the Post-Incident Report is out, any specific cause you read elsewhere is speculation. We'll update this post when it's published.

Microsoft says it was not an attack

Charles Lamanna, a Microsoft executive vice president, wrote that "there is no indication this is the result of malicious or cyber activity" (Al Jazeera). Microsoft's status page on Friday read: "At this time, we have no evidence of malicious activity associated with this incident" (SecurityWeek).

It's tempting to connect a big outage with a zero-day disclosed two days earlier. There is no evidence for it.

Recovery on 13 November

Recovery was slow. Al Jazeera reported "marginal success" more than 12 hours in, with some restored servers failing again. By Friday morning, CNBC reported "encouraging recovery progress in Europe" and said Microsoft had extended the email timeout window to 48 hours so delayed messages wouldn't bounce. At 11:55 UTC on 13 November, Microsoft's public service status page said that recovery efforts were "progressing" and that Microsoft was "continuing to pursue multiple workstreams to pinpoint the source of the issue."

Who felt it

• Courts. Alberta Courts in Canada warned that the public, counsel and parties "may experience delays or difficulties when communicating with the Court" (Yahoo News UK). Al Jazeera reported disrupted communications at the Supreme Court of the Philippines.
• Banks. Maybank in Malaysia told customers that "email communications may experience delays at this time" and advised them "to remain vigilant against scams" (Yahoo News UK). BankInfoSecurity reported banks, hospitals, courts and schools among those disrupted.
• Healthcare and business. CNBC reported some UK National Health Service services affected, Richemont's earnings slightly delayed and Air India temporarily rerouting email.
• Identity side effects. BankInfoSecurity reported disrupted password resets, account creation and some MFA and SSO sign-ins that rely on email. Most continuity plans miss this one.

Concentration risk: when one cloud runs the working day

For many organisations, one productivity cloud carries email, chat, meetings, files, calendars, the AI assistant and often the security console. When it has a bad day, they all go together. That isn't an argument against cloud email. It's an argument for knowing what depends on it. We've covered vendor concentration risk and how regulators treat ICT third-party concentration before. This outage is a live example.

Look for hidden dependencies. Password resets, MFA recovery codes and vendor sign-in links often arrive by email. Approval workflows wait for an email reply. Incident bridges, on-call alerts and runbooks often live only in Teams or SharePoint. And if your investigation console runs on the same cloud, you lose it at the worst moment: Microsoft listed Defender XDR among the services customers might be unable to reach.

Continuity: a plan that works when mail doesn't

Keep the plan short, store it outside the affected cloud, and practise it.

• A second channel. Agree in advance on one channel that doesn't depend on the primary cloud, such as a separate chat tool, a phone bridge or SMS alerting. Keep an offline contact list for leadership, IT, security, legal and communications, and decide who speaks to staff, customers and regulators. Banks used their own websites and social channels to say email might be delayed, which is the right pattern.
• Status monitoring that doesn't depend on the thing that broke. Watch Microsoft's public service status page, the admin center's service health dashboard and the Microsoft 365 Status account on X, and track the incident IDs (here EX1550543 and MO1550821). Pull service health into your own monitoring programmatically, and run synthetic sign-in and send-and-receive checks from outside your network.
• Keeping work moving. Know whether inbound mail will bounce. Microsoft extended its timeout to 48 hours this time, so check what your own gateway does when the cloud is unreachable. Cached mail and synced files buy time. Write down the manual path for approvals and regulated communications.
• Afterwards. Read the Post-Incident Report, record the real business impact, and update your dependency map with whatever surprised you.

Outage noise or attack? How to tell, and the phishing that follows

Every large outage is followed by attackers using it as bait. Maybank warned its customers about scams during this one. Here's how to keep the two apart.

Signs it's the provider. The problem hits many unrelated organisations at once, matches the provider's status page and moves with its updates. Users get timeouts and server errors. Your sign-in logs show service-side failures, not successful sign-ins from unfamiliar places, and your audit logs show no changes you didn't make.

Signs something else is going on. Problems confined to your tenant or a few users while the status page is green. Mail flow rules, app consents or privileged role assignments you can't account for. Users reporting credential prompts that came from an email link instead of the app. Keep watching for these during a genuine outage too, because attackers know defenders are distracted.

Outage-themed phishing to brief users on:

• Fake restoration notices: "Your mailbox has been restored, sign in again to recover delayed messages."
• Fake delayed-message alerts that lead to a credential form.
• Fake help desk calls or chats that ask for an MFA code or a password reset "to fix the outage".
• Fake compensation offers tied to the disruption.

The rules for users are short. Don't sign in from links in messages about the outage. Open the app yourself. Nobody from IT will ask for your MFA code. For the service desk, tighten identity checks on password and MFA resets during and after the outage, because that's where social engineering lands.

How Safeguard helps with this class of problem

Microsoft fixes Outlook itself, through the Office updates described above. Safeguard's part is to help teams find and fix the same kinds of weakness in the software they build and run, and move faster on remediation when a known-exploited vulnerability appears. Here is how its generally available capabilities map to the lessons of this week.

Finding this class of flaw in your own code. The core of CVE-2026-124194 is an application that reaches out to an untrusted location without warning the user and hands over a credential in the process. The same pattern shows up in in-house software as server-side request forgery, unsafe handling of user-supplied file paths and URLs, and missing confirmation before risky actions. Safeguard's first-party SAST and DAST test your code and running applications for these weaknesses. Zero-Day Discovery looks for previously unknown vulnerabilities in your own code and open-source dependencies, in an agentic mode or a deterministic scanner mode that also runs with no AI in the loop.

Proving what matters and fixing it. Griffin AI analyses reachability, so teams can see whether a vulnerable path can actually be triggered, and it opens policy-gated fix pull requests, with your own CI running the tests before anyone merges. Autonomous remediation is configurable by category, so you choose what's automatic and what waits for review.

KEV-aware vulnerability monitoring across SBOMs. Safeguard generates and ingests SBOMs (SPDX and CycloneDX) and enriches vulnerabilities with EPSS and CISA KEV data. When a component in an SBOM you track becomes known-exploited, it rises in priority instead of sitting in a list of a thousand. Through TPRM, you can request SBOMs from your suppliers, so third-party software you depend on gets the same treatment.

Policies and gates. You can write organisation-wide policies, including from plain-English prompts, and enforce them as gates at build, CI and release. One example is a rule that no release ships with a known-exploited component.

Asset discovery. You can't fix what you don't know you run. Asset discovery inventories your software assets and applies guardrails and enforcement to what it finds.

Guard runtime guardrails. One lesson of NTLM leaks is that unexpected egress is a signal. Guard, Safeguard's runtime protection, enforces guardrails you define inside your running applications, so an unexpected outbound connection from a service is something your runtime policy can flag.

Continuity for security alerts. Safeguard sends notifications to Slack, Microsoft Teams, Google Chat and Discord, and opens tickets in Jira, Linear, Asana, Notion and Microsoft Planner. If your primary collaboration suite is down, route critical security alerts to a second channel so they still reach someone.

You can see the platform at https://safeguard.sh.

Other notable breaches and exploited vulnerabilities this month

Other November 2026 items with reputable sources. KEV dates come from the CISA KEV catalog.

• OpenSSH "SSHole", CVE-2026-123158. An authentication bypass on certain musl-based Linux systems, including Alpine. OpenSSH 10.6p2 fixed it on 5 November, exploitation began within hours of a public proof of concept, and it entered KEV on 9 November (BleepingComputer, OpenSSH). Update, or disable password authentication, and check authorized_keys files.
• Barracuda Email Security Gateway, CVE-2026-116606 and CVE-2026-111560. An authentication bypass chained with a root command injection. Barracuda confirmed exploitation against "a small number of organizations" on 9 November, and both entered KEV on 10 November (BleepingComputer, Barracuda).
• Chrome zero-day, CVE-2026-125350. A use-after-free in Chromium's XML component. Google "is aware that an exploit for CVE-2026-125350 exists in the wild" (Chrome Releases). It entered KEV on 10 November and affects other Chromium-based browsers and embedded runtimes.
• WordPress core, CVE-2026-119977. An upgrade-window race condition that can allow unauthenticated code execution, in KEV since 3 November (WordPress 7.1.4).
• SonicWall SonicOS SSLVPN, CVE-2026-19868. A weakness that can bypass SAML-enforced MFA, in KEV since 6 November (SonicWall PSIRT).
• Hijacked GitHub accounts stealing CI secrets. From about 10 November, credentials for 4,837 GitHub accounts were used to plant a secret stealer that ran in at least 1,806 repositories, targeting Actions secrets, OIDC tokens and cloud credentials (The Hacker News).
• Chainstack. Disclosed 3 November: an intruder reached production through a third-party component and accessed a customer database including password hashes (The Hacker News).
• Apify. Confirmed 12 November: one compromised credential led to access to customer data (SecurityWeek).
• Maersk. Confirmed a breach of a local system inherited through the LF Logistics acquisition, and said "no sensitive data has been disclosed". The extortion group's claims are unverified (BleepingComputer).

Two threads run through the list. Identity is the target, whether that's a hash, a token or an SSH key. And the time from fix to exploitation keeps shrinking, sometimes to hours.

FAQ

What is CVE-2026-124194?

It's an actively exploited spoofing vulnerability in Microsoft Outlook, patched on 10 November 2026. If a user opens a specially crafted message file, Outlook can connect to an attacker-controlled network location without showing its external-content warning, which discloses the user's NTLMv2 hash. Microsoft rates it Moderate, with a CVSS 3.1 base score of 6.5.

Is CVE-2026-124194 being exploited?

Yes. Microsoft marked it "Exploitation Detected" at release, and CISA added it to KEV on 10 November 2026. Microsoft has not named an attacker or published indicators of compromise. The Preview Pane is not an attack vector: the user has to open the crafted file.

Which products are affected, and how do I fix it?

Microsoft lists Microsoft 365 Apps for Enterprise (32-bit and 64-bit), Office LTSC 2024 and Office LTSC 2021. The fix comes through Office updates, not Windows updates. Install the 10 November 2026 build for your channel, for example Current Channel build 20527.20196, Office LTSC 2024 build 17932.21140 and Office LTSC 2021 build 14334.21048, then restart Outlook.

What can an attacker do with an NTLMv2 hash?

Crack it offline to recover a weak password, or relay it in real time to a service that accepts NTLM without signing or channel binding.

What are the most effective mitigations besides patching?

Block outbound TCP 445 at the perimeter and on every host, put privileged users in Protected Users, audit then restrict outgoing NTLM (RestrictSendingNTLMTraffic), require SMB signing, enforce EPA and LDAP channel binding, and move services to Kerberos.

Which event IDs should I hunt for?

NTLM/Operational Event ID 8001 (outgoing NTLM), Security Event IDs 4776, 4624 (NTLM, logon type 3) and 4625, Sysmon Event IDs 3 and 22 for OUTLOOK.EXE, and Filtering Platform Event ID 5156 for port 445.

Was the Microsoft 365 outage a cyberattack, or related to the zero-day?

No to both. Microsoft said "there is no indication this is the result of malicious or cyber activity", and nothing published by Microsoft or credible outlets links the outage to CVE-2026-124194.

What caused the Microsoft 365 outage?

Microsoft hasn't published a root cause yet. It has described servers becoming unavailable and failing health checks, and it rolled back a recent network change without saying that change was the cause. A Post-Incident Report will follow mitigation.

How do I avoid outage-themed phishing?

Never sign in from a link in a message about the outage. Check status through official channels, and treat any request for an MFA code or password as an attack.

Did Safeguard detect CVE-2026-124194 before it was patched?

No. Microsoft disclosed and patched it. Safeguard helps teams find and fix this class of weakness in their own code and dependencies, prioritise known-exploited vulnerabilities and enforce release gates.

Sources

Primary sources: MSRC CVE-2026-124194, CISA KEV catalog, NVD, Microsoft 365 Apps security updates, Microsoft service status. Microsoft guidance on NTLM, Protected Users, SMB signing, SMB NTLM blocking, LDAP channel binding and EPA is linked inline in each section. Outage reporting: BleepingComputer, CNBC, Al Jazeera, SecurityWeek and BankInfoSecurity. Roundup sources are linked in each entry.