CVE-2026-45504, Exchange SSRF That Becomes File Read

CVE-2026-45504 is a high-severity server-side request forgery flaw in Microsoft Exchange Server. The official NVD record describes it as SSRF that allows an authorized attacker to elevate privileges over a network, with a CVSS 3.1 base score of 8.8 and a vector of AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. NVD also maps the weakness to CWE-918, the standard category for server-side request forgery. Microsoft’s affected-version data, as carried in the CVE record, includes vulnerable builds of Exchange Server 2016 CU23, Exchange Server 2019 CU14, Exchange Server 2019 CU15, and Exchange Server Subscription Edition RTM below their June 2026 security update levels. (NVD)

The important nuance is that the official record and the public technical research do not describe the risk in exactly the same language. The official record uses Microsoft’s conservative vulnerability taxonomy: SSRF, authorized attacker, elevation of privilege, network attack vector, low privilege requirement, no user interaction, and high impact on confidentiality, integrity, and availability. HawkTrace’s public technical analysis describes a more concrete path in which Exchange’s handling of EWS reference attachments and WOPI-related preview logic can be steered into local file reads when an attacker-controlled endpoint returns a קובץ scheme URL. That research should not be inflated into a claim of unauthenticated remote code execution, but it does change how defenders should treat the vulnerability: file-read-capable SSRF in Exchange is not a routine patch note. It deserves fast version verification, safe retesting, log review, and egress hardening. (NVD)

Microsoft shipped June 9, 2026 security updates for affected Exchange lines, with separate packages for Exchange Server Subscription Edition RTM, Exchange Server 2019 CU15, Exchange Server 2019 CU14, and Exchange Server 2016 CU23. Microsoft’s support pages list CVE-2026-45504 among the addressed vulnerabilities and recommend running the Exchange Server Health Checker after installation to verify successful deployment and identify any additional actions. Those pages also point administrators toward Extended Protection as an Exchange hardening measure, although Extended Protection should be understood as an authentication-relay defense and not as a substitute for the CVE-2026-45504 security update. (Microsoft Support)

The shortest practical assessment is this: if you run affected Exchange versions and expose EWS, OWA, or attachment-preview workflows to users, treat CVE-2026-45504 as urgent even though authentication is required. Many Exchange environments contain thousands of ordinary mailbox users, service accounts, shared mailbox users, delegated identities, and legacy application accounts. “Authorized attacker” is a lower bar than it sounds when the vulnerable component sits in an internet-facing mail system used by every employee.

What is publicly confirmed

The cleanest way to reason about CVE-2026-45504 is to separate official facts from public exploit-path research and from claims that still require caution.

Topic	What can be stated confidently	מדוע זה חשוב
סוג הפגיעות	Server-side request forgery in Microsoft Exchange Server	SSRF lets an attacker influence server-side requests rather than only client-side browser behavior.
Official impact	Authorized attacker can elevate privileges over a network	The issue is not documented as unauthenticated in the official record.
CVSS	CVSS 3.1 base score 8.8, High	The score reflects network reachability, low complexity, low privileges, no user interaction, unchanged scope, and high CIA impact.
Weakness mapping	CWE-918	CWE-918 is the standard SSRF weakness category.
Affected products	Exchange Server 2016 CU23, Exchange Server 2019 CU14, Exchange Server 2019 CU15, Exchange Server Subscription Edition RTM below fixed builds	Patch selection depends on the exact Exchange line and cumulative update.
Public research	HawkTrace describes a file-read path involving EWS ReferenceAttachment, WOPI/WAC preview behavior, an attacker-controlled endpoint, and insufficient scheme validation	This is the detail that turns the defensive priority from “SSRF patch” into “possible local file read exposure.”
Public PoC	HawkTrace published a public GitHub repository for CVE-2026-45504	Public exploit code lowers the operational barrier for testing and abuse, even when authentication is required.
Claims to avoid	Confirmed unauthenticated RCE, confirmed mass exploitation, confirmed CISA KEV status	Those claims require evidence that the current public sources do not establish.

NVD published the CVE record on June 9, 2026 and lists Microsoft’s advisory as the vendor reference. The same record includes affected-version thresholds for each supported Exchange line. HawkTrace’s technical analysis adds the file-read narrative, describing the flaw as a missing scheme validation issue in a WebApplicationUrl returned from an attacker-controlled WOPI endpoint. (NVD)

That split matters for incident response. A security team should not overstate what is proven, but it should also not wait for a perfect exploit narrative before patching. Exchange is a high-value system, Exchange SSRF has a long history of becoming more dangerous when chained with other behaviors, and public proof-of-concept material changes attacker economics.

Affected Exchange versions and fixed builds

The affected-build thresholds carried in the CVE record line up with Microsoft’s June 2026 Exchange security update pages. For defenders, the operational task is not to memorize the CVE description. It is to identify the exact Exchange line, cumulative update, installed security update, and fixed build target.

Exchange line	Vulnerable versions according to public CVE data	June 2026 update path	Fixed build threshold
Exchange Server Subscription Edition RTM	Versions earlier than 15.02.2562.043	KB5094139	15.02.2562.043
Exchange Server 2019 CU15	Versions earlier than 15.02.1748.046	KB5094140	15.02.1748.046
Exchange Server 2019 CU14	Versions earlier than 15.02.1544.041	KB5094142	15.02.1544.041
Exchange Server 2016 CU23	Versions earlier than 15.01.2507.069	KB5094144	15.01.2507.069

Microsoft’s Exchange Subscription Edition update page lists KB5094139 as the June 9, 2026 security update and includes CVE-2026-45504 among the resolved vulnerabilities. Microsoft’s Exchange Server 2019 CU14 and Exchange Server 2016 CU23 pages likewise list CVE-2026-45504 in their June 2026 Exchange security updates. (Microsoft Support)

