CVE-2026-50522：SharePoint 反序列化 RCE、POC、修補與鑑識分析

更新日期：2026 年 7 月 25 日。 CVE-2026-50522 是 Microsoft SharePoint Server 的不安全反序列化遠端程式碼執行漏洞。它不需要已登入帳號或使用者互動，Microsoft／NVD 給出的 CVSS 3.1 分數為 9.8；CISA 已在 7 月 22 日將它加入 Known Exploited Vulnerabilities（KEV）目錄，代表風險不再只是理論推演，而是已經出現實際攻擊。

本文不提供可直接武器化的序列化 payload，但會沿著已公開的請求入口、Token 處理類別、反序列化資料流、machineKey 竊取後果與修補邏輯，說明漏洞為何能走到 RCE，以及防守方應如何確認版本、搜尋 IIS／Windows 記錄、輪替密鑰與完成事件應變。

60 秒重點摘要

• 漏洞：CVE-2026-50522，CWE-502「Deserialization of Untrusted Data」，可造成未授權遠端程式碼執行。
• 產品：只影響自行維運的 SharePoint Server 2016、2019 與 Subscription Edition；不是 SharePoint Online 漏洞。
• 公開技術線索：ZDI 將問題定位在 SessionSecurityTokenHandler；多家事件報告描述攻擊流量會 POST 到 /_trust/default.aspx，藉 WS-Federation 登入流程傳入偽造的 SecurityContextToken。
• 真正危險處：攻擊者可讓伺服器處理未受信任的 .NET 序列化物件，並在 SharePoint Web Application 的服務身分下執行程式碼。
• 已觀察後果：攻擊活動會在單一請求後竊取 SharePoint／ASP.NET machine keys。只安裝更新不會讓已外洩的密鑰自動失效，因此修補後仍須輪替密鑰、憑證與可能受影響的認證資料。
• 最低安全版本：2016 為 16.0.5561.1001、2019 為 16.0.10417.20175、Subscription Edition 為 16.0.19725.20434。
• 優先偵測：檢查 /_trust/default.aspx 的異常 POST、w3wp.exe 啟動命令列工具、Web 目錄新增 ASPX、machineKey 或 farm 設定異動，以及後續憑證／帳號濫用。

事件背景：為什麼今天必須處理

Microsoft 在 2026 年 7 月 14 日發布修補。ZDI 的揭露時間線顯示，漏洞由 DEVCORE 研究員 splitline 透過 Pwn2Own 通報，2026 年 5 月 21 日交給供應商，ZDI 在 7 月 15 日公開技術摘要。7 月 20 日，watchTowr 通報公開 PoC 與實際利用活動；CERT-EU、NHS England 與 CISA 隨後提升警示。

「公開 PoC」「已觀察利用」「加入 KEV」三者同時存在時，排程不能再依一般 CVSS 修補週期處理。外網 SharePoint 是高價值入口：它通常接觸 Active Directory、文件、內部使用者與服務帳號；一旦 Web Process 被控制，攻擊者可竊取密鑰、建立持久化、橫向移動，甚至在安裝更新後繼續偽造可信任 Token。

證據分級：哪些已確認，哪些仍是推論

這個界線很重要。SharePoint 是專有軟體，不能只憑修補後行為就宣稱 Microsoft「一定」新增了某個函式或某一組型別白名單。後文的程式碼是用來解釋漏洞類型的概念模型，不是從 Microsoft 二進位檔反編譯後宣稱的原始碼。

受影響版本與修補門檻

Microsoft 的 SharePoint 更新是累積式，但 Farm 中每台伺服器都要完成套件安裝與 SharePoint Products Configuration Wizard／PSConfig。只看到 Windows Update 顯示成功，不等於整個 Farm 的資料庫與元件都已升級。SharePoint 2016 與 2019 還要注意語言獨立、語言相依元件都必須符合版本門檻；即使只有英文安裝，仍包含語言相依元件。

此外，SharePoint Server 2016 與 2019 已在 2026 年 7 月 14 日結束延伸支援。這次更新雖提供最後一道重要防線，長期措施仍應是移轉到受支援的 Subscription Edition 或合適的雲端服務，而不是把 2016／2019 留在外網。

漏洞資料流：一個 HTTP 請求如何走到反序列化

