Technical analysis CVE-2026-45504: Small error, big risk on Microsoft Exchange

Campaign summary

CVE-2026-45504 is a serious cybersecurity vulnerability affecting on-premises (internal) Microsoft Exchange Server servers. The vulnerability allows a low-privileged but authenticated user account on the system to read sensitive system files of the Exchange server without requiring administrative rights. From reading these configuration files and identifying information, an attacker can escalate privileges to take complete control of the organization's email system.

The appearance of public exploit code (Proof-of-Concept) significantly increases the risk of attack, especially for businesses, financial institutions and state agencies that are operating the Exchange Server system in Vietnam.

Overview of Microsoft Exchange

Introduction

First, let's learn about what Microsoft Exchange is? Surely not too strange to many organizations and businesses, Microsoft Exchange Server is an email, calendar, contact and task management platform for businesses developed by Microsoft.

This system is commonly deployed as an on-premises server or integrated into the Microsoft 365 cloud service (Exchange Online). For large organizations, especially financial sectors, banks and government agencies, Exchange Server serves as the central collaboration infrastructure that controls the entire internal and external communication flow. Due to its key location and containing a lot of sensitive data, Exchange Server is always the top target of targeted attack groups (APTs).

Architecture of Microsoft Exchange

Microsoft Exchange is a Mail Server system consisting of many components such as Outlook Web App (OWA), Exchange Web Services (EWS), Autodiscover, MAPI over HTTP, ActiveSync, PowerShell and Mailbox Services.

In CVE-2026-45504, the affected component is not Mailbox Database but Outlook Web App (OWA) when handling the Preview Attachment feature.

This entire mechanism is used by Microsoft to allow users to preview Word, Excel or PowerPoint documents right in the browser without downloading them.

What is WOPI?

WOPI (Web Application Open Platform Interface) is a protocol developed by Microsoft to allow applications such as Exchange, SharePoint or OneDrive to communicate with Office Online Server.

Instead of Exchange rendering the Office file itself, it will ask WOPI Server:

"Which URL should I direct the user to to open this file?"

WOPI Server will return an XML document containing a variety of information, including:

<WebApplicationUrl> https://office.example.com/we/wordeditorframe.aspx </WebApplicationUrl>

Exchange will take this URL for further processing. and here is the starting point of the hole.

Cause of the gap

In its design Exchange expects: HTTP -> Office Online but ironically it does not limit that the URL must be HTTP or HTTPS. Therefore, if WebApplicationUrl contains: file:///... then the processing flow then becomes: WebRequest -> FileWebRequest -> OpenRead() -> Read Local File. This unintentionally turned an SSRF vulnerability into Arbitrary File Read.

Technical context

• Description: Server-Side Request Forgery (SSRF) vulnerability allows authenticated users to gain increased access through the network.

• CVE ID: CVE-2026-45504

• CVSS v3.1 Score: 8.8 (High)

• Vector tấn công: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

• CWE: CWE-918 (Server-Side Request Forgery - SSRF)

Affected versions:

• Microsoft Exchange Server 2016 Cumulative Update 23 (requires upgrade to KB5094144)

• Microsoft Exchange Server 2019 Cumulative Update 14 (requires upgrade to KB5094142)

• Microsoft Exchange Server 2019 Cumulative Update 15 (requires upgrade to KB5094140)

• Microsoft Exchange Server Subscription Edition RTM (requires upgrade to KB5094139)

This vulnerability does not impact the Exchange Online (Microsoft 365) cloud service, but only impacts enterprise on-premises deployments. To successfully exploit it over the network, an attacker only needs to own a low-privileged account on the target Exchange server.

Mining mechanism

The vulnerability CVE-2026-45504 appears in the integration mechanism between Microsoft Exchange with SharePoint and Yammer that serves to create document preview links (WAC document-preview URLs) via the WOPI (Web Application Open Platform Interface) protocol.

