# Phân tích kỹ thuật CVE-2026-45504: Sai sót nhỏ, rủi ro lớn trên Microsoft Exchange

## Tóm tắt chiến dịch

**CVE-2026-45504** là lỗ hổng an ninh mạng nghiêm trọng ảnh hưởng đến các máy chủ **Microsoft Exchange Server** phiên bản on-premises (nội bộ). Lỗ hổng cho phép một tài khoản người dùng có đặc quyền thấp nhưng đã được xác thực trên hệ thống có thể đọc trộm các tệp tin hệ thống nhạy cảm của máy chủ Exchange mà không cần quyền quản trị. Từ việc đọc các tệp tin cấu hình và thông tin định danh này, kẻ tấn công có thể nâng cao đặc quyền để kiểm soát hoàn toàn hệ thống thư điện tử của tổ chức.

Sự xuất hiện của mã khai thác công khai (Proof-of-Concept) làm tăng đáng kể nguy cơ bị tấn công, đặc biệt đối với các doanh nghiệp, tổ chức tài chính và cơ quan nhà nước đang tự vận hành hệ thống Exchange Server tại Việt Nam.

## **Tổng quan về Microsoft Exchange**

### Giới thiệu

Đầu tiên chúng ta cùng tìm hiểu qua **Microsoft Exchange là gì?** Hẳn không còn quá xa lạ với nhiều tổ chức và doanh nghiệp thì **Microsoft Exchange Server** là nền tảng quản lý thư điện tử, lịch biểu, danh bạ và tác vụ dành cho doanh nghiệp do Microsoft phát triển.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/f41eded2-1ebc-463b-8d53-427e06114d2c.png align="center")

Hệ thống này được triển khai phổ biến dưới dạng máy chủ cài đặt tại chỗ (on-premises) hoặc tích hợp trong dịch vụ đám mây Microsoft 365 (Exchange Online). Đối với các tổ chức lớn, đặc biệt là khối tài chính, ngân hàng và cơ quan chính phủ, Exchange Server đóng vai trò là hạ tầng cộng tác trung tâm kiểm soát toàn bộ luồng thông tin liên lạc nội bộ và ngoại biên. Do vị trí trọng yếu và chứa nhiều dữ liệu nhạy cảm, Exchange Server luôn là mục tiêu hàng đầu của các nhóm tấn công có chủ đích (APT).

### Kiến trúc của **Microsoft Exchange**

**Microsoft Exchange** là hệ thống Mail Server gồm nhiều thành phần như Outlook Web App (OWA), Exchange Web Services (EWS), Autodiscover, MAPI over HTTP, ActiveSync, PowerShell và Mailbox Services.

Trong CVE-2026-45504, thành phần bị ảnh hưởng không phải là Mailbox Database mà là **Outlook Web App (OWA)** khi xử lý tính năng **Preview Attachment**.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/7e709f56-7e8e-45e7-925d-7506a46d4209.png align="center")

Toàn bộ cơ chế này được Microsoft sử dụng để cho phép người dùng xem trước các tài liệu Word, Excel hoặc PowerPoint ngay trên trình duyệt mà không cần tải xuống.

### WOPI là gì?

WOPI (**Web Application Open Platform Interface**) là giao thức do Microsoft phát triển để cho phép các ứng dụng như Exchange, SharePoint hoặc OneDrive giao tiếp với Office Online Server.

Thay vì Exchange tự render file Office, nó sẽ hỏi WOPI Server:

> "Muốn mở file này thì tôi phải chuyển người dùng tới URL nào?"

**WOPI Server** sẽ trả về một tài liệu XML chứa nhiều thông tin, trong đó có:

`<WebApplicationUrl>   `[`https://office.example.com/we/wordeditorframe.aspx`](https://office.example.com/we/wordeditorframe.aspx)`   </WebApplicationUrl>`

Exchange sẽ lấy URL này để tiếp tục xử lý. và tại đây chính là điểm bắt đầu của lỗ hổng.

## Nguyên nhân lỗ hổng

Trong bản thiết kế của mình Exchange kỳ vọng: HTTP -> Office Online nhưng trớ trêu thay nó lại không giới hạn rằng URL phải là HTTP hoặc HTTPS. Do đó, nếu `WebApplicationUrl` chứa: `file:///...` thì luồng xử lý khi này trở thành: `WebRequest -> FileWebRequest -> OpenRead() -> Read Local File`. Điều này đã vô tình biến một lỗ hổng SSRF thành khả năng **đọc tệp cục bộ (Arbitrary File Read)**.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/4b3ce967-cd61-4c8a-bf46-71a6f0242270.png align="center")

