RCE vs Local: Decoding CVE Titles and CVSS Vectors in Office Vulnerabilities

Microsoft’s CVE naming can look contradictory at a glance: a Microsoft Office entry labeled “Remote Code Execution” while its CVSS vector reads AV:L (Local). That apparent mismatch is not a mistake — it’s a product of two separate, sensible conventions colliding: one is a vendor‑level descriptive class (what kind of impact the flaw enables), and the other is a scoring metric (how the specific exploit is delivered to the vulnerable component). Understanding the difference is essential for accurate triage, risk prioritization, and communication between security teams and administrators.

Background / Overview​

Microsoft and many security vendors use the phrase “Remote Code Execution (RCE)” as a high‑level classification for vulnerabilities that ultimately enable an attacker to run arbitrary code on a victim system. That label describes the attacker’s objective — code runs on a target machine as a result of the flaw — not necessarily the precise network/physical path required to trigger the flaw.
At the same time, CVSS (Common Vulnerability Scoring System) assigns an Attack Vector (AV) value — Network (N), Adjacent (A), Local (L), or Physical (P) — that quantifies how remote an attacker can be to exploit the vulnerability. A Local (AV:L) rating means the exploitable component is not bound to the network stack: the exploit requires local access, a local account, or that a victim execute/trigger something on the host (for example, by opening a malicious Office document). The CVSS specification and guidance make this explicit: attacks that rely on a user opening a file delivered via email or web should typically be scored as Local even if the malicious file was delivered over the network.
This divergence—“Remote Code Execution” as a goal vs. “Local” as the exploitation path—is common across Office document parsing CVEs. Microsoft’s own Security Update Guide sometimes lists an Office entry as “Remote Code Execution” while the CVSS vector indicates AV:L; community writeups and trackers routinely annotate the same pattern for Office CVEs in 2025.

---

Why the words “Remote” and “Local” aren’t contradictory​

Two different questions are being answered​

• The CVE title answers: what can the attacker achieve? — e.g., Remote Code Execution indicates the vulnerability can lead to code execution on the victim machine, which is a severe impact class.
• The CVSS Attack Vector answers: how directly can the attacker exploit this flaw? — AV:L (Local) indicates the vulnerable component isn’t network‑facing; exploitation requires local access or user interaction (such as opening a file).

Paraphrased: the CVE label says “if exploited, an attacker can cause code to run on the target,” while the CVSS vector says “the exploit itself must be triggered locally (the attacker needs the target to open or execute something locally).” These are complementary statements, not contradictory ones. The CVSS user guide explicitly covers this scenario: a document parsing flaw that requires a user to open a malicious file should be scored with AV:L even if the file was distributed remotely.

Practical example — Office document RCEs​

Consider a typical Office memory‑corruption bug where a specially crafted Word/Excel/PowerPoint file coerces a parser into dereferencing freed memory and handing control to attacker data. The attacker’s end goal is remote code execution (the victim’s computer runs attack code). But the exploitation flow looks like this:

• Attacker crafts malicious Office file and hosts it on a website, emails it, or shares it via cloud storage (remote delivery).
• Victim downloads and opens (or previews) the file in a local Office client.
• The local Office process parses the file, hits the bug, and the attacker’s payload executes under the user’s account.

The exploitation action (step 2–3) happens on the victim’s machine — that’s a Local attack vector — yet the overall attack chain begins from a remote actor. This is why Microsoft and others label the vulnerability class “Remote Code Execution” (attack outcome) while CVSS marks the attack vector as Local (exploitation path). Community analysis and incident posts for Office CVEs in 2025 routinely call this out: the vulnerability enables arbitrary code execution on the target but requires local execution of the crafted file to trigger it.

---

How CVSS treats “local” but distributed attack paths​

CVSS design intent​

CVSS measures the logical and physical distance an attacker can be when they exploit the vulnerable component. The metric is intentionally conservative: it rates the base score higher the more remote an attacker can be, because a larger pool of attackers can reach the target. The specification and user guide clarify that if the vulnerable component is not bound to the network stack (i.e., requires the target application to parse a file on the local filesystem), the Attack Vector should be Local — even if the malicious input landed via email or web. This subtlety is a deliberate rule to avoid double‑counting network delivery and to keep scoring consistent across diverse exploitation models.

Real‑world interpretation​

