Microsoft’s August 11 advisory for CVE-2026-63513, titled “Microsoft Office Graphics Component Remote Code Execution Vulnerability,” is not describing a network-reachable Office service that an attacker can hit from the internet. Its CVSS attack vector of AV:L means the vulnerable Office graphics component is reached through a local execution path—which can include a victim opening or otherwise processing attacker-supplied content on their own PC.

The apparent contradiction comes from treating “remote code execution” and CVSS “Attack Vector” as if they answer the same question. They do not. Microsoft’s title classifies the consequence: an attacker can cause code to run on the affected machine. The AV:L value classifies the route to the vulnerable component: exploitation is not performed by sending a network request directly to a listening Office component.

Microsoft’s own FAQ for CVE-2026-63513 says the flaw is sometimes called arbitrary code execution, or ACE, and that the exploit is carried out locally. That practical conclusion is right. But its explanation that “Remote” refers to the attacker’s location is imprecise enough to create the confusion it is trying to solve. In normal security usage, remote code execution means the attacker obtains execution on a target system other than the system they control; it does not require the vulnerable software to expose a network-facing service.

Infographic showing a malicious Word macro delivered by email, triggering remote code execution on a protected local endpoint.AV:L does not mean the attacker needs to sit at the keyboard​

The authoritative CVSS v3.1 specification from FIRST defines the Attack Vector metric as the context by which exploitation is possible. A Local attack vector applies when the vulnerable component is not bound to the network stack and the attacker’s path uses read, write, or execute capabilities on the target system.

Importantly, the standard explicitly includes attacks in which the attacker relies on user interaction—such as social engineering a legitimate user into opening a malicious document. The victim may receive the file by email, Teams, SharePoint, a browser download, removable media, or another remote delivery method. The exploitation event is still AV:L if the vulnerable Office code is reached when the file is processed on the endpoint rather than through a protocol request aimed at a network service.

That distinction is easy to miss because a malicious attachment campaign feels remote to everyone involved. The sender may be on another continent, the document may arrive through cloud mail infrastructure, and the victim may never knowingly download an executable. CVSS is narrower: it asks whether the vulnerable component itself can be attacked through the network stack. For a file-parsing or graphics-rendering bug in Office, the answer can be no even when the malicious file was delivered remotely.

Microsoft’s older Office and graphics-component advisories illustrate the same terminology. The company has long described specially crafted documents or websites that cause code execution in the user’s context as remote code execution vulnerabilities, while the technical path often depends on a local application processing untrusted content. The label describes where hostile code ends up running: on the victim’s Windows device, under the security context of the Office user.

The title describes impact; the vector describes exposure​

A useful way to read CVE-2026-63513 is to separate four questions that vulnerability summaries often compress into one line:

  • The title’s “Remote Code Execution” describes the expected security impact: code execution can be obtained on the targeted system.
  • AV:L describes the access path: the Office graphics component is reached through a local process or local content-processing workflow, not a remotely exposed service.
  • A User Interaction metric, if required by Microsoft’s published vector, would describe whether a victim must open, preview, render, or otherwise process attacker-controlled content.
  • The Privileges Required metric would describe whether the attacker needs an existing account or local foothold before the exploit can work.

These properties can coexist without conflict. A user can be tricked into processing a file, the vulnerable Office component can run it locally, and the attacker can gain code execution on that user’s machine. It is still an RCE outcome. It is also still an AV:L vulnerability under CVSS.

The difference has operational consequences. A network-scanning tool that looks only for open ports or exposed Office services will not identify likely exposure to this flaw. Conversely, a security team should not downgrade the issue merely because AV:L appears less alarming than AV:N, the CVSS value for a remotely reachable network service. The relevant controls are endpoint patching, attachment handling, user-context protections, email and download filtering, and monitoring for suspicious Office child processes—not firewall rules around a server daemon.

“Arbitrary code execution” is clearer, but does not make the risk smaller​

Microsoft’s FAQ invokes ACE as an alternate term. In this context, that wording is useful because it focuses on the real condition: an attacker may be able to make the target system execute code they chose. It avoids the common but incorrect inference that an RCE title guarantees unauthenticated, over-the-network exploitation.

Still, ACE and RCE should not be treated as separate impact categories. They are commonly used to describe substantially the same end state: attacker-controlled code executes where it should not. What changes from vulnerability to vulnerability is the delivery path, the user interaction requirement, the privilege level of the resulting process, and whether another flaw is needed to turn execution as a standard user into administrator or SYSTEM control.

For Office defects, that last point is especially relevant. Code execution in the context of a standard user can still expose the user’s documents, browser session material, saved credentials, cloud-storage sync folders, and access tokens available to that account. Endpoint protections, Attack Surface Reduction rules, Microsoft Defender detections, and least-privilege configurations may constrain follow-on activity, but they do not remove the underlying need to patch.

Microsoft’s historical graphics-component bulletins also repeatedly noted that users operating with fewer rights could be less affected than administrators. That is a mitigation of the post-exploitation blast radius, not proof that the initial document or rendering path is harmless.


What Microsoft has and has not clarified for CVE-2026-63513​

Microsoft has clearly classified CVE-2026-63513 as an Office graphics-component code-execution issue and has explained that its CVSS local vector refers to the local exploitation path. The company has not, in the public explanation cited in the advisory FAQ, supplied the attack narrative administrators need to distinguish among several very different practical cases: a document that must be opened manually, a file rendered in an Office preview surface, content fetched from a website, or a scenario requiring an attacker who already has local access.

That missing detail matters. A file that requires a user to open and enable content belongs in a different priority tier from a vulnerability triggered by normal preview or rendering behavior. Microsoft has previously called out Preview Pane exposure explicitly when it applied to Office vulnerabilities; its explanation for CVE-2026-63513, as published on August 11, does not establish that the Preview Pane is an attack vector.

The public materials also do not, in the explanation itself, settle whether exploitation has been observed in the wild, whether proof-of-concept code exists, or which exact Office servicing channels and builds are affected. Those are the facts administrators need before making a defensible emergency-patching decision. The absence of those details should not be filled with assumptions based solely on the word “remote” in the title.

How Windows and Office administrators should treat it​

The correct response is to patch affected Office installations through their normal supported servicing channel and verify the deployment against Microsoft’s CVE-specific update guidance. Do not try to mitigate CVE-2026-63513 by treating it as an exposed network-service vulnerability, and do not exempt endpoints simply because they sit behind a perimeter firewall.

Until Microsoft provides a more specific exploitation path, organizations should treat the flaw as a potential malicious-content risk. That means paying particular attention to endpoints whose users routinely receive Office files from outside the organization, shared workstations, virtual desktop pools, finance and legal teams processing documents, and systems where Office runs with elevated local rights.

The key correction is simple: AV:L says the vulnerable Office code is invoked locally; “remote code execution” says the attacker may obtain code execution on the victim’s machine. The first limits the direct attack surface. It does not turn CVE-2026-63513 into a mere local privilege-escalation bug, and it does not mean an attacker must physically access the victim’s PC.