## **Bối cảnh kỹ thuật**

*   Mô tả: Lỗ hổng **Server-Side Request Forgery (SSRF)** cho phép người dùng đã xác thực (authenticated user) có thể nâng cao khả năng truy cập thông qua mạng.
    
*   **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)
    

## **Các phiên bản bị ảnh hưởng:**

*   Microsoft Exchange Server 2016 Cumulative Update 23 (cần nâng cấp lên KB5094144)
    
*   Microsoft Exchange Server 2019 Cumulative Update 14 (cần nâng cấp lên KB5094142)
    
*   Microsoft Exchange Server 2019 Cumulative Update 15 (cần nâng cấp lên KB5094140)
    
*   Microsoft Exchange Server Subscription Edition RTM (cần nâng cấp lên KB5094139)
    

Lỗ hổng này không ảnh hưởng đến dịch vụ đám mây Exchange Online (Microsoft 365) mà chỉ tác động đến các triển khai on-premises tự vận hành của doanh nghiệp. Để khai thác thành công qua mạng, kẻ tấn công chỉ cần sở hữu một tài khoản hộp thư thông thường (low-privileged account) trên máy chủ Exchange mục tiêu.

## Cơ chế khai thác

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/109060d3-dd3e-4997-b3f3-25e9a60819b6.png align="center")

Lỗ hổng CVE-2026-45504 xuất hiện trong cơ chế tích hợp giữa Microsoft Exchange với SharePoint và Yammer phục vụ việc tạo các liên kết xem trước tài liệu (WAC document-preview URLs) thông qua giao thức WOPI (Web Application Open Platform Interface).

Khi người dùng mở một phụ lục (attachment) dạng tham chiếu, Exchange thực hiện các cuộc gọi API thông qua các hàm nội bộ `GetTokenRequestWebResponse` và `GetWacUrl`. Các hàm này sử dụng lớp tiện ích `OneDriveProUtilities.TryTwice` để gửi truy vấn HTTP/HTTPS đến máy chủ WOPI nhằm thu thập siêu dữ liệu tài liệu (metadata).

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/92541e0a-62a7-407c-84e0-00efbae2547e.png align="center")

Hàm `GetTokenRequestWebResponse` chuyển đổi URL đã cho thành yêu cầu API SharePoint REST.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/bda029e9-f982-4785-b1c6-8c3152e7a1b8.png align="center")

Hàm `GetWacUrl` hoạt động để lấy mã thông báo WOPI thông qua SharePoint. Hàm này đưa ra yêu cầu tới URL đã cho và phân tích các giá trị WebApplicationUrl và AccessToken từ phản hồi OData được trả về. Đây thực sự là nơi lỗ hổng bắt đầu.

Để hiểu rõ hơn chúng ta sẽ cùng đi qua từng phần trong luồng khai thác gồm nhiều bước khác nhau, mỗi một bước đều là bàn đạp quan trọng cho các bước tiếp theo.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/e976aad5-264f-4ac3-a70b-75312b753c70.png align="center")

Lỗ hổng CVE-2026-45504 **không phải unauthenticated vulnerability**. Kẻ tấn công phải sở hữu tài khoản Exchange hợp lệ (domain account hoặc mailbox account) để truy cập các dịch vụ OWA và EWS.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/b5f3e0e6-a565-4e03-943e-1cd79d074336.png align="center")

Hàm `login()` sẽ thực hiện gửi yêu cầu `POST /owa/auth.owa` với thông tin `username, password, destination=/owa/`.

Sau khi đăng nhập thành công, Exchange sẽ trả về:

*   **Cookie phiên (Session Cookie)**
    
*   **OWA Canary Token**
    

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/a52060fb-0d47-4938-b4bb-ffa6e54d721f.png align="center")

OWA Canary được biết đến là một **anti-CSRF token** được Exchange yêu cầu trong các lời gọi AJAX nội bộ như: `/owa/service.svc`. Nếu thiếu Canary, Exchange sẽ từ chối yêu cầu. Trong toàn bộ chuỗi khai thác thì đây chỉ là bước thiết lập phiên làm việc. Lỗ hổng **không nằm ở cơ chế đăng nhập**, mà ở các API được phép sử dụng sau khi xác thực.