1. 攻擊者向 SharePoint 的信任登入入口 /_trust/default.aspx 發送特製 POST。
2. 該入口處理 WS-Federation 被動式登入回應，將請求中的安全權杖交給 SharePoint／Windows Identity Foundation 元件。
3. 偽造的權杖被包裝成 SecurityContextToken，其中 Cookie 欄位攜帶序列化狀態。
4. SessionSecurityTokenHandler 嘗試還原 Token／Session 狀態。如果資料在進入物件重建前沒有被可靠驗證，外部輸入就抵達反序列化邊界。
5. .NET Formatter 根據位元組流內的型別與物件圖建立物件。危險不在「把 JSON 變成物件」這個抽象動作，而是泛用反序列化器可以啟動具有副作用的 gadget chain。
6. 當物件建構、屬性設定、回呼或型別轉換觸發危險方法時，攻擊者控制的資料可變成程序執行；執行權限繼承自承載 SharePoint 的 w3wp.exe／應用程式集區服務身分。

可以把信任邊界畫成：

Internet
  │
  ├─ POST /_trust/default.aspx
  │      WS-Federation sign-in response
  │
  └─ forged SecurityContextToken / cookie bytes
            │
            ▼
     SessionSecurityTokenHandler
            │  缺少足夠的來源、完整性或型別驗證
            ▼
     unsafe deserialization
            │
            ▼
       gadget side effect
            │
            ▼
     code execution in w3wp.exe context

為何 BinaryFormatter 類型的反序列化特別危險

傳統 .NET Formatter（事件報告將這次利用描述為 BinaryFormatter payload）會保存完整物件圖與型別資訊。應用程式開發者可能只想「還原 Session Token」，但 Formatter 不知道哪些型別是業務需要、哪些型別在屬性 setter、反序列化 callback 或代理物件中帶有副作用。只要攻擊者可以控制位元組流，就可能挑選伺服器已載入組件裡的 gadget，將資料驅動轉成行為驅動。

下面是概念化的易受攻擊模式，不是 Microsoft SharePoint 原始碼：

// 概念模型：請勿用於處理任何外部輸入
byte[] cookieBytes = ReadSecurityContextCookie(httpRequest);

var formatter = new BinaryFormatter();
object sessionState;

using (var stream = new MemoryStream(cookieBytes))
{
    sessionState = formatter.Deserialize(stream);
}

RestoreSession(sessionState);

根因不是最後一行 RestoreSession()，甚至不要求應用程式之後主動「執行」物件。危險行為可能已在 Deserialize() 重建物件圖的過程發生。這也是為什麼在 Formatter 外面包一層 try/catch、檢查反序列化後物件的基底型別，或只過濾幾個字串，都不能形成可靠修補：檢查發生時，副作用可能已經出現。

安全設計應把驗證放在反序列化之前

一個合理的修補方向應同時處理「Token 是否可信」與「資料能被還原成什麼」。下列也是概念模型，不代表 Microsoft 採用的精確實作：

byte[] envelope = ReadTokenEnvelope(httpRequest);

// 1. 在解析複雜物件以前，先驗證發行者、受眾、時效與密碼學完整性
VerifiedToken token = tokenValidator.Validate(
    envelope,
    expectedIssuer,
    expectedAudience,
    trustedSigningKeys,
    clockSkew);

// 2. 只讀取固定 schema 的純資料，不接受任意 CLR type metadata
SessionState state = SafeSchemaReader.Read<SessionState>(
    token.Payload,
    allowedFields: SessionStateSchema.Fields);

// 3. 驗證業務限制後才使用
ValidateSessionBounds(state);
RestoreSession(state);

理想狀態是完全移除不安全的泛用 Formatter，改用固定 schema、不可任意指定 CLR 型別的格式。如果相容性限制使元件仍需處理舊格式，也必須先完成簽章／MAC 驗證，限制合法發行者與 audience，並採取嚴格型別 allow-list。拒絕清單通常會漏掉新的 gadget；allow-list 才能縮小可反序列化的物件集合。

為何這樣修補：控制資料，不讓資料選擇程式行為

反序列化 RCE 的本質，是「輸入資料可以決定要建立哪些程式型別」，因而跨越資料與程式行為的邊界。可靠修補要把這個選擇權收回來：伺服器先確認權杖確實由可信任對象簽發，再用伺服器定義的 schema 解碼，只允許業務需要的欄位與型別。

Microsoft 未公開 CVE-2026-50522 的可核對原始碼 diff，因此我們不能聲稱 KB5002882／KB5002883／KB5002891 分別新增了哪一行檢查。可以確定的是：官方指定的 Build 是漏洞修補邊界；管理者應以實際 Farm Build 驗證，而不是依照上述概念程式碼猜測某個 DLL 是否安全。

