Microsoft published a security advisory this week for a vulnerability in Excel that carries the alarming label “Remote Code Execution”—but the technical score attached to it says the attack vector is “Local.” That apparent contradiction has puzzled many Windows users and IT professionals. The short explanation, per Microsoft’s own documentation: “Remote” in the CVE title refers to the attacker’s location, while the “Local” CVSS metric describes where the exploit actually runs. In other words, a cybercriminal can send you a booby-trapped spreadsheet from halfway around the world, but the malicious code won’t fire until you open the file on your own machine. It’s a distinction that matters for how you prioritize defenses, but not for how serious the threat is.

What the Advisory Actually Says

CVE-2026-20957 is officially described as a “Microsoft Excel Remote Code Execution Vulnerability.” The advisory, posted on the Microsoft Security Response Center (MSRC), notes that successful exploitation lets an attacker execute arbitrary code in the context of the currently logged-on user—installing programs, altering or deleting data, or creating new accounts with full rights. The CVSS v3.1 vector string, however, begins with AV:L—Attack Vector: Local—which indicates the vulnerable code runs inside a local process on the target machine. Microsoft addresses the discrepancy head-on in the 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.”

This is not a mistake or a misclassification. It’s a deliberate, long-standing convention in which the CVE title communicates the worst-case operational impact—an attacker outside your network can achieve code execution—while the CVSS vector captures the precise technical conditions under which the vulnerability is triggered. For Excel, the trigger is parsing a maliciously crafted workbook. The file can arrive via email, a shared link, or a compromised website, but the actual corruption happens when Excel’s own native code—often written in C/C++—misinterprets malformed records, leading to a use-after-free, heap overflow, or similar memory-safety violation. Because the parser is running on the endpoint, CVSS calls the attack vector Local. Because the attacker can be anywhere, the title says Remote.

Why This Vulnerability Still Demands Immediate Action

For everyday users, the “Local” label might sound reassuring—as if the attacker needs physical access to your laptop. That would be a dangerous misinterpretation. The only thing that needs to be local is the Excel software itself. If you open an infected .XLSX attachment that lands in your inbox, or you preview a document from a cloud storage link that invokes Excel’s rendering engine, the exploit chain kicks off. No macros are required; a pure parsing flaw can be triggered just by loading the file. Social engineering—convincing someone to click—remains the weakest link, and it’s a low-friction attack.

System administrators face a broader threat landscape. The same vulnerable parser may exist on mail gateways, SharePoint servers that convert documents, or Office Online Server instances that generate previews. When Excel’s code runs in a server context listening on a network socket, the effective attack vector becomes Network (AV:N), not Local. That’s because the attacker can trigger the bug without waiting for a user to double-click—simply delivering a malicious file to a mailbox that auto-previewing attachments processes is enough. Defenders must inventory every place where Office document parsing happens, not just desktops.

Developers and IT pros who build or maintain applications that use Excel’s parsing libraries—whether through COM interop, Open XML SDK, or undocumented APIs—should also take note. If your service processes user-supplied spreadsheets server-side, you might be exposing a network-attackable surface. Even client-side tools that load workbooks from untrusted sources can become vectors. Audit any code path that calls into Excel’s binary format parsers, and ensure those environments are patched.

Office Document Parsing: A Long History of “Remote” vs “Local”

This isn’t the first time Microsoft has labeled an Office vulnerability Remote Code Execution while CVSS calls it Local, and it won’t be the last. Word, Excel, PowerPoint, and Outlook all share a sprawling legacy of native parsers for dozens of file formats—BIFF, OLE2, MSO, and many others. These parsers are notoriously fertile ground for security bugs because they date back decades, operate on complex binary structures, and often run outside the safeguards that protect modern managed code. Security researchers routinely find memory corruption issues in them, and attackers weaponize those findings with carefully constructed files.

The CVSS standard itself mandates this split. Attack Vector defines the proximity needed to trigger the vulnerability, not to deliver the payload. The four mutually exclusive values—Network, Adjacent, Local, and Physical—aim to capture the minimum barrier an attacker must cross. For a file-parsing flaw, that minimum is getting the file opened locally. If the parser were accessible over a network protocol without user interaction—say, an RPC interface that parses Excel data—the vector would shift to Network. Because Excel’s parser requires the application to load the file locally, it stays Local. This prevents double-counting of delivery mechanisms and keeps scores comparable across totally different vulnerability classes.

