返回所有文章
發佈於 · 作者 Renaud Deraison

macOS 26.5 修補十個 WebKit 漏洞——每一個,對 Bromure 使用者來說會是什麼

Apple 於 2026 年 5 月 11 日推出 macOS Tahoe 26.5,總共修補約七十個資安問題,其中包含十個 WebKit 漏洞。我們會逐一走過這份 WebKit 清單,按照漏洞類別來看,並只問 2026 年真正重要的那一個問題——在一台跑著 Bromure 的機器上,這個漏洞實際上能碰到什麼?

一份修補說明,不等於一份威脅模型。「處理惡意構造的網頁內容可能導致 Safari 意外當機」是廠商用客氣的方式說:對某些使用者而言,這個漏洞就是瀏覽器在「另一個東西」開始執行之前所做的最後一件事。真正有用的問題是,那個「另一個東西」能碰到什麼。

2026 年 5 月 11 日,Apple 發布了 macOS Tahoe 26.5 的安全內容說明。 這次更新總共修補了作業系統範圍內大約七十個 CVE,其中有十個落在 WebKit 上——也就是 Safari 的渲染引擎,同時也是 macOS 上每一個「網頁檢視」背後的引擎,從 Mail 的 HTML 渲染器,一路到 App Store 內嵌的瀏覽器。Apple 沒有把這十個列為已知被野外利用。這並不等於說它們沒有被利用過,只是說 Apple 今天沒有指向那個方向的證據。本文其餘的部分會把這份公告照字面接受,然後問一個範圍更窄、也更有用的問題:對 Bromure 使用者而言,每一個漏洞會做出什麼?

簡短的答案就寫在標題裡。較長的答案,才是這套架構為什麼值得寫一篇文章的原因。

把公告講成人話

讀 Apple 的安全公告,有一半是在做詞彙練習。那句經典寫法——「處理惡意構造的網頁內容可能導致」——涵蓋了一整段光譜,從「一個分頁會被關掉」一直到「整台機器沒了」。把它們分開的,是漏洞類別;而公告其實也有把這部分寫出來,只是寫得低調。

macOS Tahoe 26.5 — WebKit CVE 依類別分組source: support.apple.com/en-us/127115, 2026-05-11USE-AFTER-FREE5 個 CVECVE-2026-28883CVE-2026-28942CVE-2026-28946CVE-2026-28947CVE-2026-28953*Apple 公告的影響Safari 意外當機或行程崩潰實際的天花板在渲染器中執行任意程式碼,前提是有可用原語其他記憶體問題3 個 CVE(含 UAF 群組加 2)CVE-2026-28901CVE-2026-28902CVE-2026-28903CVE-2026-28904CVE-2026-28905CVE-2026-28913CVE-2026-28955CVE-2026-43658CVE-2026-28917Apple 公告的影響因記憶體破壞或不當輸入導致行程崩潰邏輯/政策5 個 CVECVE-2026-43660 — CSP 繞過CVE-2026-28907 — CSP 繞過CVE-2026-28962 — 資訊洩漏CVE-2026-28958 — 敏感資料CVE-2026-28971 — iframe 下載 UIApple 公告的影響政策未被執行、敏感資料外洩、跨來源混淆為何重要它們是記憶體漏洞往上爬時踩的階梯*CVE-2026-28953 屬於 Apple 一起列出的 UAF 群組之一;確切子類型沒有被個別列舉。
macOS Tahoe 26.5 中十個 WebKit CVE,依漏洞類別分組。每一類在「以此為起點堆出的攻擊鏈最多能碰到什麼」這個天花板上都不一樣。最下面兩類——具任意程式碼執行潛力的記憶體破壞,以及 use-after-free——在歷來的紀錄上,最常被串成渲染器陷落的攻擊鏈,再進一步進入主機。

Apple 政策上不會公布漏洞可利用性分析。措辭是刻意的:「行程崩潰」可能意指渲染器撞上一個 assert 然後無害地死掉,或者它可能意指渲染器進入了某種狀態——只要再花幾週時間搭配堆積版面操控,攻擊者就能把當機升級成一個寫入原語,再升級成程式碼執行。這個領域的研究者已經一次又一次證明,對於用這種句型公告的 WebKit use-after-free,第二種結局在很大比例下是做得到的—— CVE-2025-43529, 去年 12 月在 macOS 26.2 修補的那個漏洞,公告語言一模一樣,當時就已經在被用於針對性攻擊。所以閱讀這份公告的正確方式,是把它當成下一波野外利用的候選清單,而不是一份「我們知道這些都無害」的清單。

第一類——五個 use-after-free

