CVE-2026-20950 Explained: Remote Code Execution vs CVSS AV:L in Office Documents

Title: Why CVE-2026-20950 is labeled “Remote Code Execution” even though CVSS lists AV:L (Local) — a practical guide for Windows admins
Introduction

• Short answer: “Remote” in the CVE title describes the attacker’s location (they can be off‑host and deliver a malicious file remotely); the CVSS Attack Vector (AV:L) describes where the vulnerable code runs when the exploit triggers (inside the local Excel process). Both statements are true and answer different questions. For Office document parsing flaws the delivery can be remote while the triggering/compromise happens locally. This is the reason you commonly see RCE in advisory titles while CVSS shows AV:L.

This article explains:

• What CVSS Attack Vector actually measures and why AV:L is correct for many Excel/Office RCEs.
• Why vendors say “Remote Code Execution” in headlines.
• How the exploit chain looks in real deployments (remote delivery → local execution).
• When the CVSS vector should be Network (AV:N) instead of Local.
• Practical mitigation and prioritization guidance for Windows sysadmins and defenders.

1) What the CVSS Attack Vector (AV) measures — the formal definition
CVSS’s Attack Vector metric is explicitly about where the vulnerable component is executed at the moment exploitation occurs — not about how the attacker first reaches the victim or what social engineering is used to get a user to open a file. The metric ranks attack vectors by how “remote” the attacker can be (Network, Adjacent, Local, Physical). The CVSS specification and user guide make this clear and give specific guidance: document‑parsing vulnerabilities that trigger in a locally running application should normally be scored AV:L even if the malicious document arrives over email or the web. In short: CVSS scores where the vulnerable code runs; not the geographical location of the attacker. Practical meaning:

• AV:N (Network) — the vulnerable component is network‑accessible (e.g., a service listening on a socket) and can be exploited across network hops.
• AV:L (Local) — exploitation requires the vulnerable component to be invoked locally (for example by opening a file in a local application).
  So when you see CVSS:3.1/AV:L/… that means “the vulnerability is not in a network service; it requires local parsing/execution to trigger.”

2) What the CVE/advisory title means by “Remote Code Execution”
When a vendor (Microsoft, NVD, or security media) writes “Microsoft Excel Remote Code Execution Vulnerability,” they use operational language to tell defenders what an attacker can accomplish: an attacker, operating remotely (i.e., off the victim machine), can cause arbitrary code to run on a target machine if they can get the target to open a crafted file or otherwise trigger the parser. The title emphasizes the outcome (RCE) and the attacker’s origin (remote), which are critical triage factors for defenders. This phrasing is concise and purpose‑driven — it tells you that an attacker located off the victim host has a plausible path to achieve code execution on the victim. 3) The common Excel/Office attack chain — how “remote delivery” becomes “local execution”
Most modern Office RCEs have the same chain of events:

• Attacker crafts a malicious document (XLSX/XLSB, embedded OLE, ActiveX, specially formed legacy binary record, etc. that targets a memory‑safety bug in Excel’s native parsers.
• Attacker delivers the file remotely — via spearphishing email, a shared cloud link, public download, or other remote channels.
• Victim receives and opens the file (or an automated preview component renders it); Excel runs its native parser inside the local process.
• The parser encounters the crafted data, triggers memory corruption (use‑after‑free, buffer overflow, uninitialized resource, etc. and the attacker’s payload executes inside the victim’s Excel process under the user’s privileges.

Delivery is remote; the vulnerable code executes locally inside Excel. That is why the headline says “Remote Code Execution” (attacker’s origin/outcome) while CVSS shows AV:L (the exploit mechanics inside the target). 4) Why CVSS intentionally treats document parsing bugs as Local
The CVSS authors updated guidance for v3.x to avoid classifying document delivery channels as “network” in the Attack Vector metric. If the vulnerable component itself is not a network service (for example, Excel’s file parser runs inside the desktop application), then CVSS instructs scorers to assign AV:L even when the file is distributed remotely. This preserves consistent scoring across vulnerability types and prevents “double counting” a remote delivery mechanism when the affected component itself is not network‑bound. 5) Important operational exception — when AV should be Network (AV:N)
There is a critical exception: if server‑side components or network‑accessible services parse the same content, the vulnerable code executes in a network‑facing process and the Attack Vector must be Network (AV:N). Examples:

• An email gateway or DLP server that renders or inspects attachments using the affected parser.
• Office Online Server, SharePoint thumbnail/preview generation, or other collaboration platforms that render Office documents on servers.
• Any cloud service that accepts a file over the network and parses/renders it in a server process using the same vulnerable code.

If your environment has servers or gateways that parse Office files on behalf of users, those servers can be exploited remotely without user interaction on the endpoint; in that case the correct CVSS AV becomes Network and the exposure is materially higher. Microsoft and other advisories explicitly note this exception when applicable. Administrators must therefore map where parsing occurs in their environment (desktop Excel vs. server preview/rendering) and prioritize patching accordingly. 6) Examples & clarifications (realistic scenarios)