The lifecycle detail matters. Microsoft’s Exchange 2019 CU15 support page notes that Exchange Server 2016 and Exchange Server 2019 have reached end of support and that organizations not eligible for Extended Security Updates should move to Exchange Server Subscription Edition. That makes CVE-2026-45504 not only a patching problem but also a platform-support problem for organizations still carrying old Exchange deployments. (Microsoft Support)

Many real Exchange incidents happen in the space between “a patch exists” and “this estate can actually receive it.” Exchange 2016 and 2019 environments that are not covered by the right support path may find themselves with known affected versions and no clean long-term answer except migration. If an organization delays migration, it should at least isolate internet exposure, restrict administrative paths, monitor EWS and OWA aggressively, and document the residual risk.

Why SSRF in Exchange deserves special treatment

OWASP defines SSRF as a condition where a web application fetches a remote resource without adequately validating a user-supplied URL, allowing an attacker to coerce the application into sending a crafted request to an unexpected destination. OWASP also points out why the issue is dangerous even when a firewall, VPN, or access-control list sits in front of internal resources: the request originates from the trusted server, not from the attacker’s machine. (owasp.org)

That general SSRF model becomes more dangerous in Exchange for four reasons.

First, Exchange is usually a trust hub. It sits close to identity, mailboxes, address books, authentication flows, compliance archives, mobile access, and sometimes hybrid cloud connectors. A server-side request issued by Exchange is not equivalent to a request issued by a random browser. It originates from infrastructure that other systems may trust.

Second, Exchange has many legitimate reasons to fetch, transform, preview, proxy, or process content. OWA, EWS, attachment handling, calendar features, document preview, and Office integration all create a complex surface area. A vulnerable request path can hide inside functionality that looks normal from a user’s perspective.

Third, Exchange is often exposed to the internet by design. Even organizations that restrict administrative access may still expose OWA, EWS, Autodiscover, ActiveSync, or hybrid-related endpoints. An attacker with any valid mailbox credential may not need internal network access to reach the relevant application paths.

Fourth, SSRF is rarely only about HTTP. Defenders often think of SSRF as “make the server call an internal URL.” That is incomplete. MDN describes SSRF as a vulnerability that allows an attacker to make network requests to arbitrary destinations from the server itself, which often has broader access than an external client. HawkTrace’s research is important precisely because it describes a CVE-2026-45504 path where Exchange appears to process a קובץ scheme URL in a WOPI-related flow rather than limiting the destination to safe web schemes. (מסמכי MDN Web)

A safe mental model is simple: the dangerous request is not the browser’s request to Exchange. It is Exchange’s request to somewhere else. If an attacker can influence that second request, the Exchange server becomes the attacker’s network and filesystem vantage point.

How the file-read path appears to work

HawkTrace’s analysis describes CVE-2026-45504 as an Exchange file-read issue reachable through SSRF. The write-up focuses on Exchange behavior involving EWS ReferenceAttachment creation, a ProviderEndpointUrl controlled by the attacker, WOPI-related target property retrieval, and a WebApplicationUrl value returned by the attacker-controlled service. According to that analysis, the key failure is missing scheme validation before Exchange opens the returned URL. (HawkTrace)

The practical chain can be understood at a defensive level as follows:

1. The attacker has a valid low-privileged Exchange account or another authorized path that can create a relevant EWS item.
2. The attacker creates or manipulates a reference attachment so that Exchange later reaches out to an attacker-controlled provider endpoint.
3. A preview or attachment-processing path triggers Exchange to request WOPI-related properties from the attacker-controlled endpoint.
4. The attacker-controlled endpoint returns a URL using an unsafe scheme, described in public research as a קובץ URL.
5. Exchange processes the returned URL in a way that causes the server to read a local file and return data through the attacker-influenced flow.

That description is enough for defenders to reason about logs and controls. It is not necessary, and not advisable, to reproduce public exploit commands in a production environment. Public exploit material confirms that working proof-of-concept code exists, but production validation should use patch-state checks, lab reproduction, and non-sensitive canaries rather than real file reads. (HawkTrace)

The most interesting technical detail in the public analysis is the interaction between URL scheme handling and fragment behavior. HawkTrace states that a returned WebApplicationUrl can use a local file scheme and that fragment handling influences how appended parameters are interpreted. The consequence described by the researchers is that Exchange opens the local file path and returns the file contents. (HawkTrace)

For defenders, the lesson is broader than one Exchange bug. Any system that accepts a URL from an external or semi-external trust boundary and then fetches it from a privileged server process must validate more than string shape. It must validate scheme, host, port, redirects, DNS resolution, canonicalized path, and response handling. OWASP’s SSRF prevention material emphasizes allow lists and defensive controls rather than relying on brittle deny lists or narrow pattern matching. (סדרת דפי העזר של OWASP)

A safe mental model for CVE-2026-45504 looks like this:

Authorized user action
        |
        v
Exchange EWS object with reference attachment metadata
        |
        v
Exchange server-side request to provider or WOPI-related endpoint
        |
        v
Attacker-controlled response supplies unsafe URL scheme
        |
        v
Exchange opens unexpected local or server-side resource
        |
        v
Sensitive file content may flow back through the vulnerable path

That flow is intentionally abstract. It helps defenders identify where evidence may appear without encouraging unsafe use of public exploit code.

Why “authentication required” does not make this low risk

The official CVSS vector for CVE-2026-45504 includes PR:L, meaning low privileges are required. That lowers exposure compared with a no-authentication vulnerability, but it does not make the issue harmless. (NVD)

Exchange accounts are not rare. A normal organization may have employees, contractors, help-desk mailboxes, service accounts, shared mailboxes, third-party integration accounts, test users, legacy accounts, synchronized hybrid identities, and compromised credentials from unrelated phishing campaigns. Any vulnerability reachable by a normal authenticated mailbox user deserves attention when the target system is an internet-facing Exchange server.