用一句話來說,use-after-free 就是這樣的漏洞:瀏覽器釋放了一塊用來裝某個物件(DOM 節點、事件監聽器、JavaScript 包裝物)的記憶體,然後還繼續使用那個舊的參照,彷彿物件還活著一樣。等到那個舊參照真的被解參照時,那個位置已經被別的東西塞進去了——可能是頁面剛建立的另一個物件,或是頁面剛塞滿、長得像函式指標位元組的緩衝區。頁面現在控制了一個瀏覽器當成可信來使用的指標。

CVE-2026-28883、CVE-2026-28942、CVE-2026-28946、CVE-2026-28947,以及 CVE-2026-28901 — CVE-2026-28913 群組裡屬於 UAF 的那一部分,就是這次發布的五個 WebKit use-after-free。Apple 把它們歸功給數位獨立研究者,其中一個案例 (CVE-2026-28942) 歸功給與 Claude 合作的 Milad Nasr 與 Nicholas Carlini——這正是 Mozilla 四月那篇文章 所指的同一類 AI 輔助漏洞研究,當時 Mozilla 把單一個 Firefox 發行版裡 271 個修補,歸功給一次早期的 Mythos 執行。

在一台跑著原廠 macOS 26.5、尚未套用這次更新的 Mac 上,這類漏洞在最壞情境下大概長這樣:

  1. 你造訪一個頁面。頁面跑了一段 JavaScript,以某種方式對某個 DOM 操作下手,觸發了 use-after-free。
  2. 渲染器的記憶體被巧妙佈置,讓剛被釋放的位置被攻擊者控制的東西填上。
  3. 程式碼執行落在 Safari 內容行程之中——也就是和你的瀏覽工作階段、你的 cookie、你已登入的分頁,共用同一塊位址空間。
  4. 串接在第一個漏洞之後的第二階段攻擊,從內容沙箱裡逃出來,進入更外層的 Safari 行程。WebKit 的沙箱很穩,但不是堅不可摧;過去幾年有好幾次有紀錄的逃脫。
  5. 一旦脫離沙箱,攻擊者就以你的使用者帳號身分,在你的機器上執行。他們有讀取 ~/Documents~/Library/Keychains~/.ssh 的權限,能存取 Safari 儲存設定檔裡的 cookie、為了離線使用而下載到本機的 iCloud Drive 內容,以及任何躺在你家目錄底下的東西。

這是整條完整的傳統瀏覽器攻擊鏈。沒有一步是假設性的;過去三年,每一步都已經在真實的野外 WebKit 攻擊鏈中被觀察到。

同一個漏洞,在原廠 Safari 裡你的 Mac.你的使用者帳號Safari 內容行程use-after-free 發動渲染器內程式碼執行cookie、設定檔、開著的分頁都可觸及沙箱逃脫(第二階段)以你的使用者帳號身分執行檔案~/Documents鑰匙圈~/LibrarySSH 金鑰~/.sshiCloud Drive已快取的檔案持續化安裝進 LaunchAgents。Mac 已被攻陷。同一個漏洞,在 Bromure 裡你的 Mac.你的使用者帳號每分頁用完即丟 VMChromium 內容行程(但這是 WebKit 漏洞——見下)渲染器內程式碼執行僅限那個用完即丟的客體被圍住——分頁關閉,VM 消滅檔案未受影響鑰匙圈未受影響SSH 金鑰未受影響iCloud Drive未受影響持續化沒有地方可以落腳。主機 Mac 完全沒被動過。
同一個 WebKit use-after-free 在原廠 Safari 與 Bromure 分頁裡引爆時的對照。漏洞兩邊都會發動。差別在於渲染器的另一側放著的是什麼。

右邊那張圖有一個細節值得先把話講清楚:Bromure 並不使用 WebKit。每一個分頁都是在它自己那台用完即丟的 Linux 客體 VM 裡跑 Chromium。所以這幾個 CVE 的字面內容——五個 WebKit use-after-free——並不適用於 Bromure 出貨的那個渲染引擎。一位從來沒套用過 macOS 26.5 的 Bromure 使用者,透過他開著的 Bromure 分頁,並不會暴露在這些特定的 WebKit 漏洞下。

光是這件事本身,並不算什麼有趣的主張。Chrome 自己也有一本記憶體漏洞清單。Firefox 也有。重點是第二層的結論:就算你心裡把這幾個 CVE 替換成同一類別、發生在 Chromium V8 或 Blink 上的 use-after-free—— CVE-2024-7971, 也就是 2024 年北韓相關行為者使用過的那個 V8 型別混淆漏洞,是最明顯的對應例——右邊那張圖也不會改變。漏洞在渲染器裡發動。渲染器在客體 VM 內。程式碼執行落腳在一台 Linux 機器上,而那台機器裡沒有你的鑰匙圈、沒有你的 Documents 資料夾,也沒有你的 SSH 金鑰。分頁一關,VM 就被銷毀。