• AV:N (Network) — vulnerability exploitable at the protocol level across one or more routers (e.g., a network service buffer overflow).
• AV:A (Adjacent) — attack limited to a local network segment or same subnet (e.g., ARP or certain Bluetooth scenarios).
• AV:L (Local) — the attacker’s path is via read/write/execute capabilities; exploited locally or via user interaction (e.g., opening a crafted document).
• AV (Physical) — requires physical access to the device.

The CVSS user guide explicitly calls out the Office/document scenario as Local: a browser or mail client may download a malicious document over the network, but when a separate local application (Office) opens/parses that document and triggers the vulnerability, scoring AV:L is appropriate.

---

Why Microsoft sometimes uses “Remote Code Execution” in advisory titles​

RCE as impact shorthand​

Security advisories use concise, understandable phrases to indicate the seriousness of an issue. “Remote Code Execution” is a shorthand many administrators instantly recognize as high‑impact: if an attacker can make your machine run arbitrary code, that’s critical. Vendors, researchers, and media outlets often use RCE as a class label for any bug that can lead to remote adversary control — regardless of whether the exploit requires user interaction to complete.

Communication tradeoffs​

Vendor advisories aim to be brief and broadly understood. Using “Remote Code Execution” in a title signals severity and the general nature of the threat. The advisory body then provides the technical details (CVSS vector, required user interaction, mitigations, affected builds) that clarify the actual exploitation model. That structure is intentional: a short title for triage urgency, details for technical accuracy in the body. Microsoft’s Security Update Guide and many public trackers reflect this pattern for Office CVEs where the impact is arbitrary code execution but the attack vector is Local.

---

Why this matters for defenders and administrators​

Risk triage differences​

• If an RCE CVE is AV:N (Network), remediation priority is often higher because attackers can try to reach vulnerable services across the internet without user action.
• If an RCE CVE is AV:L, the immediate mitigation focus shifts toward reducing user interaction risk and hardening endpoints (e.g., disabling automatic preview, enforcing Protected View, applying application allowlisting).

Confusing the two can lead to misprioritization. Treat the CVE title as a red flag for impact and the CVSS vector (and advisory narrative) as the operational recipe for exploitation. Tools like WSUS/Intune and EDR should triage accordingly: prioritize network‑exploitable RCEs for perimeter and external exposure, while applying user‑centric mitigations (macro controls, attachment handling) for AV:L Office RCEs. Several community advisories and enterprise write‑ups from 2025 echo this approach for Office families.

Detection and containment posture​

For AV:L Office RCEs, defenders should:

• Enforce application hardening:
• Enable Protected View and disable macros by default.
• Restrict Office from executing content in less‑trusted directories.
• Minimize privilege of users:
• Run users with standard (non‑admin) accounts to limit post‑exploit impact.
• Control preview behavior:
• Disable Outlook/Explorer automatic preview for high‑risk groups.
• Harden document delivery:
• Strip or sandbox attachments in mail gateways, or use detonation chambers for suspicious files.
• Monitor for post‑exploit behaviors:
• Watch for unusual child process creation from Office apps, credential dump patterns, or network connections to command‑and‑control hosts.

These are standard operational mitigations for document‑based RCEs and align with vendor guidance for Office vulnerabilities.

---

Examples and historical context​

Office RCEs in 2024–2025​

The pattern is well established: Office document parsing remains a high‑yield target for attackers. A string of Office CVEs in 2024 and 2025 exhibit the same labeling and vector pattern: advisory titles indicate remote code execution while CVSS vectors indicate Local; vendor text clarifies that a user must open or preview a crafted file to trigger the bug. Community trackers and vulnerability feeds repeatedly show “Remotely Exploit: No” for such entries while still using the RCE label. This is not a new anomaly but a recurring labeling convention reflecting impact versus exploit path.

Preview panes, server‑side rendering, and the risk escalation​

One nuance: some environments can elevate the exposure. If a server component (for example, a mail server or document‑rendering service) parses files on behalf of users, the same file‑parsing bug might be exploitable without explicit user action on the desktop, effectively changing the threat model to network‑accessible. In such cases, vendors may issue additional advisories or list broader affected components; the Attack Vector in CVSS should reflect the most direct vulnerable component. The CVSS user guide warns about these chaining effects and recommends scoring the vulnerable component itself (not upstream delivery mechanisms).

---