The history of Exchange exploitation supports that caution. CVE-2021-26855, part of the ProxyLogon chain, was an Exchange SSRF issue that became one component of a major exploitation wave. CVE-2022-41040, one half of the ProxyNotShell pair, was another Exchange SSRF issue, and Microsoft described it alongside CVE-2022-41082, a remote code execution vulnerability reachable when PowerShell was accessible to the attacker. (WIRED)

CVE-2026-45504 is not ProxyLogon or ProxyNotShell. The point is not to merge different vulnerabilities into one story. The point is that Exchange SSRF issues repeatedly matter because Exchange is a high-trust, high-value system and because SSRF often becomes dangerous through context, chaining, and the permissions of the server process.

What local file read could mean in practice

A local file-read primitive is not automatically a full system compromise. It depends on the process identity, filesystem permissions, target path, application behavior, and what secrets are stored on disk. Still, it can be severe.

In an Exchange environment, defenders should think about several categories of possible exposure if credible evidence suggests exploitation:

File or data category	Why an attacker might care	Defensive response if exposure is plausible
Application configuration files	May contain paths, configuration details, service settings, or references to secrets	Review access telemetry, compare file timestamps, and rotate secrets if they could be recovered indirectly.
Web or service configuration	May reveal internal hostnames, auth settings, or integration details	Treat as reconnaissance exposure and update threat models for lateral movement.
Logs	May contain usernames, endpoints, request artifacts, tokens, or operational details	Determine whether logs include sensitive values and reduce future logging of secrets.
Certificate or key material	High impact if readable by the Exchange process and stored insecurely	Rotate affected certificates or keys, and investigate private-key exportability.
Script or automation files	May reveal credentials or administrative workflows	Remove hardcoded secrets and migrate to managed secret storage.
Local system files	May assist environment fingerprinting or chained exploitation	Correlate with other host telemetry and tighten least privilege.

This table should not be read as a claim that CVE-2026-45504 can read every file on every Exchange server. The reachable files depend on the vulnerable code path and the privileges of the process opening the URL. The correct incident-response posture is conditional: if exploitation is confirmed or strongly suspected, treat files readable by the relevant Exchange process as potentially exposed until telemetry and permissions prove otherwise.

The public HawkTrace analysis uses a benign Windows file as an example target, which is a common way to demonstrate local file read without immediately targeting secrets. In production, defenders should avoid “testing” by reading sensitive files. Safer validation options are discussed below. (HawkTrace)

Patch verification should start with build state, not exploit attempts

The fastest safe test for CVE-2026-45504 is not a PoC. It is a version and update check.

On an Exchange server, start with the Exchange Management Shell and enumerate Exchange build information:

Get-ExchangeServer |
    Select-Object Name, Edition, AdminDisplayVersion |
    Format-Table -AutoSize

Then map each server to the correct Exchange line and update target. For June 2026, the relevant fixed targets are the Subscription Edition RTM update, Exchange 2019 CU15 update, Exchange 2019 CU14 update, and Exchange 2016 CU23 update listed by Microsoft’s support pages and CVE affected-version thresholds. (Microsoft Support)

Microsoft’s Health Checker is the next step. Microsoft’s HealthChecker documentation includes a Vulnerability Report mode and shows the .\HealthChecker.ps1 -VulnerabilityReport command for running vulnerability reporting across Exchange servers. (Microsoft GitHub)

A typical post-update workflow looks like this:

# Run from an elevated Exchange Management Shell

Set-ExecutionPolicy RemoteSigned -Scope Process

.\HealthChecker.ps1

.\HealthChecker.ps1 -VulnerabilityReport

For larger estates, Microsoft’s documentation includes examples for running HealthChecker across Exchange servers and building an HTML report. A practical change-control package should include the pre-update build, post-update build, HealthChecker output, restart confirmation, event log review, and any manual actions required by the update notes. (Microsoft GitHub)

Installer integrity checks are also worth keeping in the record. A local verification command is simple:

Get-FileHash .\Exchange2019-KB5094140-x64-en.exe -Algorithm SHA256

Compare the output with the hash on the relevant Microsoft support page before installation or before preserving evidence for audit. Microsoft lists the June 2026 Exchange security update packages on the respective support pages for Subscription Edition RTM, Exchange 2019 CU14, and Exchange 2016 CU23. (Microsoft Support)

Safe validation versus unsafe validation

A public PoC exists, but the presence of exploit code does not mean defenders should run it against production systems. The goal is to prove patch state and exposure, not to create a second incident.

Validation activity	Safe for production	למה
Confirm Exchange version and build	כן	Uses administrative inventory rather than exploit behavior.
Install the correct June 2026 security update	Yes, with normal change control	This is the vendor remediation path.
Run HealthChecker and VulnerabilityReport	כן	Microsoft documents HealthChecker’s vulnerability reporting mode.
Search logs for suspicious EWS, WOPI, and attachment-preview patterns	כן	Passive review does not trigger the vulnerability.
Reproduce the issue in an isolated lab with a non-sensitive canary file	Yes, if authorized and isolated	Confirms understanding without exposing production secrets.
Run public PoC against production to read a real local file	לא	Creates data exposure and may violate policy or law.
Scan third-party Exchange servers for CVE-2026-45504	לא	Unauthorized testing is not legitimate validation.
קרא web.config, certificate stores, or credential-bearing files as a “test”	לא	Successful testing becomes credential exposure.

For organizations with a mature security validation process, the safest pattern is to reproduce the behavior in a lab that mirrors the affected Exchange build, then use production checks only to confirm that production is no longer in the vulnerable build range. If a production exploit test is absolutely required under a formal internal authorization process, the target should be a deliberately created non-sensitive canary artifact, not a real secret or system file.

