The short answer is: the CVE headline and the CVSS Attack Vector are answering two different operational questions — the CVE title tells you what an attacker can achieve and from where they can try, while the CVSS AV metric describes where the vulnerable code actually executes when the bug is triggered. For CVE-2025-62555 the result is the familiar “remote delivery, local execution” pattern: a remote attacker can deliver a malicious Word document (so the advisory calls it a Remote Code Execution issue), but the vulnerable code runs inside the local Word process when the victim opens or previews that file, which is why the CVSS Attack Vector is scored as Local (AV:L).
Microsoft’s advisory for CVE-2025-62555 describes a use‑after‑free in Microsoft Word that can lead to arbitrary code execution when a crafted document is parsed on the endpoint. In vendor language this is presented as a Remote Code Execution (RCE) class issue because an attacker located off‑host can cause code to run on a target machine by delivering a malicious file and getting a user to open it. At the same time, the published CVSS v3.1 vector for the CVE lists AV:L (Attack Vector: Local) and UI:R (User Interaction required) — a combination that reflects the exploitation mechanics rather than the attacker’s origin.
This dual phrasing — RCE in the headline versus AV:L in the CVSS vector — is common for document‑parsing vulnerabilities in Office and other client applications. Understanding why both are correct is essential for accurate triage and remediation.
Independent, standards‑level documentation (the CVSS specification and user guide) clarifies why document parsing vulnerabilities are usually scored AV:L; this should be used to validate triage logic and automated scoring pipelines.
Caution: until in‑depth technical analyses or proof‑of‑concepts are published, low‑level exploitability details should be treated as provisional and decisions should be guided by vendor patches and conservative operational controls.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
Microsoft’s advisory for CVE-2025-62555 describes a use‑after‑free in Microsoft Word that can lead to arbitrary code execution when a crafted document is parsed on the endpoint. In vendor language this is presented as a Remote Code Execution (RCE) class issue because an attacker located off‑host can cause code to run on a target machine by delivering a malicious file and getting a user to open it. At the same time, the published CVSS v3.1 vector for the CVE lists AV:L (Attack Vector: Local) and UI:R (User Interaction required) — a combination that reflects the exploitation mechanics rather than the attacker’s origin.This dual phrasing — RCE in the headline versus AV:L in the CVSS vector — is common for document‑parsing vulnerabilities in Office and other client applications. Understanding why both are correct is essential for accurate triage and remediation.
Why the headline says “Remote Code Execution” and CVSS says AV:L
Two distinct questions
- The CVE/advisory title asks: what is the impact and from where can an attacker initiate the attack? If the attacker can cause arbitrary code to run on a victim system from off‑host, vendors will use the RCE label to signal high impact and remote delivery capability.
- CVSS’s Attack Vector asks: where must the vulnerable code run at the moment the exploit triggers? If exploitation occurs when a local application (e.g., WINWORD.EXE) parses a file, the correct CVSS value is Local (AV:L) — even if the malicious file was obtained by the victim from the internet. This principle is spelled out in the CVSS specification and user guide.
The “remote delivery, local execution” model
A canonical Office-document RCE chain typically looks like this:- Attacker crafts a malicious Word document exploiting a parser bug.
- Attacker delivers the file remotely (phishing email attachment, cloud share link, or malicious download).
- Victim opens (or a local preview handler renders) the document in Microsoft Word.
- The local Word process parses the crafted content; the bug triggers and arbitrary code executes on the endpoint.
What CVSS means by AV:L (Local) — the formal rule
The CVSS v3.1 Attack Vector metric is explicitly defined to reflect the locality of the vulnerable component at the moment of exploitation. If the vulnerable code is not bound to the network stack and is only invoked by a local process parsing a file, the metric should be scored as Local. The CVSS User Guide provides explicit guidance that document parsing defects should typically be scored AV:L, even if the malicious document was distributed over a network channel such as email or cloud storage. This prevents “double‑counting” network delivery in the exploitability calculation.The practical exception: when AV becomes Network (AV:N)
There is a crucial operational exception: if a network‑facing service or server component performs the same vulnerable parsing (for example, an email gateway that generates previews, an Office Online Server, or a document‑conversion service), the vulnerable code may execute inside a network‑exposed process. In that scenario the correct CVSS Attack Vector is Network (AV:N) because the exploitation occurs in a process reachable across the network without the target user opening a local file. Vendors will explicitly call this out when applicable because it materially increases exposure and the urgency of remediation.Deep dive: why vendors still use “Remote” in RCE headlines
- Brevity and triage: Security bulletins must concisely communicate impact and attacker reach so operations and SOC teams prioritize correctly; “Remote Code Execution” is a high‑signal phrase that triggers immediate attention.
- Attacker origin vs. trigger mechanics: Saying “Remote” in the headline denotes that the attacker can operate from off the target host (email, cloud) rather than requiring physical access. It does not necessarily mean the vulnerable component is a network service.
- Operational prioritization: Teams reading the headline understand “remote actor can cause code to run on a workstation” — this immediately frames the vulnerability as high‑impact even when the CVSS AV is Local.
Technical anatomy: how a Word parsing bug becomes RCE
Typical root causes
Common root causes for modern Office RCE advisories include:- Use‑after‑free (CWE‑416) — freeing an object prematurely then dereferencing it.
- Out‑of‑bounds read/write — corrupting adjacent memory or metadata.
- Heap/stack overflows — overwriting control data or function pointers.
- Type confusion / improper validation — interpreter or parser mistakes that lead to undefined behavior.
Typical exploitation chain (stepwise)
- Weaponize a document to trigger a specific parser path.
- Deliver via email, cloud link, or file share.
- User opens (or preview handler renders) the document; the local process invokes the vulnerable code path.
- Memory corruption occurs; the attacker’s payload is executed under the process/user context.
- Post‑exploit actions: payload drops further artifacts, persists, or moves laterally.
Operational implications — triage, prioritization, and misinterpretation risks
Mistake #1: treating AV:L as “low risk”
A Local Attack Vector does not mean low risk. Because the delivery channels (email, cloud sharing, collaboration apps) are low friction and highly prevalent, an AV:L RCE can be weaponized at scale through social engineering. Security teams that automatically deprioritize AV:L issues risk underestimating real‑world attackability.Mistake #2: treating headline language as the whole story
Conversely, relying solely on a CVE title and assuming the vulnerable component is network‑facing can misdirect resources. Effective triage requires reading the CVSS vector and advisory body to understand the required user interaction and the actual execution locality.How to combine signals for correct prioritization
- Use the CVE title to flag impact and attacker origin.
- Use CVSS metrics (AV, UI, PR, S, C/I/A) to map exploit mechanics and constraints.
- Map your environment: identify any servers, gateways, or services that perform server‑side document parsing — these convert client AV:L risks into network‑exposed AV:N risks and must be prioritized.
Concrete mitigation and hardening checklist
Immediate (first 24–72 hours)- Patch — apply Microsoft’s security updates that map to CVE‑2025‑62555 across all affected Word/Office builds. Vendor KB mappings are authoritative for patch testing and rollouts.
- Harden mail gateways — quarantine suspicious attachments, enforce attachment type policies, and apply sandboxing where possible.
- Enable Protected View — ensure Office opens files from the internet in Protected View to reduce attack surface.
- Disable or restrict macros — require signed macros and avoid policies that enable all macros.
- Enforce application control (AppLocker, WDAC) and use Attack Surface Reduction (ASR) rules to prevent Office from launching child processes unexpectedly.
- Tighten least‑privilege models so users run with non‑admin privileges; this reduces post‑exploit blast radius.
- Tune EDR/EDR‑like detection for anomalous Office process behavior and suspicious child processes spawned from Word.
- Audit server‑side renderers and preview services — any network‑exposed process that parses Office files must be patched immediately and isolated if necessary.
- Maintain forensic readiness: preserve suspicious files and related telemetry for analysis.
- Train users in phishing resilience; combine with phishing‑resistant MFA where feasible.
Detection and hunting recommendations
- Create EDR rules to flag Office processes that spawn command shells, drop executables to disk, or perform suspicious network connections immediately after document open.
- Hunt for rapid child process creation from WINWORD.EXE or unusual code injection patterns into Word process memory.
- Monitor email gateway telemetry for spikes in delivery patterns that match weaponized documents.
- Retain and inspect any quarantined or sandboxed documents for exploit signatures or unusual file markers.
Risk analysis — strengths and weaknesses of vendor messaging
Strengths
- The RCE headline provides a high‑signal urgency flag that drives rapid response for high‑impact issues.
- CVSS provides standardized, mechanistic context that helps triage systems compare vulnerabilities objectively when parsed correctly.
- Advisories usually include the required user interaction and affected builds so administrators can take specific action.
Risks and sources of confusion
- Headline/machine parsing mismatch: automated pipelines that only ingest CVE titles may misclassify the attack surface (network vs local).
- Server‑side blind spot: organizations that don’t inventory server‑side preview/render components may miss hosts that are effectively network‑exposed.
- Incomplete technical detail: initial advisories often withhold low‑level exploitation mechanics to avoid facilitating attacks; analysts must flag such claims as provisional until corroborated by vendor or trusted third‑party analysis.
Verification and what remains uncertain
Microsoft’s Update Guide entry and the vendor advisory are the authoritative records mapping the CVE to patches and affected builds. At disclosure, vendor wording and CVSS metrics provide the basis for operational decisions, but detailed exploit primitives and proof‑of‑concepts are often absent in early advisories. Any claim about exact exploitation techniques, success rates, or evidence of in‑the‑wild use should be treated cautiously until corroborated by independent technical write‑ups or telemetry reports.Independent, standards‑level documentation (the CVSS specification and user guide) clarifies why document parsing vulnerabilities are usually scored AV:L; this should be used to validate triage logic and automated scoring pipelines.
Quick reference: translate the headline into action
- Headline: “Remote Code Execution” → treat as high impact; an attacker located off‑host can attempt to deliver a weaponized file.
- CVSS AV:L + UI:R → the vulnerable code runs locally and requires user interaction; focus immediate mitigations on endpoints, email gateway filtering, Protected View, and rapid patching.
- If you operate any server that parses Office files for clients, treat those hosts as top‑priority for patching — they can change the attack vector from Local to Network.
Conclusion
CVE‑2025‑62555’s label as a Microsoft Word Remote Code Execution Vulnerability and its CVSS Attack Vector: Local (AV:L) are not contradictory — they are complementary. The CVE title warns that an attacker located off‑host can deliver a crafted document that ultimately causes arbitrary code to run on a victim machine. The CVSS AV:L score documents the mechanic of exploitation: the vulnerable code executes inside a local Word process when the document is opened or parsed. Treat the headline as a red flag for impact and the CVSS vector and advisory text as the operational recipe explaining how an exploit completes. Use both signals together to prioritize rapid patching, harden mail/document handling pathways, enforce Protected View and application control, and hunt for suspicious Office process behavior — and be especially vigilant where server‑side document rendering or previewing is in use, because that exception can convert a Local exploit into a network‑exposed one.Caution: until in‑depth technical analyses or proof‑of‑concepts are published, low‑level exploitability details should be treated as provisional and decisions should be guided by vendor patches and conservative operational controls.
Source: MSRC Security Update Guide - Microsoft Security Response Center