CVE-2026-65813

This is a Microsoft Exchange Server flaw that lets someone who already has a valid account use crafted requests to trick the server into reaching places it normally shouldn’t. That can help them break out of their current permissions and gain much higher access. Think of it like having an employee badge, then using a trick to bypass internal locks and reach the building’s “manager-only” areas.

This matters if your business runs Microsoft Exchange Server on any of the listed affected releases (2016 CU23; 2019 CU14 or CU15; or Subscription Edition RTM). The key requirement is that the attacker already has valid credentials—this is not a “random outsider with no access” scenario. Treat it as a risk when the attacker can reach Exchange in your environment and has an account that can issue the needed requests.

The verdict is RED because the flaw allows an authorized attacker to escalate privileges over a network by forcing Exchange to make unauthorized internal requests. Even though confirmed “in the wild” details aren’t clearly dated in the reporting you provided, the patch-focused activity (including attention tied to a major threat actor) makes timely remediation important.

1. Identify exposure

   • On the Exchange servers, determine the exact installed build/version.
   • Confirm whether you are on one of these affected releases:
     • Microsoft Exchange Server 2016 Cumulative Update 23
     • Microsoft Exchange Server 2019 Cumulative Update 14
     • Microsoft Exchange Server 2019 Cumulative Update 15
     • Microsoft Exchange Server Subscription Edition RTM

2. Deploy the fixed update (no exceptions)

   • If you match an affected release, upgrade to the fixed version provided:
     • 2016 CU23 → 15.01.2507.072
     • 2019 CU14 → 15.02.1544.044
     • 2019 CU15 → 15.02.1748.049
     • Subscription Edition RTM → 15.02.2562.046
   • During planning, coordinate maintenance windows because Exchange updates may require service restarts.

3. Verify after installation

   • Re-check the Exchange build number to ensure the fixed version is actually installed.
   • Confirm Exchange services are running normally and mail flow is working as expected.

4. If patching is delayed (temporary containment)

   • Reduce the chance that an attacker with credentials can reach Exchange services from untrusted networks.
   • Apply strict access controls and monitor for unusual authenticated activity against Exchange endpoints.
   • Prioritize accelerating patch deployment once any signs of account compromise or suspicious login behavior appear.

5. Monitor after remediation

   • Watch authentication logs for anomalous behavior from accounts (new IPs, abnormal times, repeated failures followed by success).
   • Monitor Exchange-related system logs for unexpected internal-request-like behavior and privilege changes consistent with escalation attempts.

CISA due date

• Not provided here (this issue is not listed in CISA KEV in the findings you shared).

Severity and type: CVE-2026-65813 is an elevation of privilege issue (CWE-918) affecting Microsoft Exchange Server deployments. The confirmed mechanism from the findings is that an authorized attacker can send crafted network requests that force the server to interact with internal services, enabling privilege escalation without any other user action.

Attack requirements / reachability: Authentication is required (findings state an attacker must have valid user credentials on the target system). No user interaction is required. Exact “reachable in default configuration” is not known from the provided findings.

Exploitation status: CISA KEV is not listed, and no clear dated press claim of exploitation is provided; no public exploit code is on record in the supplied findings. However, the issue is treated as urgent in this workflow because it is explicitly tied to patch-focused threat-actor attention (PULSE) and the business risk of credential-based escalation is high.

EPSS: A prediction was provided (flat trend), but this public guidance does not rely on EPSS for urgency because KEV/news/confirmed exploitation details are not established in the provided findings.

What to look for technically: signs that an authenticated account is able to trigger Exchange to make requests to internal resources, followed by changes in authorization/privilege level.