Microsoft’s CVE listing for CVE-2026-20948 names the issue as a
Remote Code Execution (RCE) vulnerability in Microsoft Word, but its published CVSS vector lists the Attack Vector as
AV:L (Local) — a mismatch that confuses many administrators and risk managers. The two labels are not contradictory; they answer different operational questions. The CVE title signals the
attacker’s origin and impact (an off‑host adversary can cause arbitrary code to run on a victim), while the CVSS Attack Vector documents the
mechanics of exploitation at the moment the vulnerable code is invoked (the vulnerable parser executes inside a local process when a user opens or previews a file). This distinction — commonly summarized as “remote delivery, local execution” — is intentional and important for accurate triage and remediation.
Background / Overview
Microsoft’s Security Update Guide and the CVE headline use the phrase
Remote Code Execution because it succinctly communicates impact: a remote attacker can cause arbitrary code to execute on a target host if the exploit chain completes. That phrasing deliberately prioritizes clarity and urgency. At the same time, CVSS (the Common Vulnerability Scoring System) applies a standardized taxonomy to describe
how the vulnerability must be triggered; when the exploitable code runs only inside a locally executed application (for example, WINWORD.EXE parsing a document), CVSS correctly uses
AV:L (Local) even though the crafted document may have been delivered across the internet. The CVSS goal is consistent, mechanistic scoring — it intentionally
does not “double‑count” remote delivery channels when the vulnerable code itself is invoked locally.
Understanding this pair of signals together — CVE headline + CVSS vector — gives defenders the full operational picture: high impact if the chain succeeds (RCE), and the exact exploitation constraints (user interaction required, vulnerable component runs in a local process), which inform detection and mitigation choices.
CVSS Attack Vector: What AV:L really means
CVSS asks a different question than the CVE headline
The CVSS Attack Vector metric answers:
Where must the vulnerable code be executed when exploitation occurs? It classifies that location using four values: Network (AV:N), Adjacent (AV:A), Local (AV:L), and Physical (AV
). If the buggy code is a network service, AV:N is appropriate. If the buggy code is a local parser invoked only when a user opens a file, the proper score is AV:L — even when that file was obtained via an email attachment, cloud storage link, or web download. This is explicit in the CVSS guidance and the FIRST user guide.
Why CVSS avoids “double counting” the delivery step
If CVSS scored every remotely delivered exploit as AV:N, regardless of where the vulnerable code actually executes, scores would be inflated and inconsistent across different classes of vulnerabilities. CVSS deliberately separates delivery (how the malicious data arrives) from the trigger (where the vulnerable code runs), producing repeatable and comparable scoring across heterogeneous products and architectures. For document‑parsing vulnerabilities, the
trigger — not the
delivery — is the determiner of AV.
Why Microsoft (and many vendors) use “Remote Code Execution” in advisories
Vendors use the phrase
Remote Code Execution because it is a concise, high‑signal way to tell IT and security teams what an attacker can ultimately achieve (arbitrary code execution) and from where they can initiate the attack (off‑host). In practical terms, if an adversary can craft a file, deliver it across common channels, and cause a victim to open or preview it such that code runs on the victim’s machine, the end state is functionally identical to a “remote” compromise even if an in‑process parser was the immediate trigger. Microsoft’s Security Update Guide examples repeatedly show this pattern: the headline emphasizes impact while the advisory body and CVSS vector describe the actual conditions required to exploit. This wording trade‑off is operationally useful: security teams scanning dozens or hundreds of CVE titles need a fast, clear indicator of potential impact. However, headline brevity also generates the specific confusion we’re addressing — so reading the advisory body and CVSS vector together is essential.
Technical anatomy: “Remote delivery, local execution” explained
Typical attack chain for a Word document RCE
- Attacker crafts a malicious Word document (or embeds a malformed object inside a document) that targets a memory‑safety or logic bug in Word’s native parser.
- Attacker distributes that file through a remote channel — email attachment, cloud share link, or download.
- Victim opens or previews the document in Microsoft Word or a preview handler; the local Word process parses the crafted bytes.
- The parsing triggers memory corruption or a logic error and attacker‑controlled code executes in the local Word process context, achieving arbitrary code execution.
Why parsers are the frequent Achilles’ heel
Office applications contain complex, legacy‑compatible native parsers for binary formats, embedded OLE objects, images, fonts, and more. Those native code paths are often written in languages without automatic memory safety and have historically been a source of exploitable vulnerabilities (use‑after‑free, heap/stack overflow, type confusion). When attackers can fully control input bytes in a file, they can craft primitives that lead to reliable code execution
inside the process that reads the data. That in‑process execution is what CVSS records as AV:L.
User interaction and preview handlers
Most Office document RCE advisories also include the CVSS User Interaction metric (UI:R) — exploitation requires that a user open or preview the malicious file. However, preview handlers or thumbnailing engines that automatically render documents (in mail clients, file managers, or web gateways) can effectively lower that human barrier if they invoke the same local parser without user intent. When such server‑side or network‑facing components parse uploaded content, the attack vector can shift from AV:L to AV:N — the key exception discussed below.
The critical exception: when Local becomes Network
If a network‑exposed component (mail gateway, document conversion service, Office Online Server, CMS preview engine, cloud storage preview) calls the same vulnerable parser on behalf of remote clients, the parser runs in a network‑accessible process. In that configuration the exploit can be triggered remotely, without a user opening a file on an endpoint, and the correct CVSS Attack Vector should be
AV:N (Network). Microsoft and other vendors explicitly call this out when it applies because it materially increases exposure and urgency. Organizations must inventory any servers and services that perform document parsing or previewing and prioritize patching those assets.
Operational implications: how to read the headline and act
- The CVE title “Remote Code Execution” is a high‑signal alert about potential impact — treat it as urgent.
- The CVSS vector (AV:L + UI:R, for example) tells you how the vulnerability is exploited — focus mitigations accordingly (endpoint controls, Protected View, user education).
- Don’t deprioritize AV:L RCEs. Document‑based RCEs are frequently weaponized via phishing, shared links, and cloud collaboration; distribution is trivial at scale.
Prioritization guidance:
- Patch servers and services that perform server‑side parsing (mail gateways, SharePoint, Office Online Server) first — these can convert an AV:L issue into AV:N.
- Roll out client patches broadly and quickly.
- Harden email ingestion: disable automatic previews where possible and apply sandboxing / detonation for suspicious attachments.
- Enforce Office mitigations: Protected View, Application Guard, and macro restrictions.
Detection, hunting, and containment — practical playbook
Detection priorities focus on the moment after local code execution, because the exploit trigger occurs inside a benign process (winword.exe). Recommended signals to monitor:
- EDR/telemetry: Office processes spawning unusual child processes immediately after document open (powershell.exe, cmd.exe, mshta.exe, regsvr32.exe, rundll32.exe).
- Network telemetry: sudden outbound connections initiated by Office binaries.
- Process injection patterns: anomalous memory modifications inside winword.exe or other Office binaries.
- Mail gateway logs: spikes in deliveries of document attachments with suspicious metadata or high quarantine rates.
Hunting queries and alerts to implement quickly:
- Alert on process creation events where parent process is WINWORD.EXE and child is a shell or scripting host.
- Search for Office processes that load unexpected DLLs or create remote threads in other processes.
- Review quarantined/sandboxed files for exploitation indicators (malformed structures, unusual embedded objects).
Containment steps if you detect exploitation:
- Isolate the host from the network.
- Preserve volatile forensic artifacts (memory dump, process lists, network captures).
- Block accounts and rotate credentials if credential theft is suspected.
- Patch and validate the vulnerable builds across your estate.
Mitigation checklist (prioritized)
- Apply vendor patches immediately for all affected Office SKUs (endpoint and server components). Patch is the authoritative fix.
- Harden document ingestion:
- Disable or quarantine automatic previews in mail clients and web apps.
- Route attachments through a sandbox/detonation platform before delivery.
- Enforce Office security features:
- Protected View for files from the internet.
- Block macros by default and require explicit enablement only for trusted documents.
- Use Application Control (AppLocker, WDAC) to restrict unexpected child processes spawned by Office.
- Reduce privileges:
- Ensure users operate with the least privilege necessary — standard user accounts for daily work.
- Detection & response:
- Implement EDR rules to detect Office processes spawning scripting hosts or performing suspicious network activity.
- Hunt email gateway logs and quarantined artifacts for weaponized documents.
Risk analysis: strengths and pitfalls of the labeling approach
Strengths
- The RCE headline provides a fast, operational triage signal that draws attention to high‑impact issues.
- CVSS provides standardized, mechanistic context that enables consistent automated risk scoring and comparison across many vulnerabilities.
Risks and common misinterpretations
- Treating AV:L as “low priority” is dangerous. Document parsing RCEs are often weaponized using trivial delivery channels and social engineering; the practical risk remains high.
- Automated triage systems that only ingest CVE titles may misclassify exposure (network vs local) and misprioritize patching.
- Server‑side blind spots: organizations that don’t inventory preview/convert services may miss network‑exposed parsers that change the attack vector to AV:N.
Verifiability and caveats
- The CVSS classification (AV:L + UI:R etc. and vendor advisory language are authoritative for mapping affected builds and required mitigations; always use the vendor’s Security Update Guide as the primary source for KB mappings and patch files.
- At the time of initial disclosure, low‑level exploit details (exact memory primitives, PoC code, exploit reliability) are often withheld or unavailable; any detailed exploitation claims that aren’t corroborated by multiple independent technical analyses should be treated cautiously. If public proofs or in‑the‑wild exploitation are reported later, re‑assess priority and detection rules immediately.
Short FAQ (practical answers)
- Why does a “Remote Code Execution” CVE have AV:L?
- Because the vulnerable code that gets exploited runs in a local process when a file is parsed; CVSS records the locus of the trigger (AV:L) while the CVE headline indicates the attacker can deliver the exploit remotely and achieve RCE if the victim triggers the condition.
- Does AV:L make the vulnerability low risk?
- No. AV:L only refers to where the vulnerable code executes. Distribution and social engineering can make exploitation easy and widespread; treat document‑parsing RCEs as high priority for patching and mitigation.
- When should I treat the vector as Network (AV:N) instead?
- If a network‑accessible service parses uploaded files using the same vulnerable component (mail gateway previews, Office Online Server, cloud preview engines), the attack vector should be scored as AV:N because exploitation can occur without a local user opening the file. Prioritize patching these services.
Conclusion
The headline “Remote Code Execution” and the CVSS Attack Vector value
AV:L are complementary, not contradictory. The CVE title warns that an off‑host adversary can cause arbitrary code to run on a victim system — a concise, high‑impact triage signal. The CVSS Attack Vector specifies that the
actual vulnerable code executes locally (for example, when Word parses a crafted document), which is essential for precise risk scoring and mitigation planning. Together these messages give defenders both the urgency (RCE) and the practical mechanics (AV:L, UI:R, affected components) needed to decide what to patch, how to harden ingestion and preview surfaces, and where to focus detection and response efforts. Treat AV:L RCEs seriously, prioritize patches across endpoints and server‑side parsing services, and implement layered controls (sandboxing, Protected View, application control, EDR rules) to reduce exposure while you roll out fixes.
Source: MSRC
Security Update Guide - Microsoft Security Response Center