第二類——再三個記憶體漏洞與一個輸入驗證漏洞

CVE-2026-43658 是這份公告裡,Apple 明確標為「記憶體處理」而非 use-after-free 的唯一一個 WebKit 漏洞;公告影響為 Safari 意外當機。CVE-2026-28917 被標為輸入驗證問題,同樣會造成行程崩潰。兩個都和那批 use-after-free 落在同一個籃子裡——它們都是惡意頁面在 WebKit 位址空間裡造成的當機——而且兩個都有同樣的實際天花板:只要工程量夠多,「當機」在某些情況下能被升級成程式碼執行原語,在另外一些情況下則真的就只是當機而已。Apple 沒告訴我們是哪一邊,而修補本身快速瀏覽過去,也沒有給出答案。

值得強調的點是:對使用者而言,這個區別並不會改變架構上的答案。在原廠 Safari 上,就算是一個看起來無害的 WebKit 當機漏洞,最糟糕也是一個落腳點。在 Bromure 上,就算是這類漏洞的最壞情境——渲染器內完整程式碼執行——也只是發生在一個即將被丟掉的客體裡的程式碼執行事件。

第三類——五個邏輯與政策漏洞

這份公告裡十個 WebKit 漏洞中,有五個根本不是記憶體漏洞。它們是邏輯漏洞——Safari 的安全政策說該允許什麼,與它的程式碼實際上執行了什麼,之間的小小不一致。

CVE-2026-43660 與 CVE-2026-28907——CSP 繞過

內容安全政策(CSP)是網站用來告訴瀏覽器「只執行這些來源的 JavaScript、只載入那些來源的圖片」的機制。這兩個漏洞都讓惡意構造的頁面,能在剖析器的某條路徑上,讓 Safari 跳過 CSP 的執行。真實後果:原本以為自己受 CSP 保護的網站上,一個儲存型 XSS 現在會被執行。

CVE-2026-28962 與 CVE-2026-28958——資訊洩漏

兩個都讓惡意頁面能讀到它本來不該存取的資料。第一個發生在 WebKit 的存取控制邏輯;第二個在它的資料保護路徑上。把它們串在攻擊鏈中,這就是把「我在你的渲染器裡有程式碼執行」變成「我拿到了你登入的另一個站台的工作階段 cookie」的那種漏洞。

CVE-2026-28971——iframe 下載偽冒

惡意 iframe 能借用父頁面的下載設定。表面上看是一個 UI 漏洞;實務上,它是讓 drive-by 下載得以搭乘使用者明確信任以儲存檔案的網站的辦法。一個教科書級的惡意程式初始入侵原語。

這些邏輯漏洞是用來幹嘛的

單獨來看,沒一個能拿到程式碼執行。它們的價值在結構上:每一個,都是上面那些記憶體漏洞往上爬時要踩的一級階梯。一個赤裸裸的 use-after-free,沒有方法洩漏指標、沒有方法繞過 CSP、沒有方法讀取跨來源狀態的話,是很難武器化的。同一個發行版裡的邏輯漏洞,就是每一條公開攻擊鏈裡安靜的那一半。

同樣的論點也適用於 Bromure 這邊,只是有一個澄清值得提出來。下載偽冒那個漏洞(CVE-2026-28971)很有意思,因為它是這份清單上唯一一個——在原廠 Safari 上——能在硬碟上產生一個使用者之後可能會打開的檔案的漏洞。Bromure 從分頁內的下載,預設是落在那個分頁的客體 VM 裡的;要把它們提升出客體之外,是一個明確的使用者動作。一個頁面成功讓人「下載」下來的 drive-by 檔案,在 Bromure 上其實是一個躺在即將消失的 Linux 客體裡的檔案。那兩個跨來源資訊洩漏(CVE-2026-28962、CVE-2026-28958)能讀到的,就是渲染器看得到的資料,而在 Bromure 上,那等同於那一個分頁 VM 內所擁有的資料而已。

房間裡仍然存在的東西:VM 不會去隔離的那些事

如果就讀完上面那段就走人,太容易拿到錯的結論。Bromure 的架構,擅長的是縮小渲染器陷落的爆炸半徑。它不是魔法。有幾件事仍然待在房間裡,值得明白地說清楚。

工作階段本身仍會被攻陷

