AIが見つけたmacOSのroot脆弱性は、なぜAIの報告洪水に埋もれたのか

そのバグは、クラッシュしなかった

Appleは2026年7月27日、macOS Tahoe 26.6とSonoma 14.8.8を公開した。セキュリティ情報には、Screen Sharing Serverのアクセス制御を強化し、CVE-2026-43760を修正したとある。Appleが示した影響は「アプリがユーザーの機微なデータへアクセスできる可能性」だ。

一方、この欠陥を検証したイタリアのセキュリティ企業Bynarioは、影響がそこにとどまらないと主張する。同社の実験では、保護されたファイルの読み出しに加え、攻撃者が選んだ内容をroot所有の新規ファイルとして作成できた。さらに、権限昇格に使われる設定ディレクトリへ有効なポリシーファイルを置き、root権限でコマンドを実行するところまで確認したという。

ただし、誰でもインターネット越しにMacを乗っ取れる欠陥ではない。攻撃が成立するには、次の3条件が必要だ。

必要条件	意味
画面共有またはリモートマネジメントが有効	脆弱なサービスへ到達できる
「VNC使用者がパスワードで画面を操作することを許可」が有効	古いVNC認証経路が使える
攻撃者がVNCパスワードを知っている	認証後の攻撃であり、認証不要ではない

更新の目安：該当するMacはTahoe 26.6またはSonoma 14.8.8へ更新したい。すぐに更新できない場合は、旧式のVNCパスワード認証を無効化する。遠隔操作が不要なら、画面共有とリモートマネジメント自体を止める。VNCパスワードの変更だけでは、未修正OSの認可ミスは直らない。

このバグが興味深いのは、バッファオーバーフローでも、解放済みメモリの再利用でもない点だ。Appleが強化してきたMemory Integrity EnforcementやPointer Authentication Codeを破ったわけでもない。正しい形式の要求を、正規のApple製プロセスが、間違った権限で処理した。すべての部品が単独では正常に動きながら、全体として危険な結果を生む「認可のロジックバグ」だった。

従来型の発見シグナル	CVE-2026-43760の発見シグナル
クラッシュ、異常終了、メモリ破壊	認証経路によって実行UIDが変わる
不正な入力で処理が壊れる	正常な入力が過剰な権限で成功する
1プロセス内の異常を追う	認証、ヘルパー起動、ファイル操作を横断する

VNCパスワードがroot権限に化けるまで

macOSの画面共有は、RFBというVNC系のプロトコルを扱う。Apple独自の認証では、接続した人がどのmacOSユーザーなのかを特定できる。ファイルを送受信するヘルパーは、そのユーザーのUIDで動く。一般ユーザーとして接続したなら、そのユーザーが読めないファイルは読めず、書けない場所には書けない。

問題は、互換性のために残された旧式のVNC認証だった。この経路で確認できるのは「別途設定されたVNCパスワードを知っている」という事実だけだ。macOSのユーザーアカウントと結びついていないため、本来はファイルシステム上の身元を与えられない。ところがBynarioの検証では、この経路から起動したファイル転送ヘルパーがUID 0、つまりrootの権限を保持していた。

• 正常な経路：NATIVE LOGIN → Screen Sharing → FILE COPY HELPER（USER UID）→ 通常のアクセス制御
• 脆弱な経路：VNC PASSWORD → Screen Sharing → FILE COPY HELPER（UID 0／ROOT）→ 保護領域を読み書き

送信側のヘルパーがrootのままなら、接続者が指定した保護ファイルを読み出せる。受信側がrootのままなら、接続者が指定した内容とパーミッションで新しいファイルを作れる。Bynarioは後者を使い、sudoが読み込む設定ファイルをroot所有・モード0440で作成した。ここで重要なのは具体的なファイル名ではなく、画面操作だけを許したはずの認証情報が、rootのファイル操作権限へ変換されたことだ。

認証経路	確認できる身元	ヘルパーが使うべき権限	Bynarioの検証結果
Apple独自認証	macOSユーザー	認証ユーザーのUID	UID 502で動作し、保護領域への操作は失敗
旧式VNC認証	VNCパスワードの所持	画面共有に限定された権限	UID 0で動作し、保護領域への読み書きが成功

