RCE Label vs AV:L: Remote Delivery, Local Execution in Excel Attacks

Microsoft’s advisory labeling CVE-2025-59233 as a “Remote Code Execution” (RCE) vulnerability while its CVSS vector lists the Attack Vector as Local (AV:L) is not a contradiction so much as an industry shorthand that mixes delivery and execution models—and that conflation is what causes confusion for defenders and risk managers. The short version: the word Remote in many RCE titles refers to the attacker’s ability to deliver a crafted file from a remote location (for example, by email or a shared link), whereas the CVSS Attack Vector Local (AV:L) describes where the exploit actually executes—on the victim’s machine after the user opens or previews the malicious file. This practical distinction matters for prioritizing mitigations, scanning telemetry, and incident response.

Background​

Modern Office vulnerabilities—Excel in particular—repeatedly show the same pattern: a file-parsing memory-safety bug (use-after-free, out-of-bounds read, heap overflow, etc.) in a widely deployed client is discovered, Microsoft assigns a CVE and publishes a Security Update Guide entry, and the public advisory will often use “Remote Code Execution” language because the crafted file can be sent to victims remotely. The vulnerability’s exploit chain, however, usually requires the victim to open—or in some cases preview—the file, which places the actual exploitation action on the local endpoint. This combined model is sometimes described succinctly as “remote delivery + local execution.”

Why the naming mismatch happens​

• Vendor naming conventions aim for clarity and impact: “Remote Code Execution” signals that an adversary can achieve code execution without first compromising the target environment; an operator can be targeted from afar by delivering a malicious file.
• CVSS (Common Vulnerability Scoring System) is precise about where the attacker must be to exploit the flaw: AV:L indicates the exploit must be run locally (the attacker or a victim must have access to run the malicious input on the target host). This is a metric about access requirements, not delivery mechanics.

In practice, both statements are true: an attacker can be remote in location and send the exploit, but the code runs locally when the recipient opens the malicious workbook.

---

What CVSS Attack Vector AV:L actually means​

CVSS’s Attack Vector metric describes how the attacker must interact with the vulnerable component to exploit the vulnerability. AV:L (Local) means the attacker must have local access to the system or must convince a user to execute the malicious input on that system. This could mean:

• Opening a malicious file received by email or download.
• Running a program or script on the victim machine.
• Leveraging an interactive session in which the user’s action triggers the vulnerable code path.

The consequence: a high-severity CVSS number with AV:L still represents a serious risk when the application is ubiquitous (Excel is ubiquitous) and the method of delivering the malicious file is low-friction (spear-phishing, shared drives, collaboration links). Many Excel memory-bugs are scored with AV:L yet are operationally exploited at scale because adversaries can send crafted documents widely.

---

Why Microsoft (and other vendors) use “Remote Code Execution” in titles​

There are three practical reasons:

• Threat model clarity for defenders — “Remote Code Execution” warns that the attacker does not need prior access to your network to attempt compromise; they can attempt to gain it by sending a file to a target. That’s operationally important even if the exploit requires the user to take action.
• Historical terminology and comparability — Security communities have historically grouped vulnerabilities that can lead to code execution from an external, unauthenticated origin as “RCE” even when the final exploit step happens locally upon file open. This keeps CVE summaries comparable across different vulnerability classes.
• Practical risk framing — For defenders, the delivery mechanism (email attachment, shared link) is the typical risk vector to control. Calling the issue RCE focuses attention on blocking, monitoring, and patching strategies that stop remote adversaries from getting a foothold.

---

Technical anatomy of Excel document-based RCEs​

Most Excel RCE advisories in recent years follow a similar exploitation blueprint:

• A memory-safety bug (use-after-free, heap overflow, out-of-bounds read) exists in Excel’s parser or object handling code.
• An attacker crafts a workbook (.xlsx/.xlsb/.xls) that triggers that bug during parsing or rendering.
• The file is delivered through common remote channels: email attachments, collaboration platforms, shared drives, or web downloads.
• The user opens (or previews) the file; the malicious parsing triggers memory corruption and an exploit chain that results in code running in the user’s context.

Two additional nuances raise real-world impact:

• Preview panes and server rendering: Some mail clients, webmail systems, or server-side Office renderers may parse documents to produce previews; if those parsing paths use the same vulnerable code, the exploit can be triggered with less user interaction. In those cases the exposure becomes closer to a true remote exploit.
• Privilege context: The executed payload runs with the privileges of the user who opened the file. If that user has elevated rights (local admin), the attacker can achieve full system compromise. That is why enterprise privilege hygiene is a crucial mitigation.

---

Realistic exploitation scenarios​

• Spear-phishing email to employees
  An attacker crafts a malicious spreadsheet and sends it as an attachment or link. A recipient opens the file in desktop Excel and the exploit runs locally. Attackers then run payloads to steal credentials or deploy ransomware. This is the most common scenario.
• Preview pane abuse
  A mail server or client automatically renders a preview of the spreadsheet (or an enterprise content-management system renders it server-side). If the preview uses the same vulnerable parser, the exploit can be triggered without explicit user intent—effectively reducing the interaction required. This raises the exposure substantially.
• Shared drive or collaboration vector
  Adversaries place the crafted file on a shared drive or cloud collaboration folder where many users have access. When a user opens the file, the exploit executes. The attack scales if the file is widely accessible.
