CVE-2026-70571 · Microsoft Exchange Server Content-Conversion Stack Buffer Overflow RCE

01 · The Real Story

Someone can knock out your mail fortress by dropping a poisoned letter in the mailbox slot

CVE-2026-70571 is a stack-based buffer overflow (CWE-121) in Microsoft Exchange Server's internal content-conversion pipeline. An unauthenticated attacker triggers it by sending a specially crafted email to any vulnerable Exchange server — no credentials, no user click, no prior access required. When Exchange processes the message through its content-conversion routines, the malformed data overflows a stack buffer and hands the attacker SYSTEM-level code execution on the mail server itself. Affected versions span the entire on-premises Exchange fleet: Exchange 2016 CU23 (builds < 15.1.2507.77), Exchange 2019 CU14 (< 15.2.1544.50), Exchange 2019 CU15 (< 15.2.1748.55), and Exchange Server Subscription Edition RTM (< 15.2.2562.56). Microsoft patched it on October 13, 2026, and this is the final security update Exchange 2016 and 2019 will ever receive.

Microsoft rates this HIGH at CVSS 8.1 base and labels it *Critical* in their own severity taxonomy, with an exploitability assessment of Exploitation More Likely. The CVSS vector's AC:H reflects that exploitation requires deep environmental knowledge and success is not guaranteed — ZDI called the practical barrier 'substantially high.' That friction is real, but it does not change what this bug *is*: a pre-auth, zero-click, email-deliverable RCE on infrastructure that holds every corporate email, often runs with Exchange Org Admin privileges in Active Directory, and sits on the MX record facing the entire internet. The vendor score of 8.1 underweights the blast radius. History is unambiguous — ProxyLogon, ProxyShell, and ProxyNotShell all started with similar friction assessments and were weaponized within weeks. We upgrade to CRITICAL.

"Unauthenticated wormable Exchange RCE via email — upgrade to CRITICAL despite AC:H friction."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Attacker identifies target Exchange server

The attacker resolves the target organization's MX records via public DNS, which directly expose the Exchange server's hostname or IP. No scanning or probing is needed — MX records are public by design. Alternatively, Shodan and Censys indexes show approximately 116,000 internet-facing Exchange servers globally as of late 2026.

Conditions required:

Target runs on-premises Exchange (2016 CU23, 2019 CU14/CU15, or SE RTM)
Exchange server is reachable via SMTP (port 25/587/443)

Where this breaks in practice:

Organizations that have fully migrated to Exchange Online are not affected
Some orgs front Exchange with a cloud email gateway (Mimecast, Proofpoint, Microsoft 365 Defender) that may filter or re-encode messages before relay

Detection/coverage: Shodan/Censys dork: http.title:"Outlook Web App" or ssl.cert.subject.CN:mail.*. Qualys QID and Tenable plugin expected within days of patch release.

STEP 02

Craft and deliver malicious email

The attacker constructs a specially crafted email whose body or attachment contains a payload designed to trigger the stack-based buffer overflow in Exchange's content-conversion subsystem. The email is delivered via standard SMTP — no authentication, no user interaction. The attacker simply sends the message to any valid mailbox on the target server. The content-conversion engine processes inbound mail automatically as part of the transport pipeline.

Conditions required:

Knowledge of a valid recipient address (any address at the target domain)
Ability to craft a payload that triggers the CWE-121 overflow in content conversion

Where this breaks in practice:

AC:H — Microsoft states exploitation requires 'deep understanding of the target environment' and is not guaranteed to succeed
No public PoC or exploit code exists as of October 15, 2026
Stack buffer overflows on modern Windows require bypassing DEP, ASLR, and CFG mitigations
Email security gateways may strip or quarantine malformed MIME structures before they reach Exchange

Detection/coverage: Snort 2 rules 1:67210–1:67273 and Snort 3 rules 1:301663–1:301694 released by Talos for this CVE. IDS/IPS at the SMTP layer can detect known payload patterns.

STEP 03

Content-conversion triggers buffer overflow

When Exchange's transport agent invokes the content-conversion pipeline (e.g., converting between TNEF, RTF, HTML, or plain text), the malformed input overflows a stack buffer. If the attacker's payload is precisely constructed for the target's Exchange build, memory layout, and language configuration, control flow is hijacked. The overflow executes attacker-supplied shellcode in the context of the Exchange transport service, which runs as NT AUTHORITY\SYSTEM.

Conditions required:

Payload must match target Exchange build, architecture, and locale-specific memory layout
Content-conversion must process the specific message format containing the overflow trigger

Where this breaks in practice:

Stack canaries, DEP, ASLR, and CFG on Windows Server 2016/2019/2022/2025 make reliable exploitation materially harder
Different CU levels and language packs shift memory layouts, requiring per-target tuning
Exchange's content-conversion has been hardened after years of similar bugs

