RCE vs CVSS AV: Why Remote Code Execution Headlines and Local AV Still Urgent

Short answer (TL;DR)

• The CVE title says "Remote Code Execution" because a remote attacker can deliver a malicious Word file and cause code to run on the victim machine (attacker origin / impact).
• The CVSS Attack Vector = Local (AV:L) because the vulnerable code actually executes inside a local process (e.g., WINWORD.EXE) when the user opens or previews the file; CVSS records where the exploit is triggered, not how the malicious data was delivered.
• Both statements are correct and complementary: the headline describes attacker capability and impact; the CVSS AV describes the technical exploitation locality and scoring rules. Treat the CVE as high‑priority even when AV:L.

Full explanation — a practical, defender‑oriented feature article
Why this question keeps showing up
Security teams, automated triage pipelines and managers often read a CVE headline quickly and then look at the CVSS vector. When the headline says Remote Code Execution but CVSS shows AV:L (Local), it looks contradictory — and that confusion can cause the wrong operational response (e.g., “AV:L must be less urgent” or “the vendor made a mistake”). The reality is simpler: the two pieces of text answer different questions. One is a short impact/attacker‑origin label; the other is a standardized, mechanistic scoring metric. Understanding that difference is crucial to triage, prioritization, and mitigation.
1) Two different lenses: what the CVE title tells you versus what CVSS AV tells you

• CVE/advisory title (“Remote Code Execution”) — short, operational signal
• Purpose: tell defenders the worst practical outcome and the attacker’s reach: “a remote actor can cause arbitrary code to run on the target host.” This is a high‑signal label used for triage and urgency. Vendors choose it because it communicates impact quickly to non‑technical stakeholders and operations teams.
• CVSS Attack Vector (AV) — formal, mechanistic metric
• Purpose: record the locality of the vulnerable component at the moment the exploit triggers. CVSS has four AV values (Network, Adjacent, Local, Physical). If exploitation happens when a local application parses a file on disk, the correct AV is Local (AV:L), even if the file was delivered over the network. CVSS intentionally avoids “double‑counting” network delivery.

Put another way: the title answers “what can an attacker ultimately do and from where can they start?” CVSS AV answers “where must the vulnerable code run when the exploit occurs?” Both are valid and describe two parts of the same attack chain.
2) The canonical attack chain for document-based RCEs (how remote delivery becomes local execution)
A common Word/Office document RCE looks like:

• Attacker crafts a malicious Word document that abuses a parser bug (use‑after‑free, heap overflow, type confusion, etc..
• Attacker distributes the file remotely: phishing email, cloud share link, file download or collaboration attachment.
• Victim opens (or previews) the file in the local Word process; Word’s native parser reads the crafted bytes.
• The parsing triggers the memory/logical bug and attacker‑controlled code runs inside the local Word process (arbitrary code execution).

Delivery is remote; the moment of exploitation is local. The CVE headline captures the fact that a remote actor can cause code to execute on a victim host; the CVSS AV records that the vulnerable parser executes locally when opened. This pattern is so common that the CVSS Guidance explicitly calls it out: if one component receives malicious data over a network and then a separate local component parses it, that second component’s exploitation locality should be scored AV:L.
3) Why CVSS treats delivery and trigger separately (and why that’s useful)

• Consistency and comparability: CVSS needs to compare thousands of vulnerabilities across many product types. If it “counted” every network delivery path as AV:N the scores would be inconsistent and inflate exploitability in ways that don’t reflect the vulnerable component’s actual exposure. So CVSS separates delivery (how data got to disk/network) from exploitation locality (where the bad code executes).
• Avoiding double counting: network delivery + local parsing is a two‑step chain; CVSS puts the scoring on the step where the vulnerable code runs. That preserves consistent, repeatable scoring rules across industries.

4) The important exception: when “Remote” really means Network (AV:N)
There is an important and practical exception: server‑side parsing or preview services. If any network‑accessible service (mail gateway that renders attachment previews, document‑conversion service, Office Online Server, cloud preview engine, CMS that generates thumbnails, etc. uses the SAME vulnerable parser on behalf of remote clients, the vulnerable code runs in a network‑exposed process and the attack vector should be Network (AV:N). That materially increases exposure because a remote, unauthenticated attacker could trigger the vulnerability without a user opening a file on a workstation. Vendors explicitly call this out when it happens.
5) Practical implications for defenders (how to read and act)