Sau khi đăng nhập thành công thì việc tiếp theo cần làm là tạo một **Draft Email bằng EWS.**

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/2c149911-278d-4244-9055-82bd6086816a.png align="center")

Bạn có thắc mắc rằng tại sao lại phải là **Draft hay không?** Thì như đã đề cập trong Microsoft Exchange, **tệp đính kèm (Attachment) không phải là một đối tượng độc lập**, mà luôn thuộc về một email, lịch họp (Calendar Item) hoặc một mục (Item) trong hộp thư.

Có thể hình dung cấu trúc lưu trữ của Exchange như sau:\\

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/ae9e6e9b-0f63-47b7-ada7-3e585f6af661.png align="center")

Trong đó:

*   **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.
    

Nói cách khác, Exchange **không cho phép tạo một ReferenceAttachment riêng lẻ** mà không có email chứa nó. Chính vì thế mà thư mục **Drafts** được sử dụng vì:

1.  Không cần gửi email ra ngoài.
    
2.  Không tạo lưu lượng SMTP.
    
3.  Không làm phiền người dùng khác.
    
4.  Chỉ cần một đối tượng email tồn tại trong mailbox là đủ để kích hoạt các API xử lý attachment.
    

Do đó, đây là lựa chọn đơn giản và an toàn nhất mà kẻ tấn công chuẩn bị môi trường cho chuỗi khai thác của chúng. Điểm cần lưu ý là **email nháp không phải mục tiêu của cuộc tấn công**, mà chỉ đóng vai trò là **"vật chứa" (container)** cho `ReferenceAttachment`.

Sau khi tạo **Draft Email,** kẻ tấn công sẽ tiếp tục sử dụng API **CreateAttachment** của Exchange Web Services (EWS) để gắn một **ReferenceAttachment** vào email này.

Khác với **FileAttachment**, nơi nội dung tệp được tải trực tiếp lên máy chủ Exchange, **ReferenceAttachment** chỉ lưu thông tin tham chiếu đến một tệp nằm trên dịch vụ lưu trữ bên ngoài như SharePoint hoặc OneDrive. Khi người dùng mở tệp đính kèm, Exchange sẽ tự động kết nối đến URL được chỉ định để lấy thông tin cần thiết phục vụ việc hiển thị bản xem trước (Preview).

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/48ae9422-bff1-466e-8cd5-e998840ffe2d.png align="center")

Trong đó:

*   **AttachLongPathName** là đường dẫn đến tài liệu tham chiếu.
    
*   **ProviderEndpointUrl** chỉ định máy chủ cung cấp dịch vụ lưu trữ tài liệu.
    
*   **ProviderType** được đặt là `OneDrivePro` để Exchange xử lý attachment theo quy trình tích hợp OneDrive/SharePoint (WOPI).
    

Sau khi `ReferenceAttachment` được tạo thành công, Exchange chưa thực hiện đọc tài liệu ngay mà chỉ lưu thông tin tham chiếu trong mailbox. Khi cần hiển thị bản xem trước (Preview) của tệp đính kèm, Exchange sẽ kích hoạt quy trình xử lý tài liệu thông qua các thành phần tích hợp với OneDrive/SharePoint.

Trong quá trình này, Exchange sử dụng giá trị của trường **ProviderEndpointUrl** để gửi yêu cầu HTTP đến máy chủ được khai báo nhằm lấy metadata của tài liệu. Theo thiết kế ban đầu, máy chủ này phải là SharePoint hoặc OneDrive hợp lệ. Tuy nhiên, địa chỉ này đã bị thay thế bằng máy chủ do kẻ tấn công kiểm soát.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/6bb6ab1f-0243-4ce5-80fb-21c47daf3385.png align="center")

Khi Exchange gửi yêu cầu HTTP đến địa chỉ này, lớp `CallbackHandler` sẽ tiếp nhận và trả về phản hồi do kẻ tấn công tự xây dựng.

Điểm đáng chú ý là Exchange **chủ động gửi yêu cầu HTTP từ phía máy chủ của mình**, chứ không phải từ trình duyệt của người dùng. Điều này khiến lỗ hổng được phân loại là **Server-Side Request Forgery (SSRF)**, vì kẻ tấn công đã lợi dụng Exchange để thực hiện các kết nối đến một địa chỉ do mình kiểm soát.