• Chained attacks
  A document-triggered RCE can provide the initial foothold, after which privilege escalation bugs or weak segmentation enables lateral movement and broader compromise. This is the classic multi-stage enterprise breach.

---

Mitigation and operational guidance​

Applying the vendor patch is the definitive mitigation. Microsoft’s Security Update Guide lists the affected Excel builds and the updates that address CVE-2025-59233; administrators should map those KBs to their servicing channels (Microsoft 365 Apps, Office MSI, Office for Mac, Office Online Server etc.) and deploy them immediately. Where immediate patching is not possible, use layered compensations:

• Enforce Protected View for files from the internet and email attachments. Protected View runs documents in a restricted sandbox and often prevents the exploit path.
• Enable Attack Surface Reduction (ASR) rules to block Office apps from launching child processes (cmd.exe, PowerShell) which many exploit chains rely on.
• Use application allowlisting (AppLocker, Windows Defender Application Control). Allowlisting prevents arbitrary binaries from running even if an Office process is exploited.
• Route suspicious attachments through detonation/sandboxing and block or quarantine high-risk file types for unknown senders.
• Harden email handling: disable auto-preview where feasible and increase scrutiny on external attachments.
• Apply least privilege: ensure users do not run as administrators for day-to-day tasks; this reduces blast radius if an exploit succeeds.

---

Detection and hunting guidance​

Because many Excel parsing exploits do not rely on macros, classic signature-based AV may not detect them. Instead, rely on behavioral telemetry and EDR to spot exploitation attempts:

• Hunt for Office processes spawning unexpected child processes (for example, Excel launching PowerShell, cmd, or wscript). This is a common post-exploitation pattern.
• Look for unusual network egress from Office processes—exfiltration or C2 callbacks from an exploited host often use the same executables that were compromised.
• Search logs for new scheduled tasks, services, or persistence mechanisms created around the same time Office documents were opened.
• Monitor mail gateway logs and DLP/sandbox alerts for malicious Excel content or an abnormal increase in external attachments.

Practical detection playbooks should combine file telemetry (download source, sender), endpoint process activity, and network indicators to build a high-confidence alerting signal.

---

Communication: how to brief non-technical stakeholders​

When explaining the difference between the CVSS vector and the advisory label:

• Use the phrase “remote delivery, local execution” to summarize the model in one clear sentence.
• Explain that “Remote Code Execution” in the advisory signals that an outsider can attempt to compromise an employee by sending a malicious file; the file must still be opened on the employee’s machine for the exploit to proceed.
• Emphasize that patching and basic behavioral controls (Protected View, ASR, allowlisting) materially reduce risk even when the attack vector is technically local.

---

Critical analysis: strengths, gaps, and residual risks​

Strengths of the current vendor approach:

• Microsoft’s Security Update Guide provides an authoritative, per-build mapping to KBs and is the canonical place to get fixes. Administrators can translate vendor guidance directly into patches.
• Labeling a file-parsing bug as RCE raises awareness among defenders and encourages faster action than a more technical-sounding label might.

Potential gaps and cautionary points:

• The RCE label can be misread: organizations that filter solely on CVSS Attack Vector may deprioritize an AV:L issue because they interpret “local” as meaning “low exposure.” That would be a mistake for ubiquitous clients like Excel, because attackers can remotely deliver malicious files at scale.
• Dynamic vendor pages and delayed mirror updates make automated patch orchestration fragile. Many MSRC entries are rendered client-side and third-party trackers (NVD, mirrors) can lag, so operational teams must validate KBs via management consoles or the Microsoft Update Catalog.
• Preview panes and server-side renderers can raise the exposure dramatically; defenders should assume preview and rendering code paths are relevant until proven otherwise.

Unverifiable issues to watch:

• Public proof-of-concept (PoC) exploits and in-the-wild campaigns materially alter risk. At the time an advisory is published there may be no public PoC; absence of a PoC does not imply low risk. Treat the window between vendor disclosure and enterprise patching as a high-priority remediation period.

---

Practical checklist for IT teams (prioritized)​

• Patch: identify affected Excel/Office builds in your estate and deploy the Microsoft updates for CVE-2025-59233 via WSUS, SCCM/ConfigMgr, Intune, or your patching tool. Verify build numbers post-installation.
• Enforce Protected View for files from the Internet and untrusted locations.
• Enable ASR rules to prevent Office from creating child processes, and apply application allowlisting.
• Harden email: disable automatic preview where possible and route suspicious attachments through sandboxing.
• Hunt: run EDR searches for Office processes spawning unexpected children, abnormal network egress, and new persistence artifacts near the advisory date.
• Educate users: brief about not opening unexpected attachments and to report suspicious files.

---

Conclusion​

CVE-2025-59233’s labeling as a “Remote Code Execution” vulnerability while carrying CVSS Attack Vector AV:L is a reflection of two different but complementary truths: an attacker can deliver the exploit remotely, but the vulnerability is triggered and executed locally on the victim’s machine. Defenders must treat both the delivery vector and local execution mechanics seriously—patch promptly, harden Office execution paths, restrict privileges, and monitor behavioral telemetry. That combined approach closes the window of opportunity that remote adversaries rely on when they weaponize document-based memory-safety bugs.
Caveat: public technical details, PoC availability, and exploit-in-the-wild reports can change rapidly after vendor disclosure. Confirm the exact list of affected builds and KB identifiers in Microsoft’s Security Update Guide and your enterprise patch tooling, and prioritize remediation according to your organization’s exposure and threat model.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center