Teams using AI-assisted testing should be especially careful here. An agentic workflow can accelerate asset discovery, version mapping, evidence collection, and report generation, but it should not be allowed to turn a public PoC into broad, unsupervised file-read attempts. In authorized workflows, Penligent can be used to structure attack-surface inventory, CVE validation steps, evidence capture, and retest reporting under human review, but the proof target for this type of issue should remain controlled and non-sensitive. (Penligent)

Detection strategy for CVE-2026-45504

Detection has three layers: application logs, network egress, and host telemetry. No single layer is enough.

Application logs help identify who triggered relevant Exchange paths and when. Network egress helps identify Exchange reaching out to unusual external hosts. Host telemetry helps identify whether Exchange-related processes accessed local files that are unusual for the normal workload. The most useful investigation combines all three around the same time window.

The public research names several meaningful artifacts for defenders: EWS ReferenceAttachment, ProviderEndpointUrl, WOPI target property retrieval, and a WebApplicationUrl that can carry an unsafe scheme. Those terms do not guarantee exploitation by themselves, but they are useful pivots when searching logs, request bodies, proxy records, and EDR telemetry. (HawkTrace)

A simple Windows search over common log locations might look like this:

$logPaths = @(
    "C:\inetpub\logs\LogFiles\W3SVC1\*.log",
    "C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Ews\*.log",
    "C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Owa\*.log",
    "C:\Program Files\Microsoft\Exchange Server\V15\Logging\OWA\*.log"
)

$patterns = @(
    "/EWS/Exchange.asmx",
    "ReferenceAttachment",
    "ProviderEndpointUrl",
    "GetWopiTargetPropertiesByUrl",
    "WebApplicationUrl",
    "file:",
    "file%3a",
    "%66%69%6c%65"
)

foreach ($path in $logPaths) {
    if (Test-Path $path) {
        Select-String -Path $path -Pattern $patterns -SimpleMatch |
            Select-Object Path, LineNumber, Line |
            Export-Csv ".\exchange-cve-2026-45504-log-hits.csv" -NoTypeInformation -Append
    }
}

This is not a perfect detector. It is a triage helper. Exchange logs may not contain request bodies, URL parameters may be encoded differently, and legitimate Office integration can produce WOPI-related traffic. Treat hits as pivots for deeper review, not as proof of compromise.

In Microsoft Sentinel or another KQL-based environment, a defender might start with a broad query against IIS-style logs and proxy telemetry:

let suspicious_terms = dynamic([
    "ReferenceAttachment",
    "ProviderEndpointUrl",
    "GetWopiTargetPropertiesByUrl",
    "WebApplicationUrl",
    "file:",
    "file%3a"
]);
IISLogs
| where TimeGenerated > ago(30d)
| where csUriStem has_any ("/EWS/Exchange.asmx", "/owa", "/ecp")
   or csUriQuery has_any (suspicious_terms)
| project TimeGenerated, sIP, csUserName, csMethod, csUriStem, csUriQuery, scStatus, csUserAgent, cIP
| order by TimeGenerated desc

In Splunk, the first-pass equivalent might look like this:

index=exchange sourcetype IN ("iis", "ms:iis:auto", "exchange:http_proxy")
earliest=-30d
(
  uri_path="/EWS/Exchange.asmx"
  OR uri_path="*/owa*"
  OR uri_query="*ProviderEndpointUrl*"
  OR uri_query="*ReferenceAttachment*"
  OR uri_query="*GetWopiTargetPropertiesByUrl*"
  OR uri_query="*file%3a*"
  OR uri_query="*file:*"
)
| table _time host clientip user method uri_path uri_query status useragent
| sort - _time

These examples should be tuned to the actual log schema. Some environments put request parameters in cs-uri-query, some normalize them into uri_query, and some discard them. If your edge proxy, WAF, or load balancer terminates TLS before Exchange, those logs may be more useful than the local IIS logs.

Network egress signals

SSRF often becomes visible as unusual outbound traffic from a server that normally receives inbound traffic. CVE-2026-45504 is no exception. If Exchange reaches out to an attacker-controlled WOPI-like endpoint, the outbound request may appear in firewall, proxy, DNS, or EDR network telemetry.

Useful pivots include:

אות	מדוע זה חשוב	False-positive considerations
Exchange server initiates HTTP or HTTPS to an unfamiliar external domain	Public research describes Exchange requesting attacker-controlled WOPI-related properties	Exchange may legitimately contact Microsoft, hybrid services, antispam, monitoring, or third-party integrations.
Outbound request occurs immediately after EWS or OWA attachment activity	Timing correlation strengthens the hypothesis	Busy mail systems produce dense activity; correlate with user and endpoint.
External host serves WOPI-like paths but is not an approved Office or document service	Suspicious provider endpoint behavior	Some business applications integrate with Office preview features.
DNS lookups from Exchange to newly registered or low-reputation domains	Common attacker infrastructure pattern	Reputation data can be incomplete or biased.
Exchange process opens unusual local files around the same time	File-read exploitation would need process-level file access	EDR must record file access with process context to be useful.

A useful egress-control rule is not “block Exchange from the internet” in every organization. Exchange deployments differ. A more realistic target is to make Exchange outbound access explicit: proxy it, log it, restrict it to business-required destinations, and alert when it reaches unapproved hosts directly. OWASP’s SSRF prevention guidance recommends network-layer controls, allow lists, and defensive validation as part of SSRF defense. (סדרת דפי העזר של OWASP)

One caveat is important. Network egress filtering can stop or reveal a request from Exchange to an attacker-controlled web host. It does not directly prevent a local קובץ scheme access once vulnerable code has accepted such a URL. That is why patching and scheme validation are the core fix, while egress controls are compensating controls and detection aids.

Host telemetry and file access review