Sau khi nhận được yêu cầu từ Exchange, máy chủ của kẻ tấn công không trả về metadata của một tài liệu thật mà phản hồi bằng một tài liệu XML được xây dựng theo định dạng mà Exchange mong đợi.

Nội dung phản hồi được tạo trong hàm [`CallbackHandler.do`](http://CallbackHandler.do)`_GET()`:

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/1fef8432-b6af-491e-9977-021c572c9e88.png align="center")

Trường **WebApplicationUrl** vốn được sử dụng để chỉ định địa chỉ của ứng dụng Office Online hoặc WOPI dùng để mở tài liệu. Trong điều kiện bình thường, trường này phải chứa một URL sử dụng giao thức **HTTPS**.

Tuy nhiên, Exchange lại **không kiểm tra kiểu giao thức (scheme)** của URL nhận được. Chỉ cần cấu trúc XML hợp lệ, giá trị trong `WebApplicationUrl` sẽ được Exchange chấp nhận và sử dụng trong các bước xử lý tiếp theo.

Kẻ tấn công lợi dụng điểm yếu này để thay thế địa chỉ HTTP/HTTPS bằng đường dẫn `file://`, khiến Exchange chuẩn bị truy cập trực tiếp vào hệ thống tập tin của chính máy chủ.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/d5e7038c-ba56-401f-9c80-b97975996e91.png align="center")

Đây chính là **nguyên nhân gốc rễ (root cause)** của lỗ hổng CVE-2026-45504.

Trong quá trình tạo URL phục vụ xem trước tài liệu, Exchange sẽ tự động bổ sung các tham số xác thực như `access_token` và `access_token_ttl` vào cuối URL nhận được từ máy chủ WOPI.

Nếu URL chỉ là: `file:///C:/Windows/win.ini` Exchange sẽ tạo thành: `file:///C:/Windows/win.ini&access_token=...`Đường dẫn này không còn là một URI `file://` hợp lệ và việc đọc tệp sẽ thất bại.

Để khắc phục việc này thì kẻ tấn công sẽ thực hiện thêm ký tự `#` vào cuối URL: `file:///C:/Windows/win.ini#` Sau khi Exchange ghép thêm các tham số OAuth, URL trở thành: `file:///C:/Windows/win.ini#&access_token=...&access_token_ttl=...`

Theo chuẩn URI, mọi nội dung phía sau dấu `#` chỉ được xem là **Fragment** và không được sử dụng khi truy cập tài nguyên. Do đó, lớp xử lý URI của Windows sẽ bỏ qua toàn bộ phần `access_token` phía sau và chỉ xử lý: `file:///C:/Windows/win.ini`

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/e04a77c0-fa7c-43ab-a6f0-6ba45f34dd00.png align="center")

Kỹ thuật này giúp giữ nguyên đường dẫn `file://` hợp lệ và đảm bảo Exchange vẫn có thể mở tệp cục bộ.

Sau khi Exchange đã lưu thông tin về `ReferenceAttachment`, PoC gửi yêu cầu đến API tạo bản xem trước của OWA: `POST /owa/service.svc?action=GetAttachmentPreview`

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/1c687e2d-e47c-4b75-88a9-b8b17f61babe.png align="center")

Đây là thời điểm chuỗi khai thác được kích hoạt. Trong quá trình xử lý yêu cầu này, Exchange sẽ đọc thông tin của `ReferenceAttachment`, sử dụng giá trị trong `WebApplicationUrl` và cố gắng mở tài liệu để tạo bản xem trước cho người dùng.

Do URL hiện tại đã là: `file:///C:/Windows/win.ini` nên Exchange không còn thực hiện một yêu cầu HTTP nữa mà chuyển sang sử dụng lớp **System.Net.FileWebRequest** của .NET Framework để truy cập trực tiếp hệ thống tập tin trên máy chủ.

Điều này khiến Exchange mở tệp `C:\Windows\win.ini` giống như đang mở một tài liệu hợp lệ cần hiển thị. Đây là **điểm thực thi (execution sink)** của lỗ hổng, nơi việc đọc tệp cục bộ thực sự diễn ra.