これは「混乱した代理人」と呼ばれる問題に近い。強い権限を持つサービスが、弱い権限しか持たない依頼者の代わりに仕事をする際、依頼者の権限へ落とさない。AIがこの差分を追えたというBynarioの説明が正しければ、AIによる脆弱性探索は、クラッシュを大量に起こす段階から、複数の認証経路と権限境界を意味的に比べる段階へ進んでいる。

AIが見つけ、AIが届かなくした

Bynarioは、この欠陥を自社の自動脆弱性探索ワークフローで発見し、GPT-5.5を探索と検証に使ったとしている。ただし同社の記事は、自社製品Atlasの能力を紹介するマーケティングでもある。発見過程の再現性や、人間がどこまで介在したかは外部から完全には検証できない。「AIが単独で見つけた」と単純化せず、同社がAIを組み込んだ工程で発見し、人間が実機で影響を確認した事例と捉えるのが妥当だ。

Appleのセキュリティ情報も、功績をBynarioだけに帰していない。CVE-2026-43760の報告者として、BynarioのAlfredo Pesoli氏に加え、wdszzmlとAtuin Automated Vulnerability Discovery Engineを記載している。少なくとも、複数の経路から同じ欠陥へ到達した可能性がある。

それでも、この事例を際立たせるのは報告窓口の問題だ。TechRadarは、Bynarioが3週間で50件を超えるバグを提出し、Appleが設けた同時進行案件の上限に達していたため、この欠陥を通常の窓口からすぐに報告できなかったと伝えた。最終的にはApple側から直接連絡し、確認と修正が進んだという。

時点	発見・報告をめぐる動き
2026年、修正前	BynarioのAI活用ワークフローが認証経路の権限差を発見したと説明
報告段階	50件超の提出後、同時進行案件の上限で通常提出できなかったと報道
その後	AppleがBynarioへ直接連絡し、検証が進んだと報道
7月27日	Tahoe 26.6とSonoma 14.8.8で修正
7月29日	Bynarioが技術詳細を公開

ここは慎重に区別したい。Appleの公開ガイドラインは、すべての適格な研究を報奨金の対象として評価すると説明する一方、提出数の上限そのものは公開ページで明示していない。上限と個別の報告経緯は現時点で報道ベースだ。ただしAppleは、AIで生成され、人間が適切に検証していない報告が重大な問題の迅速な解決を妨げると公式ガイドラインに明記している。理論だけで再現できないAI報告は対象外とし、繰り返した研究者の処理を180日止める場合もある。

つまりAIは、発見の供給量を増やすと同時に、受付側のノイズも増やした。今回の欠陥は「AIが見つけた本物」だったとしても、窓口から見れば、検証が終わるまで大量の候補の1件にすぎない。

Appleの「5.5」と研究者の「8.0」

脆弱性の評価にも、同じ情報の非対称が表れている。Bynarioによると、Appleが付けたCVSS 3.1の基本値は5.5だった。Appleの公開説明は、機微なユーザーデータへのアクセスとアクセス制限の改善に焦点を当てる。これは、保護ファイルを読み出す側だけを見れば理解できる表現だ。

Bynarioは、root所有ファイルの作成からコマンド実行まで実証したとして、保守的な基本値を8.0と評価した。次回ログインを契機とする経路ならユーザー操作あり、すでにログイン済みで画面が開いているなら追加操作なしとして8.8になる、という整理だ。

評価主体	CVSS 3.1	主に捉えている影響	前提の置き方
Apple	5.5	機微なデータへのアクセス	公開アドバイザリはroot実行まで説明しない
Bynario	8.0	機密性・完全性・可用性への高い影響	VNCパスワードが必要、次回ログインを契機にする保守的評価
Bynarioの別シナリオ	8.8	すでに開いているセッションでroot実行	被害者の追加操作を不要と評価

数字の違いは、どちらかが直ちに誤りという意味ではない。CVSSは「無作為に選んだMacが攻撃される確率」ではなく、前提条件を満たしたシステムでの技術的な深刻度を測る。旧式VNC設定を使っていないMacにはこの攻撃経路がない一方、使っている組織では、画面操作用のパスワードがroot権限へ拡大する。対象の広さと、対象になった場合の深さを分けて見る必要がある。

また、二次報道には8.6とする記事もあるが、Bynarioの公開したCVSSベクトルから示される値は8.0または8.8だ。本稿では、検証可能な一次資料の数値を採用した。AI時代の報告を論じる記事だからこそ、要約の孫引きで数字を増やさないことが重要になる。

