Title: Why CVE-2026-20955 is Called “Remote Code Execution” Even Though CVSS Says AV:L (Local)
Executive summary — short answer
- The phrasing “Remote Code Execution” in the CVE title describes the origin of the attack (an attacker who is remote from the victim can deliver the exploit), not necessarily the technical CVSS Attack Vector value. Microsoft’s advisory language explicitly calls this out: “The word Remote in the title refers to the location of the attacker … The attack itself is carried out locally.”
- CVSS’s Attack Vector metric (AV) measures where the vulnerable code must run (network-bound vs. local process) and how the exploit must be triggered; document-parsing RCEs that require a user to open a malicious file are typically scored AV:L even though the malicious file can be delivered remotely (email, web link, cloud share). The CVSS specification and user guide explain this distinction and why such cases are AV:L.
Why the label “Remote Code Execution” appears in vendor advisories
- Vendors (including Microsoft) use “remote” as a plain-English descriptor: an attacker can be remote (sitting anywhere on the Internet) when they send the malicious document or file to the victim. The title is intended for a broad audience and highlights that the attacker's origin need not be physically near the victim. Microsoft repeats this explanation in multiple advisories and FAQs about Office and other products.
- In operational communications (security bulletins, press summaries) “remote code execution” signals the potentially severe impact (arbitrary code execution on the target host) and the fact that attackers can reach victims by remote delivery mechanisms (phishing, malware-laden downloads, cloud-shared documents). That is useful shorthand for non-technical readers, but it is not the same thing as the CVSS Attack Vector metric.
What CVSS Attack Vector (AV) actually measures
- CVSS AV reflects how close the attacker needs to be (logical/physical proximity) to the vulnerable code at the time of exploitation. The canonical CVSS definitions (v3.1 / v4.0) make an important distinction:
- AV:N (Network) — vulnerable code is bound to a network protocol and can be triggered remotely over a network connection.
- AV:A (Adjacent) — requires presence on a local network segment or logically adjacent domain.
- AV:L (Local) — the vulnerable component is not network‑bound; exploitation relies on read/write/execute mechanisms, local access, or user interaction (for example, a user opening a malicious file).
- Because CVSS is focused on the technical conditions required to exploit a specific bug, document-parsing RCEs that require the victim to open a file are normally assessed as Local (AV:L), even if the malicious document was delivered remotely (e‑mail, web, cloud link). The CVSS user guide explicitly states: “a document parsing vulnerability … should typically be scored with the Local value, regardless of the method used to distribute such a malicious document.”
Concrete example (how a document-based RCE maps to AV:L)
- Typical chain:
- Attacker crafts a malicious Office/Excel file that exploits a parser bug.
- Attacker delivers that file remotely (phishing email, file share link, cloud collaboration).
- A user on the target system opens the file (or the system’s preview mechanism parses it), and the vulnerable code executes inside the local process (Excel) on the victim’s machine.
- Step (2) is remote delivery; step (3) requires the vulnerable code to run on the local host. CVSS AV is about step (3) — where the vulnerable code must run — hence AV:L. FIRST’s CVSS examples include many document RCEs scored as AV:L for precisely this reason.
Why this distinction matters operationally (and why AV:L does not imply “low priority”)
- It’s easy to misread “Local” as “low risk.” That’s dangerous. Document-based RCEs are frequently weaponized and widely exploited because:
- Office/Excel are ubiquitous; many endpoints are potential victims.
- Remote delivery via email, file sharing, or web pages is trivial and scalable.
- Social-engineering (phishing) reliably persuades victims to open files.
- Preview/thumbnailing services and server-side parsers (mail gateways, web preview services, Office Online/SharePoint renderers) can sometimes cause the vulnerable code to run without the user explicitly opening a file, increasing exposure.
- Because of these factors, vendors and defenders treat document RCEs as high-priority fixes even when CVSS lists AV:L. Microsoft’s advisories and many post‑patch analyses emphasize rapid patching and layered mitigations for these vulnerabilities.
When does a document RCE become AV:N (Network)?
- If the exact same vulnerable parsing code is accessible over the network (for example, a server component or web preview service invokes that parser on behalf of remote clients), the Attack Vector should be Network (AV:N), because remote attackers can directly trigger the vulnerable code without relying on a user to open a file on a desktop host. CVSS guidance and vendor advisories note this operational exception and call it out when applicable. Inventorying where parsing happens (desktop Excel vs. server-side preview services) matters for accurate scoring and for prioritization.
Practical guidance for defenders (what to do now)
- Treat RCE advisories seriously, regardless of AV:L:
- Prioritize applying the vendor security update for the affected Office/Excel builds as soon as possible.
- Verify that patches are deployed to endpoints and to servers that process Office documents (Office Online Server, SharePoint, mail gateways that perform attachment rendering).
- Layered mitigations to reduce exposure:
- Protected View and Safe Documents: ensure Protected View is enabled for files from the Internet, and consider Safe Documents / Defender Application Guard for Office where available (these sandbox or block editing until cloud scans complete). These settings reduce the chance that a malicious document will execute code in the user’s process.
- Defender Application Guard / containerization: where licensed and available, Application Guard isolates untrusted files in a restricted container; if that’s not available, keep Protected View enabled.
- Email gateway and sandboxing: scan and sandbox attachments at the gateway (including blocking or detaching active content where practical).
- Disable or limit automatic previewing / thumbnailing on servers or gateways that parse/convert Office files, or ensure those services are patched and isolated.
- Principle of least privilege: limit user privileges, restrict macros and script execution, and enforce macro signing policies.
- Endpoint detection and response (EDR): hunt for indicators of exploitation (sudden child processes from Excel, command-line activity immediately after an Office process spawns cmd/powershell, unusual network connections from desktop hosts).
- Operational checklist for administrators:
- Identify which endpoints and server services run the vulnerable parser (Excel on endpoints, Office Online Server, Exchange/transport agents, cloud file-preview services).
- Patch all affected components promptly (endpoints and servers).
- Confirm Protected View / Safe Documents policies are configured per your risk tolerance and license level.
- Harden mail and web gateway settings (detonate attachments, disable unsafe previewing).
- Run threat hunts and watchlists for common exploitation patterns (Office process spawning shells, unusual outbound connections, suspicious child processes).
How to explain this to non-technical stakeholders
- Short plain-English: “The CVE title ‘Remote Code Execution’ means a distant attacker can deliver a malicious file to your users (for example by email). The CVSS ‘Local’ rating means the bug executes inside the user’s Excel program on the local machine when the file is opened. Practically, that means attackers can reach victims from afar but exploitation requires the malicious file to be run locally — so patching + user caution + document isolation are the keys.”
Quick FAQ
- Q: Does AV:L mean I can ignore the patch because attackers need physical access?
A: No. AV:L means the vulnerable code runs locally; attackers commonly deliver malicious files remotely (phishing, web downloads). Treat document RCEs as high-priority.
- Q: Could a remote attacker exploit this without user action?
A: Generally not on a plain desktop client — user interaction (open file, or a preview rendering) is required for AV:L cases. But if a network service on your infrastructure invokes the vulnerable parser (mail previews, online document renderers), the vector may become Network (AV:N), increasing exposure. Inventory server-side parsers.
- Q: Which Microsoft features reduce risk?
A: Protected View, Safe Documents, and Defender Application Guard for Office; plus email attachment scanning / sandboxing and standard EDR controls. Ensure these are configured and up to date.
Closing recommendation (concise)
- Assume an attacker can deliver the exploit remotely but that exploitation will occur in a local process on the victim host (AV:L). Prioritize the published security update, enable document isolation features (Protected View / Safe Documents / Application Guard), harden gateway previewing, and run targeted detection for Office-based exploitation activity. These steps together close the practical paths attackers use for document-based RCEs.
If you want, I can:
- Pull the exact wording from Microsoft’s CVE advisory for CVE-2026-20955 and quote the FAQ lines used in the short answer; or
- Produce a short one‑page executive summary (2–3 bullets) you can share with managers that explains the AV:L vs “Remote” wording and recommended actions.
Which would you prefer?
Source: MSRC
Security Update Guide - Microsoft Security Response Center