VMware vCenter 漏洞 CVE-2026-59310 遭全球攻擊：修補不代表系統已安全

CVE-2026-59310 已不只是「高優先級修補」問題。Broadcom 在 2026 年 7 月 29 日披露並修補 VMware vCenter Syslog Server 的重大目錄穿越漏洞，但研究人員觀察到攻擊活動最早在 8 月 3 日開始，距離修補發布僅 5 天。這波活動涉及 47 個國家的 361 個觀察到的 IP，並利用逆向 SSH 維持存取權；Shadowserver 因此表示，部署了相關機制的系統應視為已完全遭到入侵。

CVE-2026-59310 可以造成什麼影響？

Broadcom 與美國國家漏洞資料庫（NVD）將 CVE-2026-59310 描述為 vCenter Syslog Server 的目錄穿越漏洞。只要能連線到 vCenter，攻擊者便不需要驗證身分即可利用漏洞，在受影響的 vCenter 系統上執行任意程式碼。漏洞 CVSS 評分為 9.8，屬於重大等級。

實務上，這項漏洞可能把暴露在網路上的 vCenter 設備變成進入虛擬化基礎設施、建立持久化存取，甚至進一步擴大攻擊範圍的跳板。部分攻擊報告描述程式碼在設備 root 權限脈絡下執行；不過，最具權威性的供應商與漏洞資料庫資料，主要確認的是「可執行任意程式碼」這項廣泛風險，而非每一次入侵的完整權限細節。

Broadcom 已提供修補後版本，但沒有提供替代緩解措施。因此，依照供應商列出的版本更新受影響系統，就是官方指定的修復方式。

修補發布 5 天後就遭利用

Broadcom 在 7 月 29 日公布 CVE-2026-59310 並發布修補程式。QUIRSO 則回報，活躍利用跡象從 8 月 3 日開始，之後攻擊活動快速擴大。

這個時間差對事件應變非常關鍵。若系統是在 8 月 3 日之後才更新，管理員不能因為「更新成功」就直接認定環境乾淨。漏洞修復與入侵評估是兩件事：前者是先堵住漏洞，後者則要確認攻擊者是否已在修補前取得存取權並留下後門。

47 國、361 個 IP：規模有多大？

與這波活動相關的研究人員表示，已觀察到 47 個國家的 361 個受害 IP。據報告，德國、美國、土耳其、伊朗與法國合計占觀察集合的一半以上。

不過，這個數字需要謹慎解讀。單一 IP 不一定對應單一企業或機構，因此「361 個受害 IP」不等於 361 家不同組織。現有報告能支持的結論是：這是一場針對可從網際網路或其他網路環境連線到的 vCenter 系統、且分布範圍相當廣的攻擊活動。

為何研究人員懷疑與中國有關？

QUIRSO 以「中等信心」評估這波攻擊可能具有中國關聯性。報告提到的線索包括中文語言痕跡、使用的工具與公開重複利用的研究資料、符合 UTC+08:00 工作時段的活動模式，以及疑似排除中國大陸受害者的目標分布。

這些線索可以支持區域或語言層面的研判，但不能據此指認特定中國國家級組織，也不能證明攻擊由政府主導。根據惡意程式特徵、活動時間與受害目標進行的歸因，仍可能隨著新證據出現而改變。因此，目前最穩妥的說法是「疑似具中國關聯性的攻擊者」，而不是已確認的國家支持行動。

已知的攻擊鏈

目前報告顯示，攻擊者可能先利用 CVE-2026-59310 取得初始程式碼執行能力，再分階段部署持久化與遠端存取工具：

1. 目錄穿越： 攻擊者向 Syslog 服務送出特製要求，跳出原本允許的路徑，寫入由攻擊者控制的內容。
2. cron 持久化： 據報告，攻擊者建立格式異常的 cron 設定，讓排程工作執行後續指令。
3. 投遞後門： 根據對已觀察入侵事件的報導，curl 或 wget 會下載使用 WebSocket 與 XOR 混淆的 linuxFile 後門。
4. 逆向 SSH： 攻擊者安裝逆向 SSH 工具，建立由受害端向外連出的通道，回到攻擊者控制的基礎設施。Shadowserver 表示，其特別報告中的所有受害者都出現這項持久化機制。
5. 濫用憑證與帳戶： 調查人員回報發現未經授權的 vCenter 與 ESXi 管理員帳戶，以及 VMware Directory Service 憑證遭到濫用。
6. 部署勒索軟體： 至少部分報告將活動與 Babuk 衍生的勒索軟體變種連結，該變種會在檔案後附加 .babyk 副檔名。