If EDR or Sysmon-like telemetry is available, look for Exchange-related processes accessing files that do not match normal behavior. The exact process name and path may vary by Exchange role, configuration, and version, so defenders should avoid rigid assumptions. Focus on correlation:

1. Was there suspicious EWS or OWA activity?
2. Did the same user or mailbox create unusual reference attachments?
3. Did Exchange reach out to an unfamiliar host?
4. Did an Exchange process access an unusual local file immediately afterward?
5. Did the host generate errors, warnings, or unusual application events around the same time?

A sample Microsoft Defender-style hunting query might look conceptually like this:

DeviceFileEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName has_any ("w3wp.exe", "Microsoft.Exchange")
| where FolderPath has_any (
    "\\Windows\\",
    "\\Program Files\\Microsoft\\Exchange Server\\",
    "\\inetpub\\"
)
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
          FolderPath, FileName, ActionType, AccountName
| order by Timestamp desc

This query is deliberately broad. A production version should be tuned against baseline behavior. Exchange normally reads many files. The suspicious cases are not “Exchange read a file” in isolation; they are “Exchange read an unusual file at the same time as suspicious EWS/WOPI behavior and abnormal outbound traffic.”

Practical incident triage

A realistic incident triage workflow for CVE-2026-45504 should move from inventory to logs to secrets. Do not start by assuming compromise. Do not end at patching if logs suggest prior exploitation.

שלב	Question	Evidence to collect
1	Which Exchange servers exist?	CMDB, AD, Exchange Management Shell output, load balancer pools.
2	Which builds are installed?	Get-ExchangeServer, HealthChecker output, installed updates.
3	Are vulnerable builds internet-facing?	Firewall rules, DNS, reverse proxy, WAF, load balancer config.
4	Are EWS and OWA exposed?	IIS bindings, virtual directory settings, proxy routes, external URLs.
5	Were there suspicious EWS or reference attachment patterns?	IIS, HttpProxy, OWA, EWS, WAF logs.
6	Did Exchange make unusual outbound requests?	DNS, proxy, firewall, EDR network events.
7	Did Exchange access unusual local files?	EDR file events, Sysmon, Windows event logs where available.
8	Could secrets have been read?	Configuration review, file ACLs, service account inventory, certificate storage.
9	What must be rotated?	Credentials, API keys, certificates, service-account passwords.
10	Has the fix been verified?	Post-update build, HealthChecker -VulnerabilityReport, change record.

If you find evidence that a local file read occurred, the next question is not only “what file was read?” It is also “what could an attacker do with the data in that file?” A configuration file may reveal internal hostnames. A log may reveal usernames and tokens. A script may reveal credentials. A certificate file may become critical if the private key is exportable or stored insecurely. Incident response should follow the value of the exposed data, not merely the exploit primitive.

Patch deployment details that matter

Exchange security updates are cumulative within the relevant CU line, but they are not interchangeable across different Exchange lines and cumulative updates. Installing the wrong package is not a shortcut. The Microsoft update pages list separate June 2026 Exchange updates for Subscription Edition RTM, Exchange 2019 CU14, and Exchange 2016 CU23, and the CVE data separately identifies Exchange 2019 CU15 as affected below its fixed build threshold. (Microsoft Support)

The same June 2026 Exchange update context includes a subtle but important note: Microsoft’s support page says the fix for CVE-2026-45583 is not included in the Security Update and that administrators should follow the CVE documentation for that vulnerability. That is a warning against “patch by headline” behavior. Administrators must confirm each CVE’s remediation path, not assume every item in an update page is remediated by the same installer. (Microsoft Support)

Microsoft’s update pages also recommend enabling Extended Protection in Exchange Server. Extended Protection is valuable hardening because it improves Windows authentication protections and helps mitigate authentication relay and man-in-the-middle risks. It should not be represented as the direct fix for CVE-2026-45504. The direct fix is the relevant Exchange security update. (Microsoft Support)

Why attachment preview and WOPI-style flows are hard to defend

Attachment preview is a usability feature that creates security complexity. Users expect to click a document and see a preview. The server may need to inspect metadata, resolve references, call document services, create preview URLs, or interact with Office-oriented protocols. That is where trust boundaries blur.

Microsoft’s WOPI documentation describes the Web Application Open Platform Interface protocol as a way for Microsoft 365 for the web to access and change files stored in another service. The protocol itself is legitimate and widely used for document integration. CVE-2026-45504 is not a claim that WOPI is inherently unsafe; it is a reminder that URL-returning and document-preview flows must enforce strict trust boundaries. (Microsoft Learn)

The public HawkTrace research describes the vulnerable Exchange behavior as missing scheme validation on a WebApplicationUrl returned from an attacker-controlled WOPI endpoint. In other words, the dangerous transition is not simply “Exchange supports attachments.” It is “a server-side document workflow accepts a returned URL in a sensitive context without rejecting an unsafe scheme.” (HawkTrace)

Defenders should therefore avoid simplistic controls that break business workflows without reducing the real risk. Disabling broad Exchange features may not be feasible. A better long-term pattern is to make server-side URL fetching boring and constrained:

1. Only allow expected schemes, usually HTTPS.
2. Only allow expected hosts or service classes.
3. Resolve and canonicalize destinations before connection.
4. Re-check after redirects.
5. Block link-local, loopback, private, and metadata ranges unless specifically required.
6. Do not return raw server-side fetch responses to users.
7. Log the final resolved destination, not just the original input.
8. Test URL parsers with encoded, redirected, and scheme-smuggling variants.

OWASP’s SSRF guidance recommends allow lists and layered controls where the expected target set is known. Those recommendations are directly relevant to the design class behind CVE-2026-45504 even if administrators cannot patch Exchange source code themselves. (סדרת דפי העזר של OWASP)

Common mistakes during CVE-2026-45504 response

The first mistake is treating CVE-2026-45504 as a generic “authenticated only” issue. Low-privileged Exchange access is common, and credential theft is common. Authentication reduces the attacker pool; it does not make the vulnerability operationally unimportant.