How to read Microsoft’s advisory for CVE-2025-59234 (and similar Office CVEs)​

• Read the CVE title — note the impact class, e.g., Remote Code Execution (signals the potential consequence).
• Read the CVSS vector (AV/AC/PR/UI/etc.) — this tells you the required attacker position and prerequisites (e.g., AV:L, UI:R means local and user interaction required).
• Review the affected products and KBs — these identify which builds to patch via Microsoft Update, WSUS, Intune, or the Update Catalog.
• Check the advisory narrative — Microsoft’s MSRC page commonly states delivery/exploitation details (whether preview panes are a vector, whether macros are required, etc.).
• Cross‑check with independent trackers or vendor blogs for operational guidance and whether proof‑of‑concepts or in‑the‑wild exploitation has been observed.

---

Practical remediation and runbook (prioritized)​

• Immediately identify exposed assets and roll forward:
• Inventory Office builds and versions across the estate.
• Map builds to MSRC KB numbers for the CVE and schedule patching windows.
• Apply vendor patches per Microsoft’s guidance:
• Use normal patch channels (Windows Update / Microsoft Update Catalog / Intune / WSUS).
• Short‑term mitigations if patching is delayed:
• Disable automatic attachment preview in Outlook and Explorer.
• Enforce Protected View and disable macros by default.
• Block common document‑hosting domains if applicable, or quarantine inbound Office attachments.
• Post‑patch detection and validation:
• Validate update deployment success with inventory tools or SCCM/MECM reports.
• Monitor EDR telemetry for suspicious Office child processes or persistence techniques.
• Longer term:
• Reduce local admin prevalence, apply application allowlisting, and harden email gateway attachments with sandboxing/detonation.

These steps align with the operational advice given for Office CVEs in recent months and are practical actions for administrators facing AV:L RCE advisories.

---

Communication guidance — how to explain this to non‑technical stakeholders​

• Say: “This vulnerability can let an attacker run code on a user’s machine if the user opens a specially crafted Office file.”
• Add: “Although the attacker delivers the file remotely (email, web, cloud), the exploit itself executes locally when the file is opened. That’s why it’s powerful but usually requires user interaction.”
• Reassure: “Patches exist (or will be released) and vendors recommend configuration changes (Protected View, macro policies) that reduce the immediate risk.”

Framing the issue this way keeps urgency (RCE impact) while accurately describing operational controls (local exploit step).

---

Strengths and limitations of the current labeling approach​

Strengths​

• Clarity of impact: “Remote Code Execution” quickly communicates severity and motivates timely response.
• Concise advisories: Short titles help administrators triage a long list of bulletins.
• Technical precision in body: CVSS vectors and advisory bodies provide the necessary exploitation details.

Risks and limitations​

• Potential for misinterpretation: Non‑technical readers may assume “remote” equals network‑accessible exploitation and overestimate the breadth of immediate exposure.
• Operational misprioritization: Security teams prioritizing only AV:N items for mitigation might under‑protect against document‑based AV:L RCEs that exploit human behavior.
• Chaining complexity: If a server‑side component parses documents, the exposure model can change quickly; that nuance may be missed if only the title is read.

For these reasons, reading the advisory body and CVSS vector — not just the headline — is essential for correct prioritization. Several analyst write‑ups and guides emphasize this nuance for Office CVEs across 2024–2025.

---

Final assessment and guidance​

• The phrase “Remote Code Execution” in a CVE title refers to the attacker’s potential outcome (running code on the victim).
• A CVSS AV:L (Local) rating refers to the technical attack vector — the vulnerability must be triggered locally (e.g., by opening a malicious file), even if that file was delivered remotely.
• Both statements are correct and complementary; they describe different facets of the same attack chain. The CVSS specification and user guide explicitly document the rationale for classifying document‑parsing exploits as AV:L, and vendor advisories follow that practice.
• Operationally, treat such Office CVEs as high priority because of their impact (RCE), but adjust immediate mitigation and detection workstreams to reflect the exploit path (reduce risky user interaction, harden document handling, and deploy patches rapidly). Community tracking and news coverage of Office CVEs in 2025 consistently apply this same approach.

Understanding the distinction — and communicating it clearly inside your organization — transforms confusion into a targeted, effective response: urgent remediation for a high‑impact class of flaws, combined with focused, user‑centric mitigations that block the actual exploitation path.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center