Sau khi đọc thành công tệp từ hệ thống tập tin, Exchange tiếp tục xử lý dữ liệu như một tài liệu cần hiển thị trong Attachment Preview. Thay vì chỉ tạo bản xem trước cho người dùng, API `GetAttachmentPreview` đưa nội dung đã đọc vào phản hồi HTTP gửi về cho client.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/12e0366d-15d6-40fe-86aa-d66d6b5613cc.png align="center")

Nếu quá trình khai thác thành công, nội dung của tệp mục tiêu (ví dụ `C:\Windows\win.ini`) sẽ xuất hiện trên màn hình của kẻ tấn công.

Do đường dẫn tệp được truyền thông qua tham số `--target-file`, kẻ tấn công có thể thay đổi giá trị này để yêu cầu Exchange đọc các tệp khác trên hệ thống mà tiến trình Exchange có quyền truy cập. Trong thực tế, các tệp cấu hình như `web.config`, các tệp cấu hình của Exchange hoặc những tệp chứa thông tin nhạy cảm có thể trở thành mục tiêu, làm gia tăng đáng kể mức độ ảnh hưởng của lỗ hổng.

## **Ghi nhận khai thác thực tế**

Lỗ hổng do đội ngũ nghiên cứu bảo mật HawkTrace phát hiện và báo cáo trách nhiệm cho Microsoft. Microsoft đã chính thức công bố bản vá cho CVE-2026-45504 vào ngày 09/06/2026.

Vào ngày 24/06/2026, nhóm nghiên cứu HawkTrace đã công bố bài phân tích chi tiết cùng mã khai thác Proof-of-Concept (PoC) công khai trên GitHub tại địa chỉ `hawktrace/CVE-2026-45504`. PoC này chứng minh việc đọc thành công tệp tin `win.ini` trên hệ điều hành Windows Server chạy Exchange Server 2019.

Mặc dù Microsoft ban đầu xếp hạng khả năng bị khai thác thực tế của lỗ hổng này là "Exploitation Unlikely" (ít có khả năng khai thác), việc công bố rộng rãi mã khai thác hoạt động hoàn hảo đã làm thay đổi hoàn toàn cục diện rủi ro. Các tổ chức vận hành Exchange Server on-premises hiện đối mặt với nguy cơ bị dò quét và khai thác tự động từ các nhóm tin tặc.

**Mốc thời gian sự kiện:**

*   **09/06/2026:** Microsoft phát hành bản vá bảo mật chính thức trong Patch Tuesday.
    
*   **24/06/2026:** HawkTrace công bố phân tích kỹ thuật và mã PoC trên GitHub.
    
*   **24/06/2026:** Các trang tin công nghệ lớn đồng loạt đưa tin cảnh báo về nguy cơ khai thác.
    

## **MITRE ATT&CK Mapping**

Hành vi khai thác lỗ hổng CVE-2026-45504 được ánh xạ vào các kỹ thuật tấn công theo ma trận MITRE ATT&CK như sau:

| **Tactic** | **Technique ID** | **Technique Name** | **Mô tả trong ngữ cảnh CVE-2026-45504** |
| --- | --- | --- | --- |
| **Initial Access** | T1190 | Exploit Public-Facing Application | Lợi dụng EWS và Outlook Web Access (OWA) phơi bày trên Internet để gửi yêu cầu đính kèm độc hại. |
| **Execution** | T1059 | Command and Scripting Interpreter | Kích hoạt luồng đọc file thông qua các lời gọi hàm .NET. |
| **Credential Access** | T1552 | Unsecured Credentials | Tìm kiếm thông tin đăng nhập từ các tệp cấu hình Exchange (`web.config`, v.v.). |
| **Lateral Movement** | T1021 | Remote Services | Sử dụng thông tin rò rỉ để đăng nhập vào các dịch vụ khác của Active Directory. |

## **Nhận định chuyên gia**

Lỗ hổng CVE-2026-45504 có điểm CVSS là 8.8. Về mặt lý thuyết, việc yêu cầu quyền tài khoản (PR:L) làm giảm mức độ đe dọa so với các lỗ hổng thực thi mã từ xa không cần xác thực (Pre-Auth RCE) như ProxyLogon. Tuy nhiên, trên thực tế, rủi ro của lỗ hổng này gần như tương đương đối với các mạng nội bộ lớn. Trong môi trường doanh nghiệp, việc kẻ tấn công thu thập hoặc chiếm đoạt một tài khoản email thông thường của nhân viên (qua brute-force, phishing hoặc mua bán dữ liệu rò rỉ) là điều không quá khó khăn. Một khi đã bước được một chân vào hệ thống qua tài khoản cấp thấp, lỗ hổng này cung cấp chiếc chìa khóa vạn năng để kẻ tấn công lấy đi toàn bộ thông tin nhạy cảm của máy chủ Exchange.