PoC 與實際攻擊鏈分析

公開報告描述的 PoC 不是一般頁面的表單參數注入，而是利用 SharePoint 對聯合身分登入資料的信任。攻擊者製作 WS-Federation sign-in response，把惡意序列化內容放進偽造 SecurityContextToken 的 Cookie，再 POST 到 /_trust/default.aspx。因此只搜尋 URL query string 裡的「cmd」或 PowerShell 字樣，很可能完全看不到攻擊。

我們檢視搜尋到的公開 GitHub 專案時，也遇到只有範本 README、沒有可驗證 exploit 實作的倉庫；本文沒有把這類倉庫當成技術證據，更沒有在任何系統執行 payload。PoC 判讀至少要能對上三個獨立線索：ZDI 指出的處理類別、事件報告的 HTTP 入口與權杖形狀、以及 Microsoft 公告的漏洞類型。只有專案名稱或一段未驗證的 curl 指令，不足以證明利用原理。

從防禦角度，PoC 最重要的資訊是可觀測面：

• 入口可在 IIS 記錄中表現為對 /_trust/default.aspx 的 POST。
• 請求內容可能是編碼後的 WS-Federation／Token 資料，不會直接出現明顯命令。
• 第一次成功後，攻擊者可能讀取 machine keys，而非立刻放置 WebShell。
• 取得密鑰後的第二階段可能使用「看似有效」的簽章或 Token，因此來源 IP、帳號行為與服務程序異常要一起關聯。

為何竊取 machineKey 能繞過「已修補」的安全感

ASP.NET／SharePoint 的 machine keys 用於驗證與加密部分狀態或 Token。若 validationKey、decryptionKey 或相關 Farm 密鑰被竊取，攻擊者可能離線製作能通過伺服器驗證的資料。安裝更新只關閉原始反序列化入口，不會讓攻擊者硬碟裡已複製的密鑰消失，也不會自動撤銷所有先前簽發或偽造的 Session。

所以修補與事件應變是兩件事：

1. 修補：阻止新的 CVE-2026-50522 利用。
2. 密鑰輪替：使已外洩的 machine keys、Token 簽章材料失效。
3. Session 失效與服務重啟：清除仍在記憶體或快取中的舊狀態。
4. 憑證與服務帳號處置：若 Web Process 可讀取其他秘密，還要輪替 Farm 帳號、應用程式集區身分、憑證私鑰與相關 API secrets。
5. 威脅獵捕：確認攻擊者沒有建立 ASPX、排程、服務、帳號、OAuth 信任或橫向移動。

如何確認 SharePoint Farm 的實際 Build

在 SharePoint Management Shell 以系統管理權限執行：

# 顯示 Farm Build
(Get-SPFarm).BuildVersion

# 檢查各伺服器是否需要升級
Get-SPServer |
    Select-Object Address, Role, Status, NeedsUpgrade

# 檢查內容資料庫升級狀態
Get-SPContentDatabase |
    Select-Object Name, Server, NeedsUpgrade

所有節點都應達到或高於對應門檻，且 NeedsUpgrade 不應維持 True。大型 Farm 請依 Microsoft 的零停機或維護窗口程序更新；不要只在中央管理伺服器安裝，卻把 Web Front End 留在舊版。更新後要執行 PSConfig、確認 Timer Service／IIS 正常，再從負載平衡器逐台恢復流量。

IIS 日誌：先找入口，再做上下文關聯

PowerShell 範例只做唯讀搜尋，可先圈出可疑時間，再回查完整欄位：

$LogRoot = 'C:inetpublogsLogFiles'

Get-ChildItem -Path $LogRoot -Filter '*.log' -Recurse |
    Select-String -Pattern '/_trust/default.aspx' |
    Select-Object Path, LineNumber, Line

不是每一筆 /_trust/default.aspx 都是攻擊；使用 AD FS／SAML 的環境本來就可能有合法流量。要比較正常基線與異常特徵：

• 平常罕見、突然出現的 POST 或短時間大量請求。
• 不屬於企業身分提供者、Proxy 或 VPN 範圍的來源 IP。
• 異常大的 cs-bytes、不尋常 User-Agent、連續 500 後接 200。
• 同一來源在成功請求前後掃描 /_layouts/、管理頁面或其他 SharePoint 漏洞入口。
• 請求後數秒至數分鐘內，主機出現 w3wp.exe 子程序、檔案寫入、密鑰讀取或認證事件。