這些漏洞有可用的 exploit 時,依然會拿下漏洞所在的那個分頁。攻擊視窗期間在那個分頁裡輸入的密碼,都在範圍內。那個分頁用的設定檔裡儲存的 cookie,都在範圍內。表單資料,也都在範圍內。Bromure 的設定檔分離,能保證損害僅限於那個設定檔,不會擴及使用者的整個數位生活,但這並不是零。

剪貼簿就是那座最明顯的橋

Bromure 預設姿勢下,會把剪貼簿開放給客體,因為對大多數使用者來說,每天打壞「複製貼上」的代價,比起罕見的攻擊情境,是划不來的。這個姿勢是個刻意的選擇,而我們可以針對你想讓它徹底封閉的工作階段,按需把它切斷。但這座橋確實存在,值得知道。

Hypervisor 逃脫仍在棋盤上

一條足夠堅定的攻擊鏈,原則上可以一路逃出 Apple Silicon 的 hypervisor 本身。那邊的攻擊面,比起一個瀏覽器小上好幾個數量級,而這類漏洞的公開紀錄也很短,但它不是零。我們並不主張免疫;我們主張的是:我們已經把「你的安全所依賴的那個漏洞類別」整個搬到了別處。

沒有擴充功能、沒有瀏覽器輔助層

Bromure 根本不允許安裝 Chrome 擴充功能。這是一種立場,不是一個設定。它移除了一整個第二攻擊面——每一個擴充功能都是它自己那條準受信任的程式碼路徑,帶著與渲染器並列的權限——而歷來在現實世界中,這正是非常多的瀏覽器陷落最後得以持續化的途徑。

為什麼 Mac 和瀏覽器想要成為兩台不同的機器

上面的一切,其實有一個更一般化的講法。一台現代的 Mac,在同一個信任域裡,並排放著:

  • 作業系統,連同你的檔案與你的鑰匙圈。
  • 你安裝過的原生應用程式,連同它們所請求過的任何權限。
  • 瀏覽器,這是系統上目前為止最大的一塊「可被攻擊者操控的剖析機器」。

當一個 WebKit 漏洞在原廠 macOS 上發動時,系統中剛剛被攻陷的那一塊,正好就是對其他兩塊都有讀取權的那一塊。這不是 Safari 的錯;這只是把瀏覽器當作一支使用者空間應用程式、與使用者其他所有事情並排執行,所帶來的直接後果。

Bromure 的設計,把瀏覽器與其餘部分的 Mac 當作不同的機器來看待。瀏覽器其實是跑在一台不同的機器上的——一台 Linux 客體、一顆虛擬 CPU、加上每次工作階段都會重置的虛擬磁碟。主機 Mac 只透過一組很窄的 hypervisor 呼叫看到客體:畫面緩衝、輸入、網路,以及在允許時的剪貼簿。一個 WebKit 等級的漏洞——或它在 Chromium 上的對應品——只要落在客體裡,從主機角度來看,就是一段跑在另一台電腦上、不同作業系統上、且沒有路徑通往使用者檔案的程式碼。那兩台「電腦」共用一個機殼這件事,只是一個實作細節。

今天該做什麼

如果你是在那台你拿來做所有事的 Mac 上讀這篇,最重要的就是那件無聊的事:套用 macOS 26.5 更新。從 Apple 推出修補到有人把它變成可用 exploit 之間的時間窗,按業界自己的測量,現在是以小時計,而不是以週計。已套用更新的原廠 Safari 使用者,對上述十個 WebKit 漏洞有受到保護;沒套用的,則沒有。

如果你是在 Bromure 上讀這篇,你之所以對 WebKit 等級的渲染器漏洞受到保護,是因為架構,而不是因為修補套用率——因為渲染器不是 WebKit、不是跑在主機上、而且躲在一個分頁關閉就會被銷毀的客體裡。你還是應該套用 macOS 26.5 更新,因為這次發行的另外大約六十個 CVE,修補的是 macOS 上 Bromure 並不負責隔離的部分——核心元件、系統服務、原生框架——而那些仍然重要。

我們希望更多人採用的看法是這樣的:WebKit 的 0-day 不會停下來。Chromium 的 0-day 也不會停下來。對任一位使用者而言,可以停下來的,是「一個頁面出了錯」和「你的電腦出了錯」之間那條連線。那條連線,就是 Bromure 被造出來要切斷的——一份十個 CVE 的公告,又一份十個 CVE 的公告,一份一份切。

安裝 Bromure。繼續套用你的 macOS 更新。下一次 Apple 推出一個 Safari 更新,說「處理惡意構造的網頁內容可能導致」——而那會很快發生,因為現在這個節奏是按月在跑——讀完那句話,把它歸檔,並注意到:對你一天裡待在 Bromure 內的那部分時間而言,這個句子,後面沒有下文。