CVE-2025-62205: Understanding Remote Code Execution vs Local CVSS in Office Word

Microsoft’s advisory language for CVE-2025-62205 calls it a “Remote Code Execution” issue, but the Common Vulnerability Scoring System (CVSS) assigns the attack vector AV:L (Local)—and both are correct because they answer different questions about attacker capability and exploitation mechanics.

Background / Overview​

CVE-2025-62205 is reported as a use‑after‑free in Microsoft Office Word that can lead to arbitrary code execution when a crafted document is parsed by the local application. Public vulnerability trackers and vendor advisories list the base CVSS score and vector as CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (base score ~7.8), highlighting local exploitation that requires user interaction but results in high‑impact code execution on the victim host. This produces an apparent terminology clash in headlines: vendors and CVE titles often use the phrase “Remote Code Execution (RCE)” because the attacker can be located remotely (for example, sending a malicious document by email or posting it to a cloud share). CVSS’s Attack Vector metric, by contrast, records where and when the vulnerable component is actually invoked—if the vulnerable code executes inside a local process when a user opens a file, CVSS appropriately marks that as Local (AV:L). The result is a common but easily misunderstood pattern: remote delivery, local execution.

---

Why the CVE title says “Remote Code Execution” while CVSS shows AV:L​

Two different questions, two different signals​

• The CVE/advisory title answers: what can an attacker achieve? If exploited, can the vulnerability lead to execution of arbitrary code on the victim machine? When the answer is yes, the vendor often labels the issue “Remote Code Execution” because a remote actor can deliver the exploit payload.
• CVSS answers: how is the vulnerable component exploited at trigger time? Is the vulnerable code reachable over a network socket, only from adjacent hosts, by local processes, or through physical access? If exploitation requires a local application (Office) to parse a file on disk, the Attack Vector is Local (AV:L)—even if the file was delivered remotely. This is explicitly stated in the CVSS guidance.

Put simply: the title communicates attacker position and impact; the CVSS AV field communicates the exploitation mechanics and constraints. Both are operationally useful but mean different things.

A practical example​

• Attacker crafts a malicious Word document that exploits a parser bug.
• Attacker delivers the document remotely (e.g., phishing email, cloud link, shared drive).
• Victim opens (or in rare cases previews) the document in the local Word application.
• The local Word process parses the crafted content, hits the bug, and attacker‑controlled code executes on the local machine.

Steps 2 and 1 illustrate that the attacker is remote; step 3 is when the vulnerable logic runs locally. CVE headlines describe steps 1–2 (remote delivery + ultimate impact), while CVSS describes step 3 (where exploitation technically happens).

---

The CVSS rule: why document parsing bugs are usually AV:L​

The CVSS user guide clarifies that the Attack Vector metric should reflect the locality of the vulnerable component at the moment of exploitation. If a vulnerability is not bound to the network stack—i.e., the exploited code only runs when a local process parses a file—analysts should choose AV:L even if that file was originally fetched over the network. This prevents double‑counting of network delivery and keeps scoring consistent across many attack models. That rule explains why many Office document parsing bugs—despite being distributed remotely—are scored as Local in CVSS while still being described as RCE in vendor advisories. In short: delivery channel ≠ exploitation locality.

---

When “Remote” and “Local” really do align (the server-side exception)​

There is an important exception: if a server‑side component or a cloud service parses the uploaded document on behalf of a remote client (for instance, mail servers that generate previews, document-conversion services, Office Online Server, or a collaboration platform that renders files), the vulnerable parser may execute in a network‑exposed process. In that configuration the Attack Vector may legitimately be Network (AV:N) and the CVE title and CVSS vector would align. Vendors explicitly call this out when appropriate because it materially changes exposure.
Operational takeaway: defenders must check whether any affected component performs server‑side parsing or previewing; if so, treat the exposure as significantly higher and prioritize remediation accordingly.

---

What CVE-2025-62205’s published metrics tell us​

• Reported CVSS vector for CVE-2025-62205: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (base ~7.8). This indicates local attack vector, low attack complexity, no attacker privileges required, user interaction required, and high impact to confidentiality, integrity, and availability if exploited.
• Public trackers note no confirmed proof‑of‑concept or exploitation in the wild at the time of reporting, but that absence should not be equated with low risk—document-based RCE classes are frequently weaponized quickly after disclosure.
• Microsoft has published an advisory mapping the CVE to vendor updates (patches are the definitive remediation). Administrators should match installed Office SKUs to the Microsoft guidance and apply the recommended updates immediately.

---

Why this distinction matters for defenders and IT teams​

Triaging priorities change depending on AV:N vs AV:L​

• If a critical RCE CVE is AV:N, an unauthenticated remote attacker can exploit the vulnerable service without user interaction—this often becomes a top emergency priority for network‑facing infrastructure.
• If the same CVE is AV:L, exploitation usually requires user interaction (opening a file or preview), shifting mitigation focus toward endpoint hardening and user‑centric controls (mail gateway sandboxing, Protected View, preview suppression, macro restrictions). Misreading AV:L as “safe” can lead to under‑prioritization; document‑delivered RCEs have been a major initial access vector in real incidents.

Concrete operational controls that matter for AV:L Office RCEs​

• Patch immediately across affected Office channels (WSUS/Intune/MECM or the Microsoft Update Catalog).
• Enforce Office Protected View for files from the internet and external sources.
• Disable automatic preview panes in Outlook and Explorer for high‑risk groups.
• Route attachments through mail gateway sandbox/detonation chambers for high‑risk or unknown senders.
• Apply Attack Surface Reduction (ASR) rules and application allow‑listing (AppLocker/WDAC) to limit Office spawning of child processes (e.g., PowerShell, cmd.exe).
• Enforce least privilege: avoid local admin for daily users.

