macOS 螢幕分享漏洞遭駭客主動開採不需密碼就能接管整台 Mac

編按：本文綜合整理自 Ars Technica、MacStadium、Huntress 與 Mac Mini Vault 等資安廠商與媒體的公開資料，並加入 Siami 編輯部觀點與分析。

Apple 在 8 月 6 日緊急修補 macOS 螢幕分享（Screen Sharing）服務的重大漏洞 CVE-2026-65400，這個漏洞允許同網段的攻擊者完全不需要任何帳號密碼，就能遠端接管一台開著螢幕分享的 Mac。事件在 Black Hat 安全會議上被公開，並已被多家資安廠商與託管服務商證實有攻擊流量正在進行。

漏洞核心：CVE-2026-65400 是什麼這個漏洞出在 macOS 螢幕分享功能的**狀態管理（state management）**邏輯中——也就是負責追蹤先前事件、使用者操作、變數與系統狀態的程式碼。Apple 在自家的安全公告中以保守的「may」字眼描述，但多家廠商隨後確認實機攻擊已經發生。

• CVSS 評分：7.1（高風險）
• 攻擊面：TCP port 5900（macOS 螢幕分享預設 port）
• 漏洞類型：預先驗證遠端程式碼執行（Pre-auth RCE）
• 修補版本：macOS Tahoe 26.6.1、Sequoia 15.7.9、Sonoma 14.8.9
• 最初披露時機：2026 年 Black Hat 安全會議

特別值得留意的是，這已經是螢幕分享服務在十天內被揭露的第二個漏洞——7 月 27 日修補的 CVE-2026-43760 雖然性質相近，但攻擊者仍需具備有效憑證；CVE-2026-65400 卻完全跳過這道門檻。

「兩個漏洞的差別，就在於攻擊者是否需要帳號密碼——而這正是真正的分水嶺。」— Huntress 部落格

為什麼這件事重要這不是普通的 RCE 漏洞，因為它違反了大多數 Mac 使用者的基本信任假設：「就算螢幕分享不小心開了，攻擊者也得先有密碼才進得來」。CVE-2026-65400 把這個假設整個推翻，導致以下三個現實風險：

1. 家庭網路即攻擊面：同一個 Wi-Fi 下的任何裝置（包括已被入侵的 IoT 裝置或鄰居蹭網的筆電）都能直接攻擊你的 Mac。
2. 託管 Mac mini 機房集體中招：MacStadium 等託管商已觀察到攻擊流量，緊急在 edge firewall 封鎖 5900 port，因為他們代管的機器通常都開著螢幕分享給管理員。
3. 企業 CI / 測試機台變後門：許多團隊用 Mac mini 跑 CI，預設開螢幕分享方便遠端維護——這正好是攻擊者最愛的目標。對企業 IT 而言，這個漏洞也提醒一件事：Mac 基礎設施不該被當作「另一種終端裝置」看待，patch management、網段隔離、存取控制、監控、最小權限這些原本屬於伺服器與雲端的做法，在 Mac mini 機房同樣必要。

數據解讀：Apple 公告與實況的落差

Apple 在公告中用「may」一詞描述漏洞的可能性，這在科技業揭露漏洞時很常見——研發團隊通常不願意在沒有 100% 證據前斬釘截鐵。但 Ars Technica 引述多家資安廠商指出，攻擊確實正在發生，而且已經被觀測到：

• MacStadium：在客戶端觀察到攻擊流量，已在 edge 封鎖 5900 port。
• Huntress：列出明確的偵測特徵——會看到至少一個 root 事件；如果攻擊者嘗試枚舉帳號，log 中會出現 session_username: null。
• Mac Mini Vault：將 CVE-2026-65400 評為 RCE 而非單純的認證繞過。這種「官方說『可能』，社群說『正在發生』」的落差，在 CVE 公告中屢見不鮮，但對 IT 管理者來說，當多家獨立資安廠商都看到攻擊，就該當成 active exploitation 處理——而不是等到 Apple 自己把字眼升級成「actively exploited」。

受影響範圍與建議行動

如果你用 Mac，以下三件事應該今天就做：

1. 立刻更新：打開「系統設定 → 一般 → 軟體更新」，確認版本是 macOS Tahoe 26.6.1、Sequoia 15.7.9 或 Sonoma 14.8.9（依你的 macOS 主版本而定）。這是唯一完全修補 CVE-2026-65400 的版本。
2. 檢查螢幕分享是否開啟：「系統設定 → 一般 → 分享」中，如果「螢幕分享」亮綠燈，且沒有人正在使用，就該關掉它——特別是你不確定為什麼它開著的時候。
3. 家用路由器擋 port 5900：如果你有 Mac admin 經驗，可以在路由器 firewall 加一條規則擋掉對內 5900 的連線，這是 belt-and-suspenders 的額外防線。

如果你管 Mac mini 機房：

• 立刻在 firewall 封掉 5900 port 對外暴露
• 確認所有機器都已更新到 26.6.1 / 15.7.9 / 14.8.9
• 檢查 log 找 root 事件 + session_username: null 的組合，這是 Huntress 標記的 exploit 痕跡
• 評估把螢幕分享改成 jump host + SSH 的方案，永久降低曝險

漏洞技術細節與後續觀察從 Huntress 的分析來看，這次漏洞與 7 月底的 CVE-2026-43760 屬於同一個程式碼區塊的不同缺陷，顯示 Apple 的螢幕分享服務在狀態管理層面可能還有其他未公開的問題。安全研究人員在 Black Hat 現場展示了一段 exploit 影片，雖然 Apple 的「may」字眼與實際觀測有落差，但從漏洞的修補速度（緊急更新、非例行性 patch cycle）來看，Apple 內部應該早就知道這個問題的嚴重性。接下來值得關注的是：

• Apple 是否會在後續版本加 log 強化：Huntress 列出的偵測特徵（root 事件 + session_username: null）目前在 log 中並不明顯，攻擊發生時管理員可能根本看不到。
• CISA 是否會把 CVE-2026-65400 加進 KEV（Known Exploited Vulnerabilities）目錄：以目前的 active exploitation 證據，加進去是遲早的事。加進去之後，美國聯邦機構有 3 週修補期限，這會進一步拉高企業修補的優先度。
• 其他 macOS 服務是否也有類似 state management 問題：研究人員在 Black Hat 公開細節後，預期會有更多漏洞被挖掘與回報。

留言

「又是 state management 出包。螢幕分享這種服務一直接 5900 公開給網路，本來就不該存在。」 — Hacker News 用戶（28 推）

「可怕的不是漏洞本身，而是『不需帳密』。一般使用者根本不知道自己的 Mac 開了螢幕分享，更不會想到要關 port 5900。」 — Hacker News 用戶（22 推）

「Mac admin 圈應該早就把這條封了。家用使用者才是最大受害者——他們連 macOS Tahoe 是哪個版本都搞不清楚。」 — Hacker News 用戶（19 推）

「Apple 說『may』，Ars 說『is』，兩個說法差距很大。看來 Apple 安全團隊這次對外溝通又翻車了。」 — Hacker News 用戶（15 推）

「給 MacStadium 拍拍手，預設就封 port 5900。這種 edge 防禦本來就該是 hosting 標配。」 — Hacker News 用戶（12 推）