Detection/coverage: Windows Defender Exploit Guard / Attack Surface Reduction rules may detect anomalous stack pivots. EDR agents monitoring EdgeTransport.exe and MSExchangeTransport.exe for child process spawning or shellcode injection patterns.

STEP 04

SYSTEM-level code execution on Exchange

With code execution as SYSTEM on the Exchange server, the attacker can read all mailboxes, extract credentials from memory (via Mimikatz or similar), access the Exchange Management Shell, and pivot into Active Directory. Exchange servers in hybrid or on-premises environments often hold the Exchange Trusted Subsystem and Exchange Windows Permissions groups, which have WriteDACL on the domain root — a well-documented path to Domain Admin.

Conditions required:

Successful exploitation of the buffer overflow in step 3

Where this breaks in practice:

EDR/XDR on Exchange servers should detect post-exploitation behaviors (credential dumping, lateral movement, web shell deployment)
Network segmentation between Exchange and domain controllers can slow lateral movement

Detection/coverage: Monitor for: w3wp.exe or EdgeTransport.exe spawning cmd.exe/powershell.exe, unexpected .aspx files in Exchange virtual directories, LSASS access from Exchange processes, anomalous LDAP modifications from the Exchange machine account.

STEP 05

Worm propagation (theoretical)

ZDI flagged this as theoretically wormable. Once executing as SYSTEM on one Exchange server, the attacker can harvest the Global Address List, enumerate other Exchange servers in the organization (via Get-ExchangeServer), and send the same crafted email to them — or to partner organizations' Exchange servers via SMTP. Each compromised server becomes a new launch point. This mirrors the ProxyLogon mass-exploitation pattern from 2021.

Conditions required:

Multiple unpatched Exchange servers in the organization or across SMTP-connected organizations
Exploit reliability sufficient for automated propagation

Where this breaks in practice:

AC:H makes automated worm propagation unreliable without per-target tuning
Modern email security stacks would likely quarantine or flag mass-mailed identical payloads
Most large enterprises have migrated to Exchange Online, reducing the wormable surface

Detection/coverage: Volume-based anomaly detection on outbound SMTP from Exchange servers. Monitor for Exchange sending mail to its own transport pipeline or to unusual external MX destinations at scale.

03 · Compensating Control

CRITICAL 9.0→IGNORE 0.0

SEVERITY REDUCED

Apply the October 2026 security update immediately — Install KB5128898 (Exchange 2016 CU23), KB5128897 (2019 CU14), KB5128896 (2019 CU15), or KB5128895 (SE RTM) within 3 days per the noisgate mitigation SLA for CRITICAL. This is the only complete remediation. For Exchange 2016/2019, this is the final patch ever — there is no second chance.

CRITICAL 9.0→HIGH 7.5

SEVERITY REDUCED

Deploy Snort/Suricata IDS rules at the SMTP gateway — Enable Talos Snort 2 SIDs 1:67210–1:67273 or Snort 3 SIDs 1:301663–1:301694 on your network IDS/IPS inline on the SMTP path to Exchange. This can detect and block known payload patterns before they reach content conversion. Deploy within 3 days. However, this is signature-based and can be evaded with payload mutations.

CRITICAL 9.0→HIGH 7.0

SEVERITY REDUCED

Route inbound mail through a cloud email security gateway — If not already in place, front Exchange with a cloud email gateway (Microsoft Defender for Office 365, Proofpoint, Mimecast, Abnormal Security) that re-encodes or sanitizes MIME structures before relaying to on-premises Exchange. This may strip or neutralize the malformed content that triggers the overflow. Deploy or verify within 3 days.

CRITICAL 9.0→HIGH 7.5

SEVERITY REDUCED

Enable Windows Defender Exploit Guard on Exchange servers — Configure Exploit Protection policies (DEP always-on, mandatory ASLR, CFG strict mode, stack randomization) for EdgeTransport.exe, MSExchangeTransport.exe, and related Exchange worker processes. This raises the bar for reliable exploitation of the stack buffer overflow. Deploy within 3 days.

CRITICAL 9.0→HIGH 8.0

SEVERITY REDUCED

Monitor Exchange transport processes for anomalous child process creation — Create EDR/XDR detection rules alerting on EdgeTransport.exe, MSExchangeTransport.exe, or w3wp.exe spawning cmd.exe, powershell.exe, certutil.exe, or writing .aspx files to IIS virtual directories. This does not prevent exploitation but ensures rapid detection of post-exploitation activity. Deploy within 3 days.

What doesn't work