脆弱性発見のボトルネックは、人間の検証へ移った

AIによる報告洪水は、Appleだけの問題ではない。curlの開発者Daniel Stenberg氏は2026年1月、2019年から続けてきたバグ報奨金制度を終了すると発表した。制度を通じて87件の脆弱性を確認し、報奨金は合計10万ドルを超えた。一方、以前は提出の15％超が実際の脆弱性として確認されていたのに、2025年には5％未満へ落ち込んだという。

curlのバグ報奨金制度	数値
運用開始	2019年
確認した脆弱性	87件
支払った報奨金	10万ドル超
過去の確認率	15％超
2025年の確認率	5％未満

確認率が3分の1以下になれば、同じ件数の本物を見つけるために読む報告は3倍以上になる。しかも、セキュリティ報告の誤りは単純な検索で落とせない。コードを読み、ビルドし、再現環境を用意し、攻撃条件を確かめ、既知の問題と重複していないかを調べる必要がある。もっともらしい技術用語で埋められた長文ほど、否定するための時間を奪う。

Stenberg氏は、絶え間ない低品質報告が精神的な負担になり、誤りを証明するためにも長い時間がかかると記した。curlは脆弱性の受付自体をやめたのではなく、金銭的な報奨を終了した。AIで候補生成の限界費用が下がると、善意の研究者だけでなく、外れた報告にも報奨金を期待する提出者が増える。受付側には、1件ずつ読む高い限界費用が残る。

この非対称は、生成AIサービスの問い合わせ対応と同じ構造を持つ。送信は自動化できるが、責任を伴う判断は自動化しきれない。AIでトリアージすれば処理量は増やせるとしても、「危険ではない」という誤判定は本物の脆弱性を埋め、「危険だ」という誤判定は人間の作業を増やす。最後の判断には、再現可能な証拠と、影響を説明できる人間が要る。

たくさん見つけることは、守ることではない

CVE-2026-43760が示したのは、AIがセキュリティ研究者を不要にする未来ではない。むしろ、候補の発見後にある仕事の価値が上がる未来だ。今回も、認証の前提を読み解き、通常経路との比較実験を設計し、root所有ファイルの作成が実害へつながることを示し、Appleと調整してパッチが出るまで公開を待つ工程が必要だった。

AIを使った脆弱性探索が信頼を得るための条件は、次の5つに集約できる。

1. 再現条件を限定する。影響を誇張せず、必要な設定、権限、ユーザー操作を明示する。
2. 正常系と比較する。同じ操作を別の認証経路で試し、差分がどこから生まれたかを示す。
3. 実害まで検証する。「理論上可能」で止めず、安全な環境で取得できる権限を確認する。
4. 機械が作った説明を人間が削る。短く、番号付きで、ベンダーが再現できる報告にする。
5. 協調開示を守る。修正前に攻撃手順を拡散せず、利用者が更新できる状態を先につくる。

AIが安くしたもの	まだ高いままのもの
コードの横断検索	認証・権限モデルの理解
仮説とテストケースの生成	実機での再現と反証
類似パターンの大量探索	重複判定と影響評価
報告文の下書き	ベンダーとの調整と責任

発見数だけを成果指標にすると、探索エンジンは大量の候補を吐く方向へ最適化される。だが、利用者を守るのはCVE候補の件数ではない。再現され、優先順位を付けられ、修正され、更新が届いた件数だ。AIによって脆弱性を見つける速度が上がったなら、次に投資すべきなのは、証拠の品質を上げる仕組みと、それを受け止める人間の時間である。

今回のmacOSの欠陥は、AIが人間より先に見つけた可能性のある高度なロジックバグであると同時に、AIが増やしたノイズに埋もれかけた本物でもあった。このねじれは過渡期の珍事ではない。発見が豊富になった世界では、検証こそが希少資源になる。

出典・参考

• Bynario「A root remote command execution on macOS with M5 in 2026?」
• Apple「About the security content of macOS Tahoe 26.6」
• Apple「About the security content of macOS Sonoma 14.8.8」
• Apple Security Bounty Guidelines
• Apple「Report a security or privacy vulnerability」
• TechRadar「A potentially dangerous macOS security flaw went unreported...」
• Daniel Stenberg「The end of the curl bug-bounty」