macOS 26.5が塞いだ10件のWebKit脆弱性 — Bromureユーザーにとって、それぞれが何を意味したのか
Appleは2026年5月11日にmacOS Tahoe 26.5をリリースし、約70件のセキュリティ修正のうち10件がWebKitの脆弱性でした。CVEクラスごとに一つずつWebKitのリストをたどりながら、2026年において本当に重要なただ一つの問い — Bromureが動いているマシンで、このバグは実際にどこまで届くのか — を考えます。
パッチノートは脅威モデルではありません。「悪意を持って細工されたウェブコンテンツの処理が、Safariの予期しないクラッシュにつながる可能性がある」というのは、一部のユーザーにとってそのバグが、ブラウザが何か別のものを動かす前に最後にやったことだった、という事実をベンダーが上品に言い換えたものです。本当に役立つ問いは、その「別のもの」が触れられる範囲はどこまでか、ということです。
2026年5月11日、Appleは About the security content of macOS Tahoe 26.5 を公開しました。このリリースはOS全体で約70件のCVEを塞いでおり、そのうち10件はWebKitの内部 — Safariのレンダリングエンジンであり、Mail のHTMLレンダラーからApp Storeに組み込まれたブラウザに至るまで、macOS上のあらゆる「ウェブビュー」の裏側でも動いているエンジン — に属します。10件のいずれも、Appleは「実際に悪用されている」とは記載していません。これは「悪用されていなかった」と言っているのと同じではなく、単に「現時点でAppleにはそれを示す証拠がない」というだけのことです。本記事ではこのアドバイザリーを額面どおりに受け取り、もっと狭く、もっと役に立つ問いを立てます。すなわち、これらのバグそれぞれについて、Bromureユーザーにとっては何を意味したのか、ということです。
短い答えはタイトルにあります。長い答えこそが、このアーキテクチャを文章にして残す価値のあるものです。
アドバイザリーを、平易な言葉で
Appleのセキュリティノートを読むことは、半ば語彙の練習でもあります。お決まりの言い回し — 「悪意を持って細工されたウェブコンテンツの処理が…につながる可能性がある」 — は、「タブが閉じる」から「マシンが乗っ取られる」までの広いスペクトルを覆っています。両者を分けるのはバグクラスであり、アドバイザリーはそれも書いてくれてはいるのですが、控えめにそう書いているにすぎません。
Appleは方針として、悪用可能性の分析を公表しません。文言は意図的に選ばれています。「プロセスクラッシュ」は、レンダラーがアサートに引っかかって無害に死ぬという意味にもなれば、レンダラーが、数週間の作業とヒープグルーミングを経て攻撃者によって書き込みプリミティブに、そして最終的にコード実行に変換しうる状態へ陥った、という意味にもなりえます。この分野の研究者たちは、まさにこの言い回しで公表されたWebKitのuse-after-freeの大半について、後者の結末が達成可能であることを繰り返し示してきました。昨年12月にmacOS 26.2で修正された CVE-2025-43529 も、これと一字一句同じ表現で記述されており、公表時点で実際に標的型攻撃に悪用されていました。ですからこのアドバイザリーは、「無害だと分かっているバグのリスト」としてではなく、「次の実環境での悪用ラウンドに名乗りを上げそうな候補のリスト」として読むのが正しい読み方です。
クラスその一 — 5件の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に分類されるサブセットの5件が、今回のリリースに含まれるWebKitのuse-after-freeです。Appleはこれらを独立系の研究者たちに帰属させており、そのうち1件 (CVE-2026-28942) はMilad NasrとNicholas Carlini両氏がClaudeとともに発見したものとされています — これは、Mozillaが 4月に 初期のMythosの実行が1つのFirefoxリリースで271件の修正に貢献したと記述した、AI支援型の脆弱性研究の広い範疇と同じものです。
このアップデートを適用する前の、素のmacOS 26.5を走らせているMac上で、これらのバグのうちの一つの最悪ケースは、おおむね次のように展開します。
- ユーザーがあるページを訪れる。そのページはJavaScriptを実行し、use-after-freeを発火させるようなDOM操作を仕掛ける。
- レンダラーのメモリがグルーミングされ、解放された枠が攻撃者の支配下にあるもので埋められる。
- Safariのコンテンツプロセス内でコード実行が成立する — そこは、あなたのブラウジングセッション、クッキー、ログイン済みタブと同じアドレス空間です。
- 第二段の攻撃が第一段に連鎖し、コンテンツサンドボックスを抜けてより広いSafariプロセスへと脱出する。WebKitのサンドボックスは堅牢ですが破られないわけではなく、ここ数年だけでも複数のサンドボックス脱出が記録されています。
- サンドボックスの外に出てしまえば、攻撃者はあなたのユーザーアカウントとして、あなたのマシン上で動いています。
~/Documents、~/Library/Keychains、~/.sshの読み取り、Safariの保存プロファイルにあるクッキー、オフライン利用のためにダウンロード済みのiCloud Driveの中身、そしてホームディレクトリ配下にあるありとあらゆるものへアクセスできます。
これが、伝統的なブラウザでの攻撃チェーンの全体像です。どのステップも仮想的な話ではなく、この3年間の実環境で観測されたWebKit攻撃チェーンに、すべて実例があります。
右側の図には、はっきりさせておくべき細部が一つあります。BromureはWebKitを使っていません。各タブは、使い捨てのLinuxゲストVMの中でChromiumを走らせています。ですから、これらのCVEの文面どおりの内容 — 5件のWebKit use-after-free — は、Bromureが同梱しているレンダリングエンジンには当てはまりません。macOS 26.5を一度も適用していないBromureユーザーは、Bromureの開いているタブを通じて、これらの特定のWebKitバグにさらされてはいません。
それ自体は、それほど興味深い主張ではありません。Chromeにも自前のメモリバグのカタログがあり、Firefoxにも自前のものがあります。重要なのは二次的な論点のほうです。これらのCVEを、頭の中でChromium V8やBlinkの同等クラスのuse-after-free — 北朝鮮系の攻撃者が2024年に使った V8の型混同 CVE-2024-7971 が分かりやすい類比です — に置き換えたとしても、右側の絵は変わりません。エクスプロイトはレンダラー内で発火します。レンダラーはゲストVMの中にあります。コード実行が降り立つのは、あなたのキーチェーンも、Documentsフォルダも、SSH鍵も入っていないLinuxの箱の中です。タブが閉じれば、VMは破棄されます。
クラスその二 — さらに3件のメモリバグと、入力検証のバグ
このアドバイザリーの中で、Appleがuse-after-freeではなく「メモリの取り扱い」と明示的にラベル付けしているWebKitバグはCVE-2026-43658だけで、記載されている影響は「Safariの予期しないクラッシュ」です。CVE-2026-28917は入力検証としてラベル付けされており、こちらもプロセスクラッシュを生じます。どちらもuse-after-freeと同じ大枠 — 敵対的なページによって引き起こされる、WebKitのアドレス空間でのクラッシュ — に属しており、現実的な上限もこれと同じです。十分な労力をかければ、ケースによっては「クラッシュ」をコード実行プリミティブへ昇格できることがあり、別のケースでは本当にただのクラッシュにとどまります。Appleはどちらかを教えてはくれませんし、ざっと読んだ限りパッチからもその答えは出ません。
強調すべき点は、ユーザーにとってはこの区別がアーキテクチャ上の答えを変えないということです。素のSafariでは、WebKitの一見良性なクラッシュバグでさえ、最悪の場合は足がかりになります。Bromureでは、これらのバグの最悪ケース — レンダラー内での完全なコード実行 — でさえ、いずれ捨てられるゲストの中でのコード実行イベントにすぎません。
クラスその三 — 5件のロジックとポリシーのバグ
このアドバイザリーの10件のWebKitバグのうち5件は、そもそもメモリバグではありません。これらはロジックバグであり — Safariのセキュリティポリシーが許可していると言っているものと、そのコードが実際に強制しているもののあいだに生じる、小さな食い違いです。
CVE-2026-43660とCVE-2026-28907 — CSP回避
Content Security Policyは、ウェブサイトがブラウザに「JavaScriptはこのオリジンからだけ実行してよい、画像はあちらのオリジンからだけ読み込んでよい」と伝えるための仕組みです。これら2件のバグは、悪意を持って細工されたページがパーサーのある経路で、Safariにそのポリシーの強制をスキップさせることを許します。実際の帰結は、CSPに守られていると信じていたサイト上の保存型XSSが、いま現に実行されてしまう、ということです。
CVE-2026-28962とCVE-2026-28958 — 情報漏えい
どちらも、敵対的なページが本来アクセスできないはずのデータを読めるようにします。1件目はWebKitのアクセス制御ロジック内、2件目はデータ保護経路内のものです。連鎖の中で使われると、これらは「あなたのレンダラーでコード実行している」を「あなたがログインしていた別サイトのセッションクッキーを持っている」へと変えてくれるバグです。
CVE-2026-28971 — iframeのダウンロード偽装
悪意あるiframeが、親ページのダウンロード設定を利用できます。表面的にはUIのバグですが、実際にはドライブバイダウンロードが、ユーザーが「ファイルを保存してよい」と明示的に信頼したサイトに便乗するための経路です。マルウェアの初期アクセスプリミティブの教科書例です。
ロジックバグが何のためにあるのか
単独では、これらはいずれもコード実行を授けません。価値は構造的なものです。一つひとつが、上のメモリバグが登るのに使う梯子の一段なのです。剥き出しのuse-after-freeを武器化するのは、ポインタをリークする手段、CSPを回避する手段、クロスオリジンの状態を読み取る手段がなければ困難です。同じリリースに含まれるロジックバグは、公の攻撃チェーンすべての「静かな半分」です。
同じ論法はBromure側でも成り立ちますが、はっきりさせておく価値のある補足が一つあります。ダウンロード偽装のバグ（CVE-2026-28971）が興味深いのは、このリストの中で唯一、素のSafariでは、ユーザーが後で開いてしまうかもしれないファイルがディスク上に生成されうるバグだ、という点です。Bromureでは、タブの内側からのダウンロードは既定でそのタブのゲストVM内に着地し、ゲストの外へ持ち出すのはユーザーの明示的な操作です。ページがどうにか「ダウンロードさせた」ドライブバイファイルは、Bromureにおいては、まもなく消えるLinuxゲスト内のファイルにすぎません。クロスオリジンの情報漏えい（CVE-2026-28962、CVE-2026-28958）が読み取るのはレンダラーから見えるデータであり、Bromureにおいてそれは、その一つのタブのVM内に存在するデータだけです。
部屋に残るもの：VMが隔離するものと、しないもの
ここまでの話から、間違った教訓を持って帰ってしまうのは容易です。Bromureのアーキテクチャは、レンダラー侵害の影響範囲を狭めることに長けています。しかし魔法ではありません。それでも部屋に残るものがいくつかあり、はっきり書いておく価値があります。
セッションそのものは侵害される
これらのバグの一つで実際に動くエクスプロイトは、それでもなお発火したタブの中身は手中に収めます。エクスプロイト発動中にそのタブに入力されたパスワードは射程内です。そのタブが使っているプロファイルに保存されたクッキーも射程内です。フォームデータも射程内です。Bromureのプロファイル単位の分離は、被害が「ユーザーのデジタル生活全体」ではなく「そのプロファイル」に限られることを保証しますが、ゼロにするわけではありません。
クリップボードが分かりやすい橋
Bromureの既定の姿勢では、クリップボードはゲストから利用可能なままにしてあります。ほとんどのユーザーにとって、毎日コピー&ペーストが壊れるコストのほうが、まれな攻撃シナリオよりも重いからです。これは意図して選んだ姿勢であり、密閉したいセッションについてはオンデマンドで切り離せます。橋が存在することは知っておく価値があります。
ハイパーバイザー脱出はまだ視野に
十分に執拗な攻撃チェーンであれば、原理的にはApple Siliconのハイパーバイザーそのものを脱出することもできます。そこの攻撃面はブラウザのそれより数桁小さく、公知のバグの記録は短いですが、ゼロではありません。我々は免疫を主張しているのではなく、あなたの安全が依存するバグクラスを動かしたのだ、と主張しているのです。
拡張機能なし、ブラウザヘルパー層なし
Bromureは、そもそもChrome拡張機能のインストールを一切許可しません。これは設定ではなくスタンスです。これによって第二の攻撃面 — 拡張機能はそれぞれが、レンダラーの脇で権限を持つ準信頼コード経路であり、現実世界のブラウザ侵害が永続化を獲得する経路として歴史的に多用されてきたもの — がまるごと取り除かれます。
なぜMacとブラウザは別のマシンでありたいのか
これまでのすべては、もっと一般的な言い方ができます。現代のMacは、同じ信頼ドメインの中に、肩を並べて次のものを抱えています。
- OS、つまりあなたのファイルとキーチェーン。
- インストール済みのネイティブアプリ、それぞれが要求したエンタイトルメント。
- ブラウザ、すなわちシステム上で群を抜いて大きな、攻撃者の制御下にある入力を解析する機械。
素のmacOS上でWebKitバグが発火したとき、たった今侵害された部分こそが、システム上の他の二つに読み取りアクセスを持っている部分です。これはSafariの失敗ではなく、ブラウザをユーザー空間アプリとして、ユーザーが他にやっているすべてのことと一緒に走らせていることの、自然な帰結にすぎません。
Bromureの設計は、ブラウザと残りのMacを、別々のマシンとして扱います。ブラウザは実際に別のマシン — 仮想CPU上のLinuxゲスト、セッションごとにリセットされる仮想ディスク — の上で動いています。ホストのMacから見えるゲストは、ハイパーバイザー呼び出しの狭い集合 — フレームバッファ、入力、ネットワーク、許可されていればクリップボード — を通してだけです。ゲスト内に着地したWebKitクラスのバグ — あるいはそのChromium相当 — は、ホストの視点から見れば、別のコンピュータ上で、別のオペレーティングシステム上で、ユーザーのファイルへの経路をいっさい持たずに走っているコードにすぎません。二つの「コンピュータ」が同じ筐体を共有しているという事実は、実装上の細部です。
今日できること
ふだん何でもこなしているMacでこれを読んでいるなら、いちばん大切なのは退屈な選択肢です。macOS 26.5アップデートを適用してください。Appleがパッチを出してから誰かがそのパッチを実働するエクスプロイトに仕立てるまでの時間幅は、いまや業界自身の計測によれば、週ではなく時間で測られるものです。このアップデートを適用した素のSafariユーザーは、上記の10件のWebKitバグから守られます。適用していないユーザーは守られません。
Bromureでこれを読んでいるなら、あなたはWebKitクラスのレンダラーバグからは、パッチの適用状況ではなくアーキテクチャによって守られています。レンダラーがWebKitではなく、ホスト上では走っておらず、タブを閉じれば破棄されるゲストの中にいるからです。それでもmacOS 26.5アップデートは適用すべきです。なぜなら、このリリースに含まれる残り約60件のCVEは、Bromureが隔離していないmacOSの部分 — カーネル構成要素、システムサービス、ネイティブフレームワーク — を修正しており、それらは依然として重要だからです。
我々がもっと多くの人に使ってほしい捉え方は、これです。WebKitのゼロデイは止まりません。Chromiumのゼロデイも止まりません。止まりうるのは、特定のユーザーにとっての「ページが間違っていた」と「あなたのコンピュータが間違っていた」のあいだのつながりです。そのつながりこそ、Bromureが断ち切るために作られたものであり、10件のCVEのアドバイザリーひとつごとに、それを実行していくのです。
Bromureをインストールしてください。macOSのアップデートを適用し続けてください。そして次にAppleが「悪意を持って細工されたウェブコンテンツの処理が…につながる可能性がある」と書かれたSafariアップデートを出したとき — そしてそれはすぐ起きます、いまやリリースの周期は月単位ですから — その一行を読み、記憶に留め、そしてBromureの中で過ごす時間に関する限り、その一文は最後まで完結しないのだということに、気づいてください。