Practically, this means that when you see an Office CVE with AV:L but a high severity score, you should read it as: “An attacker can craft a file that, if a user opens it, will likely lead to complete system compromise.” The User Interaction requirement (UI:R) and Privileges Required (PR:N) in most of these vectors underscore that no special access is needed—just one click by an unprivileged user. The combination of Low Attack Complexity, No Privileges Required, and High impact on confidentiality, integrity, and availability (C:H/I:H/A:H) pushes the base score well into the “Critical” range, often 7.8 out of 10. That’s the real message: patch immediately, no matter what the Attack Vector field says.

Your Patch-and-Protect Checklist

Microsoft has already released security updates that address CVE-2026-20957. Here’s what to do, broken down by role:

For Home Users and Small Businesses

  1. Run Windows Update now. Go to Settings > Update & Security > Windows Update and check for updates. If Microsoft 365 or Office isn’t updated through Windows Update, open any Office app, go to File > Account > Update Options > Update Now.
  2. Keep Protected View on. Don’t disable the warning bar that appears when you open a file from the internet. It sandboxes the file, preventing active content from running until you explicitly enable editing.
  3. Turn on Safe Documents if you have Microsoft 365 E5. This feature automatically opens files from potentially dangerous locations in a virtualized container, isolating the parser.
  4. Be skeptical of unsolicited attachments. Even spreadsheets that look legitimate can harbor parser exploits. If you weren’t expecting a file, verify with the sender through another channel before opening.

For IT Administrators

  1. Deploy the latest Office patches across your fleet. Use your patch management tool to force installation. Microsoft did not credit any public exploit, but post-patch reverse engineering often leads to working proofs-of-concept within days.
  2. Audit any server that parses Excel files. Check SharePoint Online, on-premises SharePoint, Exchange mail flow rules that detonate attachments, and any third-party mail security appliances that render previews. If they use Excel components, they must be patched as aggressively as desktops—these are where AV:N truly applies.
  3. Configure mail filters to block or sandbox risky file types. At a minimum, ensure your email gateway quarantines .XLS, .XLSX, .XLSM, .XLSB, and legacy formats like .XLT. Sandbox them in an isolated environment where Office is installed and kept up to date, but with network restrictions.
  4. Harden user privileges. Successful code execution inherits the rights of the Excel process. If your users must not be local administrators, the blast radius shrinks dramatically. Enforce least privilege with a tool like Windows LAPS or a third-party PAM solution.
  5. Build detection rules. Write EDR queries to flag Excel.exe spawning unexpected child processes (cmd.exe, powershell.exe, wscript.exe) or making outbound network connections on non-standard ports. Historical Excel RCEs often drop malware this way.
  6. Communicate clearly to management. Avoid jargon: “A critical update fixes an Excel bug that lets attackers take over a PC if someone opens a rigged file. We’re pushing patches to all devices, blocking dangerous attachments at the email server, and verifying nothing’s already compromised.”

For Developers

  • If your application uses Excel interop libraries (e.g., Microsoft.Office.Interop.Excel), ensure the client machines have the latest Office runtime patches. Avoid loading user-uploaded files in server-side Excel processes; use the Open XML SDK or a secure third-party library that doesn’t invoke native parsers whenever possible.

Stay Vigilant: The Next Wave of Excel Exploits

History suggests that within days or weeks of a patch, threat actors will attempt to reverse-engineer the fix and develop exploits for unpatched systems. Vulnerabilities in Excel’s parsing engine have been a staple of targeted attacks—from nation-state espionage campaigns to ransomware delivery—because they bypass macro-based defenses and only require opening a file. Expect phishing campaigns that use fake invoices, reports, or shared documents to deliver the malicious workbook.

Microsoft’s recent security defaults, like blocking macros by default for internet-originated files, help reduce the overall attack surface, but they are not a panacea against pure parsing bugs. Defense-in-depth remains the watchword: patching, isolation, least privilege, and thorough monitoring. As the advisory’s own clarification shows, “remote” does not mean your firewall stops everything—it means the attacker is out of sight, waiting for you to open that file. Don’t give them the chance.