Microsoft has published a critical advisory for a remote code execution vulnerability in Excel, tracked as CVE-2025-62560, with a CVSS base score of 7.8. The company warns that an attacker can craft a malicious workbook that, when opened or previewed, allows arbitrary code execution on a victim’s machine. But the CVSS vector labels the attack vector as “Local,” causing confusion about the true risk.

What changed: the disclosure and the technical gap

The advisory, first released through Microsoft’s Security Update Guide, carries a blunt headline: “Microsoft Excel Remote Code Execution Vulnerability.” Yet the CVSS string is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, which many security tools will interpret as a locally exploitable flaw requiring the attacker to already be on the system. That isn’t the full picture.

The core issue is an untrusted pointer dereference (or similar memory corruption) inside Excel’s native parsing engine. An attacker creates a booby-trapped .xlsx, .xlsb, or OLE-embedded file. The file arrives via email, cloud share, or download—remote delivery. When a victim opens it, Excel’s parser encounters the malformed input and corrupts memory in a way that lets the attacker execute code in the context of the logged-on user. No macros, no script, just a data-only attack.

Why the CVSS says “Local” and why that’s dangerously misleading

The CVSS Attack Vector metric is strict: it describes where the vulnerable component must be at the moment of exploitation. Because Excel runs on the endpoint, parsing the file locally, the vector is AV:L. It’s a consistent scoring pattern for all Office document-parsing vulnerabilities—CVSS intentionally doesn’t count the network delivery step to avoid double-counting risk.

Microsoft addressed this directly in the advisory FAQ: “The word Remote in the title refers to the location of the attacker. This type of exploit is sometimes referred to as Arbitrary Code Execution (ACE). The attack itself is carried out locally.” That explains the disconnect, but it doesn’t soften the blow: an external attacker can still compromise your machine.

Treating AV:L as “low urgency” is a critical mistake. The combination of low attack complexity, no privileges required, and the ubiquity of Excel means this vulnerability scores right below the worst-case scenarios. The user interaction required (opening a file) is trivially satisfied through phishing, watering-hole attacks, or compromised shared links. For IT teams, the reality is a remote attacker can send one attachment and gain control of a workstation—so long as the patch isn’t applied.

What it means for you

Home users and small offices

If you use Excel, especially outside of a managed IT environment, you’re the primary target. Attackers bank on delayed patching. The file might arrive disguised as an invoice, resume, or shared document. Once opened, code can run silently. Immediately install the latest update for Microsoft 365 or your perpetual-license version of Office. Check for updates manually if automatic updates are off.

Enterprise administrators

This is a high-priority patch for every endpoint running Excel. But don’t stop there:

  • Servers that process Office files are the highest-risk targets. Mail gateways that generate previews, Office Online Server, SharePoint document converters, or any service that calls Excel’s parsing engine become network-accessible—effectively converting the AV:L into an AV:N scenario. Patch these first.
  • Privileged workstations used by IT, finance, and executives come next. A compromise there can lead to rapid lateral movement.
  • General user machines should be patched immediately afterward. Enable automated updates if possible, and verify deployment success.

Security analysts and SOC teams

Update your detection rules. Look for Excel spawning unusual child processes (cmd.exe, powershell.exe, wscript.exe). Monitor for anomalous outbound network connections from Excel. Since this is a data-only attack, macro-blocking won’t help; focus on behavioral telemetry. If you suspect exploitation, isolate the host, preserve forensic artifacts, and pivot through mail logs to find who else received the malicious attachment.

How we got here: Office parsing bugs and the CVSS “local” pattern

Excel’s codebase is enormous and decades old. It handles multiple file formats—BIFF, Open XML, OLE—each with its own complex parsing routines. Memory-safety defects in these parsers (use-after-free, heap overflows) are discovered regularly. The pattern of remote delivery + local execution has been the standard for Office RCEs for years. In 2025 alone, several similar Excel vulnerabilities were disclosed, all carrying RCE titles but AV:L vectors.

The CVSS specification explicitly documents this reasoning: if the vulnerable component is a local application that parses data, the vector is Local, even if the data originates from the network. The alternative would artificially inflate scores and confuse exploit comparisons. Microsoft follows this guidance, producing what looks like a mismatch but is actually two complementary signals: the CVE title shouts “remote threat,” while CVSS provides the precise exploit context needed for scoring engines.

This duality isn’t new, but it often trips up defenders who treat CVSS scores as the sole prioritization driver. A 7.8 with AV:L can appear less urgent than an 8.8 with AV:N—but when the chain is as simple as “send an email, get a shell,” the operational risk is virtually identical.

What to do now

  1. Patch immediately. Microsoft’s monthly security updates (or the relevant out-of-band fix, if one drops) contain the fix. For Microsoft 365 Apps, the patch is delivered via Click-to-Run. For perpetual versions, download the update from the Microsoft Update Catalog. Confirm the KB number from the advisory.

  2. Harden email and file-handling. Configure mail filters to quarantine or detonate attachments with suspicious extensions. Block common attack file types if not needed. Use Safe Attachments in Defender for Office 365 or equivalent sandboxing.

  3. Enforce Protected View and Application Guard. In Group Policy or Intune, set files from the internet to open in Protected View. For high-risk users, consider Application Guard for Office to isolate the Excel process in a container.

  4. Disable unnecessary preview panes. In both File Explorer and Outlook, turning off automatic previews reduces exposure without requiring user decisions.

  5. Limit Excel’s capabilities. Restrict macro execution to signed macros only, but recognize this vulnerability bypasses macros. Deploy application control rules (e.g., Windows Defender Application Control) to prevent Excel from spawning unapproved child processes.

  6. Watch for exploitation. Update your SIEM queries to detect the indicators mentioned above. Hunt for payload staging artifacts or credential theft following document opens.

What to watch next

Microsoft’s advisory currently does not confirm active exploitation in the wild, but that can change rapidly. Once a proof-of-concept circulates, opportunistic phishing campaigns are almost certain. Administrator awareness of the CVSS/RCE title dichotomy should be paired with automated detection of the patch across the estate. If patching is delayed for any reason, apply aggressive file restrictions and inbox scanning as stopgaps.

The underlying parser vulnerability class—memory corruption in a local application—won’t disappear soon. Microsoft has been investing in memory-safe rewrites and sandboxing, but for now, the patch cycle remains the primary defense. This incident is a reminder that CVSS base scores are just one input for risk decisions. When the advisory says “Remote,” treat it as remote—even when the vector says “Local.”