CVE-2026-20952 and CVE-2026-20953 Two Critical Remote Code Execution Vulnerabilities in Microsoft Office

CVE-2026-20952 and CVE-2026-20953 are critical remote code execution (RCE) vulnerabilities affecting Office. Both vulnerabilities carry a CVSS v3.1 score of 8.4 (Critical) and stem from use-after-free memory corruption flaws within Microsoft Office components.

These vulnerabilities can be exploited by unauthenticated attackers to execute arbitrary code in the context of the targeted user. In the worst-case scenario, no user interaction is required. Exploitation can occur through specially crafted malicious emails or links, with the Preview Pane serving as a viable attack vector.

In the most severe attack scenario, an attacker could send a specially crafted email that triggers the vulnerability without requiring the victim to open the email or click any links, resulting in immediate remote code execution on the victim’s system.

Successful exploitation could allow attackers to:

  • Execute arbitrary code
  • Install malware
  • Access or exfiltrate sensitive data
  • Establish persistence on affected systems
FieldCVE-2026-20952CVE-2026-20953
Short nameMS Office RCE (use-after-free)MS Office RCE (use-after-free)
CVE IDCVE-2026-20952CVE-2026-20953
CVSS v3.1 base score (vendor)8.4 (Critical)8.4 (Critical)
Severity (vendor)CriticalCritical
Exploitability (quick)Can be triggered by specially crafted Office content; Preview Pane is an attack vector; may require no user interaction in worst case.Same: specially crafted Office content; Preview Pane attack vector; may require no user interaction in worst case.
Public exploit / PoC availabilityNo public PoC reported (as of Jan 17, 2026).No public PoC reported (as of Jan 17, 2026). (industry trackers list no public exploit yet).
Typical attack deliveryMalicious e-mail with crafted attachment/embedded content, malicious link, or any mechanism that causes the Office engine to parse untrusted content (Preview Pane, file explorer previews, direct open).
Affected contextUser’s account context (code executes as the logged-on user) — full system compromise possible if user is admin.User’s account context (code executes as the logged-on user) — full system compromise possible if user is admin.
  • Both CVEs are use-after-free bugs inside Microsoft Office components. At a high level: a piece of code frees (releases) a chunk of memory but later still assumes that memory is valid and tries to use it. An attacker can craft input that causes the program to later use that freed memory in a way that gives the attacker control over program flow. That control can become arbitrary code execution.
  • Because Office reads and renders many file formats and embedded objects, a malicious file or message can carry specially crafted data that triggers the use-after-free when Office parses it. In practice that means an attacker can weaponize a Word, Excel, RTF or other Office-compatible payload and deliver it by email, web link or even through preview handlers. Multiple industry writeups and Microsoft’s advisory call out the Outlook Preview Pane specifically as a vector — in other words, the victim may not need to double-click or “open” a file for the buggy code to run.
  • The exploitability is rated high (CVSS 8.4). The CVSS vector Microsoft provided includes User Interaction = None in the worst case, which is why this is high-priority for enterprises.

MITRE ATT&CK / CWE mapping

  • CWE: CWE-416 — Use After Free.
  • ATT&CK techniques (likely):
    • T1204 (User Execution) — only for variants that require opening a file.
    • T1190 / T1203 (Exploit Public-Facing Application / Exploit) — in cases where Office or related services accept remote content.
    • Post-compromise techniques depend on payloads — e.g., T1059 (Command and Scripting Interpreter), T1105 (Ingress Tool Transfer). (Mapping is contextual; use after free itself is the initial exploitation primitive.)

PoC / exploit availability

  • As of Jan 17, 2026 there are multiple vendor and research trackers listing these CVEs as patched in Microsoft’s January 13, 2026 release and no public proof-of-concept (PoC) or confirmed active exploitation has been widely observed. Industry trackers and patch summaries state no public exploit code is available yet. That does not mean exploit code won’t appear quickly — memory-corruption RCEs that have a convenient vector (email preview) are often weaponized rapidly.

How an attacker could realistically exploit this

  1. Create a malicious Office document (or crafted object) that corrupts memory in the specific parsing path targeted by the bug.
  2. Deliver it to a target by email, or publish it behind a link. Because Outlook’s Preview Pane or other preview handlers can parse the file automatically, the attacker can rely on the recipient’s mail client to parse the malicious content without the recipient clicking anything.
  3. When the target’s Outlook/Office process parses the crafted content, the use-after-free triggers and — if properly exploited — the attacker gets code execution in the user context. From there they can drop a payload, contact a command-and-control server, or move laterally.
  4. If the user has administrative rights, the attacker can escalate and persist. If not, they can still run malware in the user’s context. (Typical RCE post-exploitation patterns apply.)

Detection guidance — what to look for (payload signs & logs to monitor)