Windows 與端點遙測：找 w3wp.exe 的異常行為

SharePoint 正常工作也會讓 w3wp.exe 存取檔案與資料庫，所以高訊號規則應聚焦「Web Worker 啟動不該啟動的子程序」。可疑子程序包括 cmd.exe、powershell.exe、pwsh.exe、rundll32.exe、regsvr32.exe、certutil.exe、bitsadmin.exe、mshta.exe 與腳本主機。

# 需要已啟用「包含命令列的程序建立稽核」
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4688
    StartTime = (Get-Date).AddDays(-14)
} | Where-Object {
    $_.Message -match 'Creator Process Name:s+.*\w3wp.exe' -and
    $_.Message -match 'New Process Name:s+.*\(cmd|powershell|pwsh|rundll32|certutil|mshta).exe'
} | Select-Object TimeCreated, Id, Message

同時檢查 PowerShell Operational 4103／4104、Microsoft Defender、Sysmon Event ID 1、Windows Error Reporting 與 ASP.NET Application 記錄。若 EDR 支援程序樹，將 IIS 請求時間與程序建立、網路連線、檔案寫入串起來，比只靠靜態 IOC 更可靠。

Microsoft Defender XDR／Sentinel KQL 範例

DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ (
    "cmd.exe", "powershell.exe", "pwsh.exe", "rundll32.exe",
    "certutil.exe", "bitsadmin.exe", "mshta.exe", "cscript.exe", "wscript.exe"
)
| project Timestamp, DeviceName, AccountName, FileName,
          ProcessCommandLine, InitiatingProcessCommandLine, SHA256
| order by Timestamp desc

DeviceFileEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName endswith ".aspx"
| where FolderPath has_any (
    "\TEMPLATE\LAYOUTS\",
    "\wwwroot\",
    "\Web Server Extensions\"
)
| project Timestamp, DeviceName, ActionType, FolderPath,
          FileName, SHA256, InitiatingProcessCommandLine

查詢結果不是自動定罪。部署解決方案或正常管理程序也可能寫入 ASPX；應核對簽章、雜湊、套件安裝時間、變更單與同一時間的網路活動。反過來說，查不到 w3wp.exe → powershell.exe 也不能證明安全，因為 payload 可以直接在程序記憶體完成資料竊取，不必建立子程序。

檔案、設定與持久化檢查

• 比對 SharePoint Hive、IIS Web Root 與自訂解決方案目錄的近期新增／修改檔案，特別是 ASPX、ASHX、DLL、PowerShell 與壓縮檔。
• 確認 web.config 中 machineKey、認證、Proxy、Handler 與 Module 沒有未授權變更；保留檔案時間與雜湊。
• 檢查新增的 Windows Service、Scheduled Task、WMI 永久事件訂閱、Run Keys、Startup、SSH keys 與遠端管理工具。
• 檢查 SharePoint Farm Administrators、Site Collection Administrators、服務應用程式、Trusted Identity Token Issuer、OAuth／App Principal 與憑證變更。
• 檢查服務帳號異常登入、Kerberos Ticket、NTLM 驗證、RDP／SMB／WinRM 連線及對 Domain Controller 的存取。
• 將調查窗口至少往公開 PoC 與已知利用之前延伸；若系統長期曝露外網，應依日誌保存期盡可能回溯。

修補與 Farm 維運步驟

1. 盤點：列出所有 Web Front End、Application Server、Central Admin 與 Search 節點，記錄 Build、角色、外網曝露與負載平衡狀態。
2. 降低曝露：在完成更新前，限制外網直接存取；若業務允許，暫時從 Load Balancer 下線或只允許 VPN／可信任來源。WAF 只能作臨時風險降低，不能代替更新。
3. 安裝正確套件：2016／2019 同時處理語言獨立與語言相依更新；Subscription Edition 安裝 KB5002882，並閱讀該更新列出的 Workflow Manager 與已知問題注意事項。
4. 執行設定升級：在每台伺服器執行 SharePoint Products Configuration Wizard 或經核准的 PSConfig 程序。
5. 驗證：確認 Farm Build 達門檻、所有節點 NeedsUpgrade=False、內容資料庫狀態正常、Central Admin 與站台健康。
6. 輪替密鑰：若曾外網曝露，依 Microsoft／組織程序輪替 machine keys、Token signing／encryption material 與可由服務身分讀取的其他 secrets；同步 Farm 節點後重啟 IIS／相關服務。
7. 獵捕與監控：持續觀察 IIS 入口、程序樹、檔案與身分活動。把修補時間當成調查分界，不要當成事件結束時間。
8. 移轉：2016／2019 已停止支援，建立升級到 Subscription Edition 或適合的 SharePoint Online 架構與完成日期。