• Don’t treat AV:L as “low priority.” Document‑parsing RCEs are commonly weaponized rapidly because distribution (email, cloud links) and social engineering are easy. Even though CVSS AV:L signals local triggering, the overall risk can still be high.
• Read the whole advisory and the CVSS vector together:
• If AV:L + UI:R (User Interaction), focus on endpoint controls and user hardening (Protected View, mail sandboxing, user awareness).
• If vendor explicitly calls out server‑side rendering or an enterprise gateway that parses files, treat the vector as effectively network‑accessible and prioritize perimeter/servers.
• Immediate mitigations you can apply today (prioritized)
• Patch promptly — deploy the vendor’s updates for affected Office builds (patch is the definitive fix).
• Mail / file ingestion hardening — enable sandboxing/detonation for attachments, disable or quarantine automatic previews, block risky file types or attachments from untrusted sources.
• Enforce Protected View and Office Application Guard where supported; block or limit Office from launching child processes (AppLocker/WDAC/ASR).
• Least privilege — ensure users run non‑admin accounts for daily work; reduce blast radius.
• Detection & hunting — add EDR rules for Office processes spawning suspicious child processes, abnormal memory injection, or network connections right after document open.

6) A short FAQ (practical answers to common follow‑ups)
Q: “So is the vendor wrong to call it Remote Code Execution?”
A: No. The vendor is describing the threat actor’s origin and the impact: an attacker off the victim host can deliver a file that leads to code execution. That statement is correct and important for triage. CVSS AV is a different, formalized metric and is also correct for the exploitation locality. Both are complementary.
Q: “If the attacker can deliver the file remotely, shouldn’t CVSS use AV:N?”
A: Only when the vulnerable parser actually executes in a network‑reachable process. If the vulnerable code only runs inside the local Word process when a user opens the file, scoring AV:L is correct; if the same code runs on a server that accepts remote uploads and parses them, then AV:N is the right choice.
Q: “Does AV:L mean we can deprioritize the patch?”
A: No. Many high‑impact Office RCEs are AV:L but still have high operational risk because delivery and social engineering are easy. Prioritize patching and mitigations as you would for any RCE.
7) Why vendors and CVE titles prefer concise labels like “Remote Code Execution”
Security bulletins must be actionable and quickly understood by operations and management. “Remote Code Execution” is a high‑signal phrase that draws immediate attention to the potential for arbitrary code execution initiated from outside the host; it’s designed to trigger timely patching and mitigation. The advisory body and CVSS vector are the place to find the precise exploitation mechanics you’ll use for planning.
8) Example: how FIRST / CVSS guidance frames this (standards perspective)
The CVSS specification and user guide explicitly state that Attack Vector aims to capture “how remote an attacker can be when they exploit the vulnerable component.” For many document parsing issues, the vulnerable component is invoked locally by the desktop application and should therefore be scored AV:L — even when the malicious data was fetched over the network. FIRST provides examples (including Office/Word) showing exactly this pattern. That is why you will frequently see “Remote Code Execution” in the headline and AV:L in the CVSS string concurrently.
9) Bottom line and operational checklist (one‑page takeaway)

• Interpret the CVE title as an impact/origin flag: remote actors can deliver the exploit.
• Interpret CVSS AV as a technical scoring detail: AV:L means the vulnerable code executes locally when triggered.
• Treat RCE‑labeled advisories as high‑priority regardless of AV:L; promptly apply vendor patches.
• Short‑term technical controls: disable previews, enforce Protected View, harden mail gateway sandboxing, apply application control, limit Office from launching child processes, run user accounts with least‑privilege.
• If you run any server that parses uploaded documents or provides previews, treat those servers as top‑priority patch targets — that environment can convert AV:L into AV:N if the vulnerable parser runs server‑side.

If you want—I can

• Pull the exact CVSS vector string and related metric values for CVE‑2026‑20944 from the vendor advisory and translate them into a one‑line remediation priority for your environment (workstation only vs server‑side parsing).
• Produce a concise patch checklist formatted for a ticketing system (KBs to check, short mitigations to apply, EDR hunts to run) tailored to Microsoft Word/Office endpoints and common mail gateway products.

Concluding sentence
In short: “Remote” in the CVE title tells you the attacker can be off‑host and deliver a weaponized file; “AV:L” in CVSS tells you the vulnerable code is executed inside a local process at trigger time. Both are true, and both are useful—read them together and prioritize patching and mitigations accordingly.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center