When a user opens a reference attachment, Exchange makes API calls through the internal functions GetTokenRequestWebResponse and GetWacUrl. These functions use the OneDriveProUtilities.TryTwice utility class to send HTTP/HTTPS queries to the WOPI server to collect document metadata.

The GetTokenRequestWebResponse function converts the given URL into a SharePoint REST API request.

The GetWacUrl function works to get the WOPI token through SharePoint. This function makes a request to the given URL and parses the WebApplicationUrl and AccessToken values ​​from the returned OData response. This is actually where the vulnerability begins.

To understand better, we will go through each part of the exploitation flow consisting of many different steps, each step is an important stepping stone for the next steps.

The vulnerability CVE-2026-45504 is not an unauthenticated vulnerability. The attacker must possess a valid Exchange account (domain account or mailbox account) to access OWA and EWS services.

The login() function will send a POST request to /owa/auth.owa with username, password, destination=/owa/ information.

After successful login, Exchange will return:

• Cookie phiên (Session Cookie)

• OWA Canary Token

OWA Canary is known as an anti-CSRF token required by Exchange in internal AJAX calls like: /owa/service.svc. If Canary is missing, Exchange will reject the request. In the entire exploitation chain, this is just the session establishment step. The vulnerability is not in the login mechanism, but in the APIs that are allowed to be used after authentication.

After successfully logging in, the next thing to do is create a Draft Email using EWS.

Do you wonder why it has to be Draft? As mentioned in Microsoft Exchange, an attachment is not an independent object, but always belongs to an email, calendar item (Calendar Item) or an item (Item) in the mailbox.

We can imagine Exchange's storage structure as follows:\

In which:

• Email Item là đối tượng chính (parent object).

• Attachment chỉ là đối tượng con (child object) gắn vào Email Item.

In other words, Exchange does not allow creating an individual ReferenceAttachment without an email containing it. That's why the Drafts folder is used because:

1. No need to send emails out.

2. Does not generate SMTP traffic.

3. Do not disturb other users.

4. Just having an email object exist in the mailbox is enough to enable the attachment processing APIs.

Just having an email object exist in the mailbox is enough to enable the attachment processing APIs.

Therefore, this is the simplest and safest option for attackers to prepare the environment for their exploit chain. The point to note is that the draft email is not the target of the attack, but only serves as a "container" for the ReferenceAttachment.

After creating the Draft Email, the attacker will continue to use the Exchange Web Services (EWS) CreateAttachment API to attach a ReferenceAttachment to this email.

Unlike FileAttachment, where file content is uploaded directly to the Exchange server, ReferenceAttachment only stores reference information to a file located on an external storage service such as SharePoint or OneDrive. When a user opens an attachment, Exchange will automatically connect to the specified URL to get the necessary information to display the preview.

In which:

• AttachLongPathName is the path to the reference document.

• ProviderEndpointUrl specifies the server providing the document storage service.

• ProviderType is set to OneDrivePro so that Exchange handles attachments according to the OneDrive/SharePoint integration (WOPI) process.

After the ReferenceAttachment is successfully created, Exchange does not read the document immediately but only saves the reference information in the mailbox. When it is necessary to display a preview of an attachment, Exchange triggers document processing through integrations with OneDrive/SharePoint.

During this process, Exchange uses the value of the ProviderEndpointUrl field to send an HTTP request to the declared server to retrieve the document's metadata. By original design, this server must be a valid SharePoint or OneDrive. However, this address has been replaced by a server controlled by the attacker.

When Exchange sends an HTTP request to this address, the CallbackHandler class will receive and return a response constructed by the attacker.

It's worth noting that Exchange proactively sends HTTP requests from its server side, not from the user's browser. This causes the vulnerability to be classified as Server-Side Request Forgery (SSRF), because the attacker took advantage of Exchange to make connections to an address under his control.

After receiving a request from Exchange, the attacker's server does not return the metadata of a real document but responds with an XML document constructed in the format expected by Exchange.

The response body is generated in the CallbackHandler.do_GET() function:

The WebApplicationUrl field is used to specify the address of the Office Online or WOPI application used to open the document. Under normal conditions, this field should contain a URL that uses the HTTPS protocol.

However, Exchange does not check the scheme of the received URL. As long as the XML structure is valid, the value in WebApplicationUrl will be accepted and used by Exchange in subsequent processing steps.

An attacker takes advantage of this weakness to replace the HTTP/HTTPS address with a file:// path, causing Exchange to prepare to directly access the server's own file system.

This is the root cause of the vulnerability CVE-2026-45504.

During the process of creating URLs for document previews, Exchange automatically adds authentication parameters such as access_token and access_token_ttl to the end of the URL received from the WOPI server.

If the URL is just: file:///C:/Windows/win.ini Exchange will produce: file:///C:/Windows/win.ini&access_token=...This path is no longer a valid file:// URI and reading the file will fail.

To fix this, the attacker will add the # character to the end of the URL: file:///C:/Windows/win.ini# After Exchange concatenates the OAuth parameters, the URL becomes: file:///C:/Windows/win.ini#&access_token=...&access_token_ttl=...

According to URI standards, any content after the # sign is only considered a Fragment and cannot be used when accessing resources. Therefore, the Windows URI processing layer will ignore the entire access_token part behind it and just handle: file:///C:/Windows/win.ini

This technique preserves a valid file:// path and ensures Exchange can still open local files.

Once Exchange has saved the ReferenceAttachment information, the PoC sends a request to the OWA Preview Generation API: POST /owa/service.svc?action=GetAttachmentPreview

This is when the mining chain is activated. During processing of this request, Exchange reads the ReferenceAttachment information, uses the value in WebApplicationUrl, and tries to open the document to create a preview for the user.

Because the URL is now: file:///C:/Windows/win.ini, Exchange no longer makes an HTTP request but switches to using the .NET Framework's System.Net.FileWebRequest class to directly access the file system on the server.

This causes Exchange to open the C:\Windows\win.ini file as if it were opening a valid document for display. This is the execution sink of the vulnerability, where the local file reading actually takes place.

After successfully reading the file from the file system, Exchange continues to process the data as a document to display in Attachment Preview. Instead of just creating a preview for the user, the GetAttachmentPreview API includes the read content in the HTTP response sent back to the client

If the exploit is successful, the contents of the target file (e.g. C:\Windows\win.ini) will appear on the attacker's screen.

Because the file path is passed via the --target-file parameter, an attacker can change this value to have Exchange read other files on the system that the Exchange process has access to. In fact, configuration files such as web.config, Exchange configuration files, or files containing sensitive information can become targets, significantly increasing the impact of the vulnerability.

Record actual exploitation

The vulnerability was discovered by the HawkTrace security research team and reported to Microsoft. Microsoft officially announced a patch for CVE-2026-45504 on June 9, 2026.

On June 24, 2026, the HawkTrace research team published a detailed analysis and Proof-of-Concept (PoC) exploit code publicly on GitHub at hawktrace/CVE-2026-45504. This PoC demonstrates successful reading of a win.ini file on a Windows Server operating system running Exchange Server 2019.

Although Microsoft initially ranked the vulnerability's actual exploitability as "Exploitation Unlikely", the widespread release of the perfectly working exploit code has completely changed the risk landscape. Organizations operating Exchange Server on-premises now face the risk of automated scanning and exploitation by hacker groups.

Event timeline:

• June 9, 2026: Microsoft releases official security patches in Patch Tuesday.

• June 24, 2026: HawkTrace publishes technical analysis and PoC code on GitHub.

• June 24, 2026: Major technology news sites simultaneously reported warnings about the risk of exploitation.

MITRE ATT&CK Mapping

Exploitation of the CVE-2026-45504 vulnerability is mapped into attack techniques according to the MITER ATT&CK matrix as follows:

Tactic	Technique ID	Technique Name	Description in the Context of CVE-2026-45504
Initial Access	T1190	Exploit Public-Facing Application	The attacker abuses publicly accessible Exchange services (EWS and Outlook Web Access) by submitting a malicious ReferenceAttachment that initiates the exploit chain.
Execution	T1059	Command and Scripting Interpreter	The exploit triggers Exchange's internal .NET processing workflow, ultimately invoking file-handling routines to access local files.
Credential Access	T1552	Unsecured Credentials	Arbitrary file read may expose sensitive configuration files (e.g., web.config), potentially revealing service account credentials, connection strings, or authentication secrets.
Lateral Movement	T1021	Remote Services	Credentials or sensitive information obtained from exposed files may be leveraged to authenticate to additional Active Directory or Exchange services, facilitating lateral movement within the environment.

Expert opinion

The vulnerability CVE-2026-45504 has a CVSS score of 8.8. Theoretically, requiring account permissions (PR:L) reduces the threat level compared to unauthenticated remote code execution (Pre-Auth RCE) vulnerabilities like ProxyLogon. However, in reality, the risk of this vulnerability is almost equivalent for large internal networks. In a corporate environment, it is not too difficult for an attacker to collect or hijack an employee's regular email account (through brute-force, phishing or buying and selling leaked data). Once one foot in the system through a low-level account, this vulnerability provides a master key for attackers to take away all sensitive information of the Exchange server.

According to observations from network security monitoring projects in Vietnam, the Exchange Server on-premises system is still the communication heart of many large agencies and financial organizations thanks to internal data security. However, the inherent weakness is that the patch update cycle for these systems is often long due to concerns about service interruption or system conflicts. Once the PoC code has been published in detail on GitHub, APT attack groups can quickly integrate this technique into targeted attack campaigns to quickly escalate Active Directory privileges after the initial successful compromise.

Technically, this vulnerability reflects the trend of path parser exploits. Using the # character to cut off URLs is a classic technique but still effective because programmers often only focus on filtering input characters but forget to canonicalize the path before forwarding it to system libraries like FileWebRequest.

Recommended action

Urgent (Within 24 hours)

1. Determine the current Exchange version: Run the following PowerShell command on the Exchange server to check the current build version:

   powershell
   
   Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion
   

   Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion

2. Download and install the security patch: Download the June 2026 Security Update that matches your system's current Cumulative Update (CU) version:

   • Exchange Server 2019 CU15: Install KB5094140

   • Exchange Server 2019 CU14: Install KB5094142

   • Exchange Server 2016 CU23: Install KB5094144

   • Exchange Server Subscription Edition: Install KB5094139

   • NVD - CVE-2026-45504

3. Outbound Internet Limits: If updates cannot be performed immediately due to operational processes, configure a firewall that prevents the Exchange server from connecting directly to the Internet on ports 80 and 443, except for Microsoft's well-defined IP ranges for patch updates.

Short term (From 1-7 days)

1. Chạy công cụ Health Checker: Tải và thực thi kịch bản ExchangeServerHealthChecker.ps1 chính thức từ Microsoft để quét toàn diện cấu hình và đảm bảo bản vá được áp dụng thành công mà không gặp lỗi.

2. Rà soát lịch sử log EWS: Quét log IIS của máy chủ Exchange để tìm kiếm các yêu cầu liên quan đến WOPI hoặc SharePoint từ các địa chỉ IP ngoại lai trong vòng 30 ngày qua nhằm phát hiện sớm các dấu hiệu dò quét thử nghiệm.

Long term

1. Apply the principle of Least Privilege: Regularly review and revoke the permissions of Exchange service accounts and limit access to EWS from public networks if not absolutely necessary.

2. DMZ network zoning planning: Completely separate Exchange Server servers from network areas containing important workstations and databases, only allowing necessary data flows to pass through security control devices with deep packet inspection capabilities.

Reference

CVE-2026-45504 Microsoft Exchange SSRF via File Read | HawkTrace

CVE-2026-45504 - Security Update Guide - Microsoft - Microsoft Exchange Server Elevation of Privilege Vulnerability

PoC Exploit Released for Microsoft Exchange Server Elevation of Privilege Vulnerability