• Scenario A (AV:L situation — headline “RCE” still accurate)
• A phishing email arrives with a malicious Excel attachment. A user double‑clicks it and opens Excel; the local parser is triggered and code runs on the user’s machine. Outcome: remote attacker caused code execution on a target. CVSS AV: Local because the vulnerable code executed inside a local application.
• Scenario B (AV:N situation — server parsing)
• A company’s mail gateway automatically scans attachments by rendering them in a server‑side engine that uses the vulnerable Excel parser. An attacker uploads a crafted document to an Internet‑accessible service that passes it to the mail gateway; the gateway’s parser crashes and is exploited. Outcome: attacker can trigger the vulnerable code remotely against that server — CVSS AV: Network.
• Scenario C (preview pane nuance)
• Some advisories explicitly confirm whether the Outlook preview pane or similar features can trigger the vulnerability (some do, some don’t). Vendors will call this out; if the preview/thumbnailer uses the same vulnerable parser, it can become an effective attack vector. For many Excel CVEs Microsoft has clarified whether Preview Pane is an attack vector in their update guidance.

7) Why this matters for defenders — triage and prioritization implications

• Headline “RCE” means: if exploited, arbitrary code can run with user privileges — patch fast.
• CVSS AV:L means: exploitation requires user interaction or local parsing — but this does not make it low priority; RCE with user interaction still gives attackers significant capability and is commonly exploited in the wild via socially engineered emails. Many Microsoft Excel RCEs have high impact scores (C/I/A = High) even with AV:L.

However, if you operate servers or gateways that parse Office files (Office Online, SharePoint preview, mail gateways, cloud services), treat those hosts as higher priority because the attack vector may effectively be Network for those components. In other words: know where the vulnerable code runs in your environment and prioritize based on real exposure. 8) Practical mitigation checklist for sysadmins (immediate to medium term)
Apply patches

• Apply the vendor security updates for all affected Office/Excel builds as soon as feasible. Vendor patches fix the vulnerable code path. Microsoft’s update guide and security update catalogs are the authoritative patch sources.

Reduce exposure while you patch

• Disable or restrict preview/thumbnail rendering on mail servers/gateways if they use the vulnerable parser (or ensure the gateway vendor has applied mitigations/patches).
• Configure mail gateways to block or sandbox suspicious attachments; use attachment emulation/sandboxing to render risky files in isolated environments.
• Turn on Protected View in Office (it’s designed to open files from untrusted locations in a hardened, limited mode).
• Disable automatic opening of attachments in email platforms and train users not to double‑click attachments from unknown senders.

Harden endpoints

• Use application control (AppLocker, Windows Defender Application Control) to limit what code can run in user profiles.
• Ensure endpoint detection and response (EDR) solutions are tuned to detect post‑exploit behaviors typical of Office RCE (suspicious child processes spawned by Excel, shell activity originating from Office processes, memory probing, etc..
• Keep Windows and Defender signatures up to date.

Defend server infrastructure

• If Office/SharePoint/Office Online Server or gateway products parse Office files, patch those servers early — these hosts may be directly reachable and thus effectively network‑exploitable.
• If you use cloud collaboration services, check vendor statements about whether they were impacted and whether the provider has mitigated.

Operational controls & monitoring

• Block common file types in email if you can (or apply additional scanning).
• Use data loss prevention (DLP) and sandboxing to inspect high‑risk attachments.
• Monitor for indicators of compromise (IOC) listed in vendor advisories and threat intelligence feeds.

9) Messaging to non‑technical stakeholders — how to explain the discrepancy

• “The alert says ‘Remote Code Execution’ because an attacker on the internet could remotely get code to run on your desktop if a user opens a crafted file. The technical score calls it ‘Local’ because the bug is in a desktop parser and the code executes inside the local application when the file is opened. Both statements are correct — they just answer different questions.” Use this phrasing for concise executive communications.

10) Quick FAQs
Q: Does AV:L mean I don’t need to worry?
A: No. AV:L only describes the vulnerable component’s execution context. Many AV:L Excel vulnerabilities still allow attackers to achieve full user‑level compromise via socially engineered file delivery; they are often exploited in the wild. Patch quickly and follow the mitigation checklist. Q: When would this CVE become a real “network” problem?
A: If you have servers or services that parse Office files for users (email gateways that render attachments, Office Online Server, SharePoint preview handlers), those hosts run the vulnerable parser in a network‑accessible process — exposure becomes network‑level and risk increases. Map parsing locations in your environment and patch those servers early. Q: Does Protected View stop these exploits?
A: Protected View raises the bar by sandboxing untrusted files, but it may not stop every data‑only parsing exploit. It is an important defense in depth but not a substitute for patching and other mitigations. 11) Sources and further reading (selected)

• CVSS v3.1 specification and guidance (explains Attack Vector semantics and why document parsing bugs are scored Local).
• Windows security advisory threads and practical writeups that explain the delivery vs execution distinction in Office RCEs.
• Microsoft Security Response Center (MSRC) vulnerability/update guide entries for Excel CVEs (vendor guidance, affected products, update packages).
• Technical coverage and mitigation guidance from security vendors and news outlets for Office RCEs.

Conclusion — two complementary truths

• The CVE title highlights the attacker’s ability to cause code execution from a remote location — a critical operational fact for defenders.
• The CVSS Attack Vector documents where the vulnerable code runs when exploited — a technical detail intended to standardize scoring.

Understanding the difference matters because it changes your operational priorities: a high‑impact RCE with AV:L is still a serious risk for desktops (phishing + user action), and becomes an even greater organizational risk if any of your server‑side components parse the same content (making the vector Network). Map where parsing happens; patch all affected endpoints and servers; apply layered mitigations while you patch.
If you want, I can:

• Pull the exact MSRC advisory text for CVE‑2026‑20950 and extract the vendor’s “Is the Preview Pane an attack vector?” guidance and the list of affected builds for your environment (Office 2016/2019/365/Office LTSC etc. so you can create a prioritized patch plan.

(End of article)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center