The second mistake is validating by exploitation. Reading a sensitive file on a production Exchange server can create the same exposure you are trying to prevent. Use version checks, HealthChecker, logs, and lab canaries.

The third mistake is patching only the internet-facing Exchange server while ignoring internal Exchange servers. Internal Exchange hosts may still be reachable through compromised accounts, VPNs, hybrid paths, or lateral movement. Inventory all Exchange servers.

The fourth mistake is relying on Extended Protection as the fix. Extended Protection is valuable for authentication relay hardening, but Microsoft’s CVE-2026-45504 remediation path is the Exchange security update.

The fifth mistake is reviewing only inbound logs. SSRF is about server-side outbound behavior. Firewall, proxy, DNS, and EDR network telemetry are often the best way to see the server acting as a client.

The sixth mistake is assuming file read has no downstream impact. A single readable configuration file can expose internal topology, service names, credentials, or secrets that help the next stage of an intrusion.

Related Exchange CVEs that clarify the risk

CVE-2026-45504 sits in a long Exchange security history where SSRF, EWS, OWA, and server-side processing flaws have produced outsized risk. The relevant comparison is not “these bugs are identical.” They are not. The value is in understanding recurring patterns.

CVE	Why it is relevant	Key difference from CVE-2026-45504
CVE-2021-26855	A major Exchange SSRF issue associated with the ProxyLogon exploitation chain	It was part of a different chain and a different exploitation era. Do not copy assumptions from ProxyLogon into 2026 without evidence.
CVE-2022-41040	An Exchange SSRF issue associated with ProxyNotShell and discussed with CVE-2022-41082 RCE	ProxyNotShell’s impact depended on chaining and PowerShell access conditions.
CVE-2026-42897	A 2026 Exchange OWA issue that created a separate patch-window and mitigation problem	XSS or spoofing is a different bug class, but it affects the same operational patching and Exchange exposure management problem.
CVE-2026-45583	Listed in Microsoft’s June 2026 Exchange pages, with Microsoft noting that its fix is not included in the Security Update	It should be tracked separately, not assumed to be remediated by the same action as CVE-2026-45504.

CVE-2021-26855 is the historical warning sign. It showed how Exchange SSRF can be part of a high-impact intrusion path when the vulnerable server sits at a trusted network and identity boundary. CVE-2022-41040 is the closer conceptual comparison for “authenticated does not mean minor,” because Microsoft and security researchers described it as an Exchange SSRF paired in real-world discussion with CVE-2022-41082 RCE. (WIRED)

CVE-2026-42897 is useful as an operational contrast because it sits in the same Exchange risk-management universe but involves a different class of vulnerability. Penligent’s separate write-up on CVE-2026-42897 focuses on Exchange OWA XSS and the defensive problem of separating confirmed facts from assumptions during Exchange patch windows. For teams managing Exchange risk in 2026, the pattern is clear: do not handle Exchange CVEs as isolated tickets if they share exposed endpoints, user workflows, patch dependencies, and evidence sources. (Penligent)

CVE-2026-45583 adds another caution. Microsoft’s June 2026 Exchange update pages list it among the CVEs in the security update context but explicitly note that the fix for CVE-2026-45583 is not included in the security update and that administrators should follow the CVE documentation for mitigation. That is exactly the kind of detail that gets lost when teams patch by headline instead of reading the update notes. (Microsoft Support)

Hardening after the patch

Patching is the first move, not the whole defense. CVE-2026-45504 points to several hardening priorities that remain useful after the specific Exchange build is fixed.

Start with exposure control. Confirm whether EWS and OWA need to be reachable from the public internet. If they do, put them behind the strongest feasible access controls, conditional access, device posture checks, WAF or reverse proxy logging, and rate limiting. If they do not, remove unnecessary exposure.

Next, restrict Exchange outbound traffic. Mail servers often need DNS, SMTP, Microsoft services, monitoring, update infrastructure, hybrid connectors, and security integrations. They usually do not need arbitrary direct outbound HTTP or HTTPS to the internet. Force outbound web traffic through a proxy where possible, log it, and define allow lists for known business destinations.

Then, review service account and mailbox hygiene. Because CVE-2026-45504 requires authorization, compromised low-privileged accounts are part of the threat model. Disable stale accounts, reduce shared credentials, enforce MFA where applicable, monitor impossible travel and abnormal mailbox behavior, and review application accounts with EWS access.

Finally, improve file-secret hygiene on Exchange servers. If a local file read vulnerability can expose secrets, the environment should be designed so that files readable by the application process do not contain reusable credentials. Move secrets to managed stores, reduce hardcoded credentials in scripts, rotate legacy passwords, and restrict private key exportability.

A defender’s playbook for the first 24 hours

For teams that need a concrete response plan, the first 24 hours should focus on decisions that materially reduce risk.

Hour 0 to 2, establish exposure

Run Exchange inventory, identify external endpoints, and classify servers by version. Record the exact Exchange line, CU, installed security update, and whether the server is internet-facing.

Get-ExchangeServer |
    Select-Object Name, ServerRole, Edition, AdminDisplayVersion |
    Sort-Object Name |
    Format-Table -AutoSize

Hour 2 to 6, patch or isolate

Install the correct June 2026 security update where possible. If a server cannot be patched immediately, reduce exposure. Remove unnecessary public access, restrict EWS and OWA behind stronger controls, and limit outbound web access from Exchange until the update is complete.

Hour 6 to 10, verify

Run HealthChecker and a vulnerability report. Preserve output for incident and audit records.

.\HealthChecker.ps1
.\HealthChecker.ps1 -VulnerabilityReport

Microsoft’s documentation shows HealthChecker’s vulnerability-report mode and Microsoft’s June 2026 update pages recommend using Health Checker after installing the security update. (Microsoft GitHub)