其中最需要立即重視的是逆向 SSH。Shadowserver 的結論是，只要系統部署了這項機制，就應視為完全遭到入侵。單純刪除某個二進位檔或移除 cron 工作，並不足以恢復對設備的信任；組織還需要重建受信任的系統狀態，並更換所有高權限憑證。

.babyk 勒索軟體可能也是反鑑識手段

報告中的 .babyk 活動，未必代表一場以大規模加密與勒索為主要目的的傳統勒索軟體攻擊。分析人員推測，選擇性加密 ESXi 日誌，可能是為了干擾調查並掩蓋入侵證據。

但這仍是分析推論，不是已確認的攻擊者意圖。防禦團隊應同時調查兩種可能性：虛擬機器是否受到勒索軟體影響，以及日誌是否遭到蓄意竄改，用來掩飾攻擊活動。

GitHub 儲存庫疑似偽裝逆向 SSH 工具

相關報告還將這次行動與一個 GitHub 儲存庫連結起來。該儲存庫把逆向 SSH 二進位檔包裝成 Linux 暫存檔清理工具。將持久化工具偽裝成管理或清理程式，可能讓工具更容易散布，也降低在例行檢查中被注意的機率。

不過，現有證據尚未獨立確認該儲存庫由誰操作，因此不能把儲存庫的存在本身視為歸因證據。

對 Broadcom 與 VMware 業務的意義

2026 年 8 月 14 日，關於 VMware 漏洞遭到積極利用的報導傳到投資市場後，Broadcom 股價下跌約 5% 至 6%。其中一份報告描述股價由 417.82 美元跌至 392.99 美元。

資安報告是股價下跌的因素之一，但未必是唯一原因。同期報導也提到投資人對 AI 相關債務曝險等更廣泛的疑慮，因此不能把整段跌幅，或精確的市值蒸發金額，全部歸因於 CVE-2026-59310。

目前可取得的資料也不足以證明這次事件已對 VMware 營收造成可量化的下滑。較有根據的短期商業影響，包括客戶修復成本、營運中斷風險與聲譽壓力。至於長期營收影響，仍需要公司公告或更多財務證據才能判斷。

vCenter 管理員現在應該怎麼做？

修補是第一步，不是最後一步。組織應採取以下措施：

1. 立即套用 Broadcom 的修補版本： 為所有受影響的 vCenter 執行更新，優先處理可從網際網路連線，或能從廣泛內部網路觸及的設備。Broadcom 沒有提供替代緩解措施。
2. 發現跡象就先假設已遭入侵： 重點檢查異常 cron 變更、逆向 SSH 檔案、linuxFile、不明的 curl 或 wget 下載、陌生的 vCenter 或 ESXi 管理員帳戶，以及異常的 VMware Directory Service 活動。
3. 隔離可疑設備並保存證據： 在營運條件允許下，重建系統前先保存磁碟映像、日誌與揮發性資料。
4. 更換所有高權限憑證： 包括 vCenter SSO、VMware Directory Service、ESXi 或 root、API、服務帳戶與相連的管理員憑證；同時撤銷現有工作階段並檢視聯邦身分驗證路徑。
5. 確認持久化後應重建，而非只做清理： 將未授權帳戶、cron 工作、二進位檔、SSH 金鑰與通道移除，並納入完整且有紀錄的事件應變流程。
6. 在整個虛擬化環境進行威脅獵捕： 搜尋 .babyk 活動、異常對外 SSH 或 WebSocket 連線、未授權帳戶，以及 ESXi 日誌遭竄改的跡象。
7. 從可信來源恢復日誌與遙測資料： 若日誌或設定已被更改，應使用已知良好且不可變更的備份進行還原。
8. 降低未來暴露面： 將 vCenter 管理介面限制在分段的專用管理網路，並監控 vCenter 與 ESXi 主機的對外連線。

最重要的結論很簡單：所有易受攻擊的 vCenter 系統都必須更新，但不要把「修補成功」等同於「環境乾淨」。快速出現的漏洞利用、逆向 SSH 持久化，以及已回報的憑證濫用，意味著曾暴露在攻擊面的設備都應接受完整入侵調查，並在出現相關指標時按完全遭入侵處理。