Theo quan sát từ các dự án giám sát an ninh mạng tại Việt Nam, hệ thống Exchange Server on-premises vẫn là trái tim truyền thông của nhiều cơ quan, tổ chức tài chính lớn nhờ tính bảo mật dữ liệu nội bộ. Tuy nhiên, điểm yếu cố hữu là chu kỳ cập nhật bản vá cho các hệ thống này thường kéo dài do lo ngại gián đoạn dịch vụ hoặc xung đột hệ thống. Khi mã PoC đã được công bố chi tiết trên GitHub, các nhóm tấn công APT có thể nhanh chóng tích hợp kỹ thuật này vào các chiến dịch tấn công mục tiêu nhằm nhanh chóng leo thang đặc quyền Active Directory sau khi đã xâm nhập thành công ban đầu.

Về mặt kỹ thuật, lỗ hổng này phản ánh xu hướng khai thác parser đường dẫn. Việc sử dụng ký tự `#` để cắt đuôi URL là kỹ thuật kinh điển nhưng vẫn phát huy tác dụng do các lập trình viên thường chỉ tập trung lọc ký tự đầu vào mà quên mất việc chuẩn hóa (canonicalization) đường dẫn trước khi chuyển tiếp cho các thư viện hệ thống như `FileWebRequest`.

## **Khuyến nghị hành động**

### **Cấp bách (Trong vòng 24 giờ)**

1.  **Xác định phiên bản Exchange hiện tại:** Chạy lệnh PowerShell sau trên máy chủ Exchange để kiểm tra phiên bản build hiện tại:
    
    ```plaintext
    powershell
    
    Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion
    ```
    
    Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion
    
2.  **Tải và cài đặt bản vá bảo mật:** Tải bản vá June 2026 Security Update phù hợp với phiên bản Cumulative Update (CU) hiện tại của hệ thống:
    
    *   Exchange Server 2019 CU15: Cài đặt **KB5094140**
        
    *   Exchange Server 2019 CU14: Cài đặt **KB5094142**
        
    *   Exchange Server 2016 CU23: Cài đặt **KB5094144**
        
    *   Exchange Server Subscription Edition: Cài đặt **KB5094139**
        
    *   [NVD - CVE-2026-45504](https://nvd.nist.gov/vuln/detail/CVE-2026-45504?utm_source=chatgpt.com#range-24586817)
        
3.  **Giới hạn Outbound Internet:** Nếu chưa thể thực hiện cập nhật ngay lập tức do quy trình vận hành, hãy cấu hình tường lửa ngăn chặn máy chủ Exchange kết nối trực tiếp ra Internet trên các cổng 80 và 443, ngoại trừ các dải IP được xác định rõ của Microsoft phục vụ việc cập nhật bản vá.
    

### **Ngắn hạn (Từ 1-7 ngày)**

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.
    

### **Dài hạn**

1.  **Áp dụng nguyên tắc Đặc quyền tối thiểu (Least Privilege):** Thường xuyên rà soát, thu hồi quyền hạn của các tài khoản dịch vụ Exchange và hạn chế quyền truy cập vào EWS từ các mạng công cộng nếu không thực sự cần thiết.
    
2.  **Quy hoạch phân vùng mạng DMZ:** Tách biệt hoàn toàn máy chủ Exchange Server khỏi các vùng mạng chứa máy trạm và cơ sở dữ liệu quan trọng, chỉ cho phép luồng dữ liệu cần thiết đi qua các thiết bị kiểm soát bảo mật có khả năng deep packet inspection.
    

## Tham khảo

[CVE-2026-45504 Microsoft Exchange SSRF via File Read | HawkTrace](https://hawktrace.com/blog/CVE-2026-45504/)

[CVE-2026-45504 - Security Update Guide - Microsoft - Microsoft Exchange Server Elevation of Privilege Vulnerability](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45504)

[PoC Exploit Released for Microsoft Exchange Server Elevation of Privilege Vulnerability](https://cybersecuritynews.com/poc-exploit-released-exchange-vulnerability/)