Restricting OWA/ECP access via firewall does not help — the attack vector is SMTP (port 25), not HTTPS. The content-conversion pipeline is triggered by inbound email delivery, not web access.
Disabling Exchange ActiveSync or MAPI/HTTP does not help — the vulnerability is in the transport pipeline's content conversion, not in client access protocols.
Applying Extended Security Updates (ESU) enrollment alone does not help — ESU is a licensing mechanism, not a patch. You must still install the actual KB update.
Network segmentation between Exchange and DCs slows lateral movement but does not prevent the initial RCE — the attacker still gains SYSTEM on the Exchange server and access to all mailboxes.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	Not observed. Not listed in CISA KEV. Microsoft rates it Exploitation More Likely but has not confirmed active exploitation as of October 15, 2026.
Proof-of-Concept	No public PoC. Checked pocindex.io, GitHub (no repos named CVE-2026-70571), ExploitDB, and Metasploit — no exploit code available. The SecureWithUmer/CVE-2026-PoCs and asvorg/CVE-2026-PoCs community collections do not include this CVE.
EPSS	0.00927 (0.93%) — approximately 85th percentile. Elevated above median but not in the top tier. Reflects the AC:H constraint and absence of public exploit code.
CVSS Vector	`CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H` — Base 8.1 / Temporal 7.1 (E:U/RL:O/RC:C). Network-accessible, unauthenticated, zero-click. The only downward pressure in the base score is AC:H (conditions beyond the attacker's control). All impact metrics are HIGH.
Affected Versions	Exchange 2016 CU23 (< 15.1.2507.77), Exchange 2019 CU14 (< 15.2.1544.50), Exchange 2019 CU15 (< 15.2.1748.55), Exchange SE RTM (< 15.2.2562.56)
Fixed Versions	Exchange 2016 CU23: KB5128898 (build 15.1.2507.77) · Exchange 2019 CU14: KB5128897 (15.2.1544.50) · Exchange 2019 CU15: KB5128896 (15.2.1748.55) · Exchange SE RTM SU11: KB5128895 (15.2.2562.56)
Internet Exposure	Shodan indexes ~116,000 internet-facing Exchange servers globally (US: ~22,700, DE: ~18,100, CN: ~17,000). A prior Exchange CVE (CVE-2026-62911) found 21,899 servers still unpatched weeks after disclosure — indicating slow patch adoption persists.
End-of-Life Warning	This is the final security update for Exchange 2016 and Exchange 2019. No further patches will be issued, even under ESU Period 2. Unpatched servers will remain permanently vulnerable.
Disclosure & Credit	Disclosed October 13, 2026 via Microsoft Patch Tuesday. Researcher/reporter not publicly credited in MSRC advisory.
IDS Coverage	Cisco Talos released Snort 2 rules (SIDs 1:67210–1:67273) and Snort 3 rules (SIDs 1:301663–1:301694) covering this CVE.

Sources.

05 · The Call

Final Verdict

↑ UPGRADED to CRITICAL (9.0/10)

Why this verdict

Pre-auth zero-click via email delivery: The attack requires only sending an email to the target — no credentials, no user interaction, no prior access. SMTP delivery to an MX endpoint is trivially achievable by any adversary on the internet. AC:H does not gate *reachability*, only *reliability* of the overflow itself.
Role multiplier — Exchange is canonically high-value (100% of installs): Every Exchange server IS the organization's mail infrastructure by definition. Compromise yields access to every mailbox, every attachment, every credential cached in LSASS. Exchange machine accounts typically hold WriteDACL on the domain root via Exchange Windows Permissions — a documented path to Domain Admin. This is not 'when deployed in role X'; this IS the role. The blast radius is domain-scale to fleet-scale.
Wormable characteristics amplify blast radius beyond single-org: ZDI flagged wormable properties. A compromised Exchange server can harvest the GAL, enumerate peer Exchange servers, and relay the payload via SMTP to other organizations. This is the ProxyLogon pattern with a self-propagation vector. Even if reliability is low per-target, the addressable surface (~116K servers) means statistical exploitation at scale.
Historical precedent demands respect: ProxyLogon (CVE-2021-26855) was AC:L but took the industry by surprise. ProxyShell, ProxyNotShell — every major Exchange RCE has been weaponized, typically within 2-4 weeks of disclosure. AC:H has not historically prevented Exchange exploitation once motivated actors invest in payload development.
Final patch for 2016/2019 creates permanent exposure: Organizations still running Exchange 2016 or 2019 that miss this patch window will *never* receive a fix. The 21,899 servers found unpatched for CVE-2026-62911 weeks post-disclosure suggest a large residual population will remain vulnerable indefinitely.
AC:H friction acknowledged but insufficient to break the CRITICAL floor: The CVSS AC:H is meaningful — exploitation requires target-specific environmental knowledge, ASLR/DEP/CFG bypass, and locale-aware payload tuning. No public PoC exists. EPSS is 0.93%. These factors prevent a score of 10.0 but do not change the deployment-role floor: Exchange is in the high-value-role catalog by analogy to network edge appliances and identity infrastructure, and ≥10% of installs (effectively 100%) occupy that role.

Why not higher?

The reassessed score of 9.0 is already CRITICAL, the highest severity bucket. It is not scored at 10.0 because the AC:H constraint is genuine — Microsoft and ZDI both confirm exploitation requires deep environmental knowledge, success is not guaranteed, and no public exploit code demonstrates reliable exploitation. The absence of active exploitation or a working PoC means the *current* threat is potential rather than realized.

Why not lower?

HIGH (the vendor's own rating) underweights the deployment context. Every Exchange server is, by definition, a crown-jewel asset holding all corporate email with elevated AD privileges. The attack vector — sending an email — is the most trivially deliverable payload mechanism in existence; AC:H constrains *reliability*, not *reachability*. The wormable property, the ~116K internet-facing servers, and the historical pattern of rapid Exchange weaponization all compound upward. Downgrading to HIGH would require evidence that the content-conversion code path is not reachable via standard SMTP delivery, or that <1% of Exchange installs are internet-facing — neither is true.

06 · Verification

Crowdsourced verification payload.

Run this script on each Exchange server as a local administrator. It checks the installed Exchange build number against the patched builds for each CU level. Invoke: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-70571.ps1

noisgate-verify.ps1

POWERSHELLREAD-ONLYSAFE

#Requires -RunAsAdministrator
<#
.SYNOPSIS
    Checks whether the local Exchange Server is patched against CVE-2026-70571.
.DESCRIPTION
    Compares installed Exchange build number against fixed builds:
      Exchange 2016 CU23: 15.1.2507.77 (KB5128898)
      Exchange 2019 CU14: 15.2.1544.50 (KB5128897)
      Exchange 2019 CU15: 15.2.1748.55 (KB5128896)
      Exchange SE RTM:    15.2.2562.56 (KB5128895)
    Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
#>

$ErrorActionPreference = 'Stop'

try {
    $exchangePath = Join-Path $env:ExchangeInstallPath 'bin\ExSetup.exe'
    if (-not (Test-Path $exchangePath)) {
        $exchangePath = Get-ItemPropertyValue -Path 'HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Setup' -Name 'MsiInstallPath' -ErrorAction SilentlyContinue
        if ($exchangePath) { $exchangePath = Join-Path $exchangePath 'bin\ExSetup.exe' }
    }

    if (-not $exchangePath -or -not (Test-Path $exchangePath)) {
        Write-Host 'UNKNOWN - Exchange Server not detected on this host.'
        exit 2
    }

    $fileVersion = (Get-Item $exchangePath).VersionInfo.FileVersion
    $currentBuild = [version]$fileVersion
    Write-Host "Detected Exchange build: $fileVersion"

    # Define patched builds per product line
    $patchedBuilds = @{
        # Exchange 2016 CU23 (15.1.x)
        '15.1' = @{ Label = 'Exchange 2016 CU23'; Fixed = [version]'15.1.2507.77'; KB = 'KB5128898' }
        # Exchange 2019 CU14 (15.2.1544.x)
        '15.2.1544' = @{ Label = 'Exchange 2019 CU14'; Fixed = [version]'15.2.1544.50'; KB = 'KB5128897' }
        # Exchange 2019 CU15 (15.2.1748.x)
        '15.2.1748' = @{ Label = 'Exchange 2019 CU15'; Fixed = [version]'15.2.1748.55'; KB = 'KB5128896' }
        # Exchange SE RTM (15.2.2562.x)
        '15.2.2562' = @{ Label = 'Exchange SE RTM'; Fixed = [version]'15.2.2562.56'; KB = 'KB5128895' }
    }

    $matched = $false
    # Try most specific match first
    $prefixes = @("$($currentBuild.Major).$($currentBuild.Minor).$($currentBuild.Build)", "$($currentBuild.Major).$($currentBuild.Minor)")
    foreach ($prefix in $prefixes) {
        if ($patchedBuilds.ContainsKey($prefix)) {
            $info = $patchedBuilds[$prefix]
            $matched = $true
            Write-Host "Product: $($info.Label)"
            Write-Host "Fixed build: $($info.Fixed) ($($info.KB))"
            if ($currentBuild -ge $info.Fixed) {
                Write-Host "PATCHED - CVE-2026-70571 is remediated."
                exit 0
            } else {
                Write-Host "VULNERABLE - Current build $fileVersion is below fixed build $($info.Fixed). Apply $($info.KB) immediately."
                exit 1
            }
        }
    }

    if (-not $matched) {
        Write-Host "UNKNOWN - Exchange build $fileVersion does not match known affected CU levels."
        exit 2
    }
} catch {
    Write-Host "UNKNOWN - Error during check: $_"
    exit 2
}