若發現疑似成功利用：事件應變順序

1. 隔離但不要關機：從外網與橫向網路隔離受影響節點，保留記憶體與即時程序狀態。不要先清檔案而破壞證據。
2. 保存證據：匯出 IIS、HTTP Proxy／WAF、Windows、EDR、SharePoint ULS、PowerShell、AD 與負載平衡器記錄；取得記憶體與磁碟映像或至少關鍵檔案雜湊。
3. 界定範圍：確認所有 Farm 節點、服務帳號、Domain Controller、SQL Server 與管理工作站是否出現相同 IOC 或認證使用。
4. 根除：安裝更新、移除確認的持久化、撤銷惡意帳號／Token。高度可信的 RCE 事件應考慮從乾淨映像重建，而不是只刪除可疑 ASPX。
5. 輪替信任材料：machineKey、Farm secrets、服務帳號、憑證、API Token、備份帳號與管理員認證都要依暴露範圍處理。
6. 復原與加強監控：只將已驗證乾淨且達安全 Build 的節點重新上線；針對舊密鑰、舊帳號、同源 IP 與相同 TTP 建立延長監控。

常見錯誤

• 只封鎖一個 IP：基礎設施可快速更換，且已取得密鑰的攻擊者不需要重走相同入口。
• 只安裝 KB、不跑 PSConfig：Farm 元件與資料庫可能仍未完成升級。
• 看到 SharePoint 頁面可開就算修好：可用性不是安全版本驗證。
• 只找 WebShell：成功利用可能只竊取密鑰或在記憶體操作，沒有落地 ASPX。
• 直接執行網路下載的 PoC：名稱符合 CVE 不代表程式碼可信；PoC 本身可能植入後門或破壞環境。
• 把 WAF 視為永久修補：編碼、Token 格式與合法聯合登入流量會讓規則很難同時準確且完整。

FAQ

CVE-2026-50522 需要登入嗎？

不需要。Microsoft／NVD 的向量是 AV:N/AC:L/PR:N/UI:N，意即網路可達、低複雜度、不需權限、也不需使用者互動。

SharePoint Online 需要自行安裝這些 KB 嗎？

不需要。公告列出的受影響產品是 On-Premises SharePoint Server。Microsoft 365 的 SharePoint Online 由 Microsoft 維運，沒有讓客戶自行安裝 SharePoint Server KB 的流程。

安裝更新後還要輪替 machineKey 嗎？

曾經對外曝露或有任何可疑請求時，應把輪替視為必要事件應變。更新能關閉漏洞入口，但不會撤回攻擊者先前偷走的密鑰。

沒有看到 /_trust/default.aspx 請求就能排除入侵嗎？

不能。日誌可能過期、未記錄 Request Body、被 Proxy 正規化，攻擊者也可能使用其他漏洞鏈。這個 URL 是高價值線索，不是唯一判定條件。

可以用 PoC 掃描正式站嗎？

不建議。反序列化 PoC 可能真的觸發程式碼執行、造成服務中斷或留下難以辨識的狀態。正式環境應先用 Build、KB、PSConfig 狀態與唯讀日誌檢查；需要驗證利用時，請在隔離、可還原且有明確授權的實驗室進行。

延伸閱讀

• CVE-2026-45659：另一個 SharePoint 實際利用事件
• LonelySec 漏洞預警與 CVE 專題

官方公告與技術來源

• Microsoft MSRC：CVE-2026-50522
• Microsoft：SharePoint Server Subscription Edition KB5002882
• Microsoft Learn：SharePoint updates／Build 與 KB 對照
• NVD：CVE-2026-50522、CVSS 與受影響版本
• CISA Known Exploited Vulnerabilities Catalog
• ZDI-26-412：SessionSecurityTokenHandler 技術摘要與揭露時間線
• CERT-EU：Critical Vulnerabilities in Microsoft SharePoint
• NHS England：實際利用、machine keys 與修補建議
• CTIR Gov：各產品受影響 Build 門檻
• BleepingComputer：已觀察攻擊流程與 machineKey 竊取

本文的修補版本、利用狀態與技術細節以 2026 年 7 月 25 日可取得資料為準。Microsoft 未公開的原始碼修改一律標示為概念解釋，不把推論冒充成供應商事實。