Hour 10 to 18, hunt

Search 30 to 90 days of logs, depending on retention. Start with EWS, OWA, WOPI, unusual outbound destinations, and local file access events. Correlate events around user identity, IP address, mailbox activity, and Exchange process behavior.

Hour 18 to 24, decide whether this is only remediation or also incident response

If there are no suspicious indicators, document the patch and continue monitoring. If there are credible signs of file-read exploitation, open an incident. Identify potentially exposed files, rotate affected secrets, review mailbox accounts involved, preserve logs, and check for lateral movement.

A deeper playbook for mature teams

Mature teams should go further than “install KB and close ticket.” Exchange vulnerabilities are infrastructure events. They deserve repeatable validation and evidence.

A good control record should answer:

1. Which Exchange servers existed at the time of disclosure?
2. Which were vulnerable by build number?
3. Which were externally reachable?
4. Which had EWS, OWA, or attachment preview exposure?
5. Which update package was installed?
6. Was the installer hash verified?
7. What was the post-update build?
8. What did HealthChecker report?
9. What logs were reviewed?
10. Were any suspicious events found?
11. If yes, what files or secrets might have been exposed?
12. What was rotated or contained?
13. Who approved the residual risk?

This type of record is especially important for organizations under SOC 2, ISO 27001, government, financial, or customer contractual obligations. The key evidence is not a screenshot saying “patched.” It is a chain: inventory, affected-state determination, remediation, verification, detection review, and risk decision.

For AI-assisted validation workflows, the right guardrails are simple: constrain the target scope, forbid sensitive file-read tests in production, require human approval for any active validation, and generate evidence that a reviewer can understand. Automated reasoning is useful for correlating versions, KBs, logs, and patch states. It is dangerous when it turns into unbounded exploit execution.

What security teams should monitor after patching

CVE-2026-45504 patching reduces the known vulnerable behavior, but post-patch monitoring still matters. A server may have been exploited before the patch. A public PoC may inspire copycat testing. Attackers may pivot from this CVE to adjacent Exchange surfaces.

Monitor the following for at least several weeks after remediation:

Monitoring area	What to watch
EWS activity	Unusual volumes, unusual user agents, unexpected attachment operations, requests from new IPs.
OWA activity	Abnormal attachment preview usage, unexpected paths, unusual client IP geography.
Outbound HTTP or HTTPS from Exchange	New domains, newly registered domains, direct-to-internet traffic bypassing proxy.
DNS from Exchange	Rare domains, high-entropy names, domains first seen around suspicious EWS activity.
Local file access by Exchange processes	Reads of unusual configuration, script, certificate, or system files.
Account activity	Low-privileged accounts creating unusual objects or accessing mailboxes outside baseline.
Error logs	Exceptions around URL parsing, WOPI handling, preview, or file access.
Update health	HealthChecker findings, failed update events, servers missing the intended build.

False positives are inevitable. The goal is not to alert on every WOPI string. The goal is to identify a small set of events where identity, endpoint, outbound destination, and host behavior line up with the known attack shape.

How to think about exploitability in your own environment

Exploitability is not binary. The same CVE can have different practical risk in two organizations.

A higher-risk environment usually has several of these traits:

1. Exchange OWA and EWS are internet-facing.
2. Legacy Exchange 2016 or 2019 servers remain in production.
3. Patch deployment depends on long maintenance windows.
4. Many low-privileged users can authenticate from the internet.
5. EWS access is broadly enabled for users and service accounts.
6. Exchange has unrestricted outbound web access.
7. Logging does not capture request query strings or outbound destinations.
8. EDR file-access telemetry is absent or short-retention.
9. Service accounts or scripts store secrets on the Exchange server.
10. The organization has weak credential hygiene or frequent mailbox compromise.

A lower-risk environment has different traits:

1. Exchange is patched to the fixed build.
2. Internet exposure is minimized or strongly mediated.
3. EWS is restricted to known clients and applications.
4. Outbound web access from Exchange is proxied and allow-listed.
5. HealthChecker output is clean and archived.
6. Logs retain enough detail for EWS, OWA, DNS, proxy, and EDR review.
7. Service-account secrets are not stored in local files.
8. Suspicious activity is correlated across identity, network, and host telemetry.

Most organizations are between those poles. The practical priority should be based on the overlap between vulnerable build, exposure, credential risk, and observability. A vulnerable but isolated lab server is not the same as a vulnerable internet-facing mailbox server with unrestricted outbound access.

What developers can learn from CVE-2026-45504

CVE-2026-45504 is an Exchange administrator problem today, but the design lessons apply to any developer building server-side integrations.

Never trust a URL simply because it came from a protocol response. If the other side of the protocol can be influenced by a user or attacker, the returned URL is input. Validate it as input.

Validate scheme first. If a workflow expects HTTPS, reject everything else before parsing deeper fields. Do not rely on later network-layer controls to fix an application-layer scheme validation bug.

Canonicalize before policy decisions. Encoded schemes, mixed-case schemes, redirects, fragments, username fields, IPv6 literals, DNS rebinding, and parser differences can all break naive checks.

Re-check after redirects. A safe initial URL can redirect to an unsafe host, private IP, loopback address, link-local address, cloud metadata endpoint, or unsupported scheme.

Do not return raw fetch results to users. Even when a server-side fetch is allowed, the response may contain data from an internal service or local resource.

Add structured logging. A useful log should include the original URL, final resolved URL, scheme, host, port, redirect chain, validation decision, user identity, and request correlation ID. Sensitive values should be redacted.

Use positive allow lists. OWASP’s SSRF prevention guidance is clear that allow lists are stronger than deny lists where the target set is known. (סדרת דפי העזר של OWASP)