Below are practical detection ideas you can implement quickly in EDR/SIEM and email gateways. These are detective signatures and heuristics — they won’t block exploitation; they help you notice likely attempts.

High-value log sources

  • Email gateway / mail transfer logs (EOP, Exchange transport): track messages with suspicious attachments, anomalous senders, or messages with attachments that contain OLE objects, RTF/embedded HTML with unusual streams.
  • Mail client logs & Outlook process telemetry: process creation and child processes spawned from outlook.exe (e.g., outlook.exe → winword.exe / excel.exe / cmd.exe / powershell.exe).
  • Endpoint EDR / Sysmon (process create, network connect): Sysmon EventID 1 (Process Create), EventID 3 (Network connection), EventID 7/8 (Image loaded) — watch for scripts or cmd/powershell spawned by Office processes.
  • Windows Event Logs (Application, Security): Office application crashes (AppCrash / Event ID 1000) that correlate with an incoming message can indicate attempted exploitation.
  • Network IDS/Proxy logs: HTTP(s) or attachments that contain known exploit kit patterns or unusual file types delivered via webmail or links.

Practical detection rules & example queries

(Use these as starting points; tune to environment noise.)

Splunk (example) — detect Office process spawning suspicious children

index=wineventlog EventCode=1 
| where ParentImage LIKE "%OUTLOOK.EXE%" OR ParentImage LIKE "%WINWORD.EXE%" 
| where Image IN ("C:\\Windows\\System32\\cmd.exe","C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe")
| table _time, Host, User, ParentImage, Image, CommandLine

Elastic/SIEM (example) — detect Office crash after receiving email

event.dataset: "windows.event_logs" and event.code: 1000
and process.name: ("OUTLOOK.EXE" OR "WINWORD.EXE" OR "EXCEL.EXE")
| join email_gateway_logs by host (look for recent inbound mail with attachment)

EDR rule idea (behavioral):

  • Alert if outlook.exe or winword.exe spawns a shell or a network-connected child process within 30s of a process crash or an inbound mail event. This is high-fidelity — Office rarely launches shells legitimately.

Network/IDS signature idea (Suricata-like heuristic):

  • Flag Office document attachments carrying embedded OLE streams with unusually long or repetitive NOP sled strings, or attachments with executable content inside zipped Office packages. (These are heuristics — tune to avoid false positives.)

YARA-like heuristic (for mail gateway / sandbox)

A simple conceptual YARA to flag Office files with odd embedded streams — example only; test before production use.

rule suspect_office_embedded_exe {
  meta:
    description = "Detect Office packages containing suspicious embedded executable-like content"
  strings:
    $ole = "PK\\x03\\x04"        // OOXML zipped doc marker
    $exe_magic = "\\x4D\\x5A"    // "MZ" exe header
  condition:
    $ole and $exe_magic
}

(Again: test and refine — many false positives possible; combine with other telemetry.)


Indicators of Compromise (IoCs) & payload signs to watch for

  • Emails where the attachment is .doc, .docx, .rtf, .xls, .xlsx or odd file types with embedded OLE objects from unknown senders.
  • Outbound network traffic from winword.exe, excel.exe, or outlook.exe to uncommon endpoints immediately after opening or previewing mail.
  • Unexpected process tree: Outlook → child process that performs network I/O or writes executables.
  • Application crash events for Office processes tied to mail receipt time.

Recommended detection rules

  1. EDR: Block or alert on Office apps spawning command interpreters (cmd/powershell/wscript) — high priority.
  2. SIEM: Correlate inbound mail with an Office attachment + subsequent Office crash or process spawn. Raise medium/high.
  3. Mail gateway: Flag and quarantine messages with Office attachments containing OLE streams or macros — if your gateway can sandbox attachments, run them in sandbox and look for Office process spawning or network callbacks.
  4. Network: Watch outbound connections from Office processes; block known bad endpoints.
  5. Harden: Disable Preview Pane in Outlook for high-risk user groups (temporary mitigation if immediate patching isn’t possible). (This is a practical mitigation many orgs use when preview-based CVEs appear.)

Mitigation & immediate steps

  1. Patch immediately — install Microsoft’s Jan 13, 2026 Office updates (links below). This is the primary and recommended fix.
  2. Consider temporary configuration changes until you patch: disable Outlook Preview Pane and disable automatic download/preview of external content in mail clients for high-risk groups. (Preview Pane is explicitly called out as a vector by vendors.)
  3. Harden EDR rules to block Office processes from spawning shells or networked payloads unless explicitly allowed.
  4. Harden mail gateway to sandbox or block inbound emails with unexpected Office embedded objects; increase scrutiny for attachments from external senders.
  5. Monitor the detection rules above and review any Office crashes or odd process trees.