---

Detection and response: what to look for​

Behavioral detection is more reliable than signatures for memory‑safety exploits that do not rely on macros.
Key hunting signals to monitor via EDR and telemetry:

• Office processes (WINWORD.EXE, EXCEL.EXE, POWERPNT.EXE) spawning unexpected child processes such as cmd.exe, powershell.exe, or wscript.exe.
• Unusual outbound connections immediately following Office document opens.
• New persistence artifacts (scheduled tasks, services, registry run keys) appearing shortly after an Office binary is executed.
• Mail gateway sandbox detonations or DLP alerts showing anomalous attachment behavior.

Containment steps on suspected compromise:

• Isolate the endpoint from the network.
• Preserve forensic evidence (EDR snapshots, application logs, email headers, the original malicious file).
• Hunt for lateral movement and credential theft indicators.
• Remediate via patching and credential resets if compromise confirmed.

---

Risk assessment: strengths and limitations of the advisory language​

Strengths (why vendors use “Remote Code Execution” in titles)​

• Rapid triage: “RCE” is a concise signal to operations teams that the potential outcome is severe and requires urgent attention.
• Operational clarity: Using an impact‑based class (RCE) helps unify triage and patching priority across vulnerability feeds.
• Broad reach: The phrase warns defenders that an external adversary can initiate an attack chain—important when stakeholders are non‑technical.

Limitations and pitfalls​

• Potential for misprioritization: Automated systems or teams that parse only CVE titles can misinterpret the attackability if they ignore CVSS vectors and advisory details.
• Ambiguity about required interaction: The title rarely states user interaction or preview server parsing specifics—those are in the advisory body and CVSS metrics.
• Server‑side parsing blind spots: Many teams overlook whether mail servers or cloud renderers are performing server‑side parsing; if they are, the real exploitation vector may be network‑accessible (AV:N), greatly increasing exposure.

Because of these limits, it’s essential to read both the headline and the CVSS/advisory body before choosing mitigations.

---

Practical checklist for administrators (prioritized)​

• Patch first: identify installed Office builds and apply the vendor KB/update that fixes CVE-2025-62205 via your enterprise update channel. Patching is the definitive remediation.
• Enforce Protected View: require files from the Internet or email to open in sandboxed Protected View.
• Disable previews: turn off Outlook/Explorer automatic preview and preview handlers for high‑risk users.
• Mail gateway sandboxing: detonate suspicious attachments in a sandbox before delivery.
• Apply ASR and allow‑listing: prevent Office apps from spawning child processes and restrict execution to approved binaries.
• Least privilege: confirm users run as standard accounts, not local admins.
• Hunting and logging: enable EDR collections and hunt for Office processes spawning shells or unusual network behavior.

---

Technical verification and cross‑checks​

To avoid relying on a single feed, the CVSS vector and impact for CVE-2025-62205 were cross‑checked against multiple independent sources. Public vulnerability aggregators report a CVSS v3.1 vector of AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H and base scores around 7.8; vulnerability databases and trackers mirror Microsoft’s advisory mapping of affected Office SKUs and the availability of vendor patches. These independent confirmations align with CVSS guidance that document‑parsing vulnerabilities which require the victim application to parse a local file should be scored AV:L.

---

What cannot be verified (caveats and caution)​

• Public exploit reliability: at the time of writing, public proof‑of‑concepts and confirmed in‑the‑wild exploitation for CVE‑2025‑62205 are not universally documented. Several trackers report no public PoC and no confirmed exploitation, but that absence can change rapidly after patch release because patches often enable reliable patch‑diffing and exploit development. Treat the absence of PoCs as temporary and avoid complacency.
• Low‑level exploit details: specific heap grooming techniques, gadget chains, and exact memory layout manipulations used to reliably weaponize a use‑after‑free are typically not disclosed publicly in vendor advisories. Those low‑level mechanics should be treated as unverified until a reputable technical analysis or PoC is published. Publicly available writeups sometimes include illustrative PoC snippets, but they vary in fidelity and may not represent the full complexity of a real exploit. Exercise caution when consuming unvetted PoCs.

---

Longer view: how to think about RCE vs AV:L patterns in enterprise risk models​

• Treat any RCE‑class CVE seriously regardless of AV:L; the combination of a high‑impact result and trivial delivery mechanics (email, shared links) makes these vulnerabilities high‑value for attackers.
• Distinguish between client‑side and server‑side parsing in your inventory: server‑side rendering turns many AV:L problems into AV:N problems for the organization as a whole.
• Combine patch deployment with layered mitigations (email hardening, sandboxing, ASR rules, allow‑listing, EDR hunting) to reduce the attack surface while patches are staged.

---

Conclusion​

The apparent conflict between CVE-2025-62205’s “Remote Code Execution” label and its CVSS Attack Vector AV:L is not a mistake—it's a reflection of two different but complementary communication goals. Vendor titles succinctly warn defenders that a remote actor can deliver an exploit and ultimately cause arbitrary code execution on endpoints, while CVSS records the precise exploitation context (the vulnerable code runs locally when the user opens or the system parses the crafted file). Understanding the difference—remote delivery, local execution—is essential for effective triage, prioritization, and operational response.
Administrators should map CVE metadata to their environment, patch promptly using Microsoft’s updates, and harden endpoint and mail handling policies while monitoring for suspicious Office behavior. Treat the RCE label as an urgency flag and CVSS AV:L as a technical recipe that guides mitigation choices; both pieces of information are necessary for a measured, effective defense.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center