These principles sound basic, but complex enterprise applications repeatedly fail at them because server-side integrations grow over years. New preview features, legacy protocol handlers, compatibility shims, and external service integrations can create unexpected paths through old code.

Why CVE-2026-45504 belongs in continuous Exchange risk management

Exchange security cannot be managed as a quarterly patch chore. The platform has a history of high-impact vulnerabilities, complex patch dependencies, and exposed endpoints. CVE-2026-45504 reinforces several recurring truths.

Exchange inventory must be current. If a team cannot answer which CU and SU each server runs, it cannot respond quickly to Exchange CVEs.

Security updates must be tested quickly but not indefinitely delayed. Exchange patches can be operationally sensitive, but the risk of slow deployment is high when public research and PoC code exist.

Detection must include outbound behavior. SSRF is not only an inbound request problem. The server becomes the client.

Credential compromise must be assumed possible. Low-privileged authentication requirements do not protect organizations that routinely face phishing, token theft, password reuse, or service-account exposure.

Evidence must be reusable. Every Exchange CVE response should improve the next one: better inventory, better logging, better patch proof, better egress policy, and better incident playbooks.

FAQ for security teams

What is CVE-2026-45504 in Microsoft Exchange Server?

• CVE-2026-45504 is a Microsoft Exchange Server server-side request forgery vulnerability.
• NVD describes it as allowing an authorized attacker to elevate privileges over a network.
• The CVSS 3.1 base score is 8.8, High.
• Public research describes a file-read path involving EWS reference attachments and WOPI-related URL handling.
• The safest defensive interpretation is: patch quickly, verify build state, review logs, and avoid production exploit testing.

Is CVE-2026-45504 remote code execution?

• The official NVD description does not label CVE-2026-45504 as remote code execution.
• It is officially described as SSRF leading to elevation of privilege.
• Public research describes local file-read behavior, not a complete unauthenticated RCE chain.
• Treat claims of confirmed RCE or mass exploitation cautiously unless supported by later vendor, CISA, or high-confidence incident-response reporting.
• File read can still be severe if configuration files, credentials, logs, certificates, or scripts are exposed.

Does an attacker need authentication?

• Yes, the official CVSS vector includes low privileges required.
• That usually means the attacker needs some authorized Exchange access or a compromised account.
• This does not make the vulnerability low risk because ordinary Exchange accounts are common.
• Phished mailbox credentials, shared accounts, legacy service accounts, and delegated users can all become practical entry points.
• Internet-facing OWA or EWS increases risk when many users can authenticate remotely.

Which Exchange versions should be checked first?

• Check Exchange Server Subscription Edition RTM below 15.02.2562.043.
• Check Exchange Server 2019 CU15 below 15.02.1748.046.
• Check Exchange Server 2019 CU14 below 15.02.1544.041.
• Check Exchange Server 2016 CU23 below 15.01.2507.069.
• Prioritize internet-facing servers, servers with EWS or OWA exposed, and legacy Exchange 2016 or 2019 deployments.
• Confirm whether Exchange 2016 or 2019 systems are eligible for Extended Security Updates or need migration planning.

How can defenders verify the patch safely?

• Use Exchange Management Shell to enumerate Exchange versions and builds.
• Install the correct Microsoft June 2026 security update for the exact Exchange line and CU.
• Run Microsoft HealthChecker and -VulnerabilityReport after installation.
• Verify installer hashes against Microsoft’s published hashes where required by change control.
• Preserve pre-update and post-update evidence.
• Avoid reading real production files as a test.

What logs are most useful for detecting suspicious activity?

• IIS logs for OWA and EWS request patterns.
• Exchange HttpProxy logs, especially EWS and OWA paths.
• WAF, reverse proxy, and load balancer logs if they capture query strings or request bodies.
• DNS, proxy, and firewall logs showing outbound requests from Exchange servers.
• EDR telemetry showing Exchange processes accessing unusual local files.
• Identity logs showing abnormal behavior by low-privileged mailbox users.
• The best signal is correlation across user action, EWS or attachment activity, outbound request, and unusual file access.

Does Extended Protection fix CVE-2026-45504?

• No, Extended Protection should not be treated as the direct fix for CVE-2026-45504.
• The direct remediation is the correct Exchange security update.
• Microsoft recommends Extended Protection as Exchange hardening because it helps mitigate authentication relay and man-in-the-middle risks.
• Enable it where supported and tested, but do not use it as a reason to delay the June 2026 Exchange security update.
• After enabling it, run validation to ensure clients, load balancers, and hybrid flows still work as intended.

What should a team do if suspicious file-read activity is found?

• Preserve logs and host telemetry before rotating systems or deleting artifacts.
• Identify the user account, client IP, Exchange endpoint, outbound destination, and time window.
• Determine which files may have been accessed and what secrets or operational details they contained.
• Rotate exposed credentials, service-account passwords, API keys, and certificates where appropriate.
• Review mailbox access and lateral movement indicators.
• Patch affected Exchange servers and verify with HealthChecker.
• Treat the event as an incident, not merely a vulnerability ticket.

Closing judgment

CVE-2026-45504 should be handled as a high-priority Exchange vulnerability because the official SSRF and elevation-of-privilege classification intersects with public research describing a local file-read path. The most defensible response is not panic and not exploit-driven validation. It is disciplined Exchange operations: identify affected builds, install the correct June 2026 security update, run HealthChecker, review EWS and OWA evidence, monitor outbound Exchange traffic, and treat any credible file-read signal as a potential secret-exposure incident.

The vulnerability also reinforces a broader engineering lesson. Server-side URL fetching must be constrained by explicit scheme and destination policy, especially in systems that process attachments, previews, and external document workflows. In Exchange, the cost of getting that boundary wrong is high because the server is not just another web application. It is a trusted communications platform, an identity-adjacent system, and a frequent target for attackers who understand that one mailbox credential can sometimes open the door to much more than email.