Appleのバグ報告数上限が裏目に、重大なmacOS脆弱性が修正前に公開

Appleが導入したバグ報告数の上限により、正当なセキュリティ研究者が重大な脆弱性を報告できず、修正前に情報が公開される事態が発生した。この問題は、AIを活用して多数のバグを発見する正当な研究者と、粗悪な自動生成レポートを大量に送信する者を、システムが区別できないことに起因する。Macユーザーには、使用しているOSに応じて、修正済みのmacOS Tahoe 26.6またはmacOS Sonoma 14.8.8へのアップデートが推奨される。

■導入

先月、イタリアのサイバーセキュリティスタートアップBynarioは、OpenAIの「GPT-5.5」を搭載した自社のAtlasプラットフォームを使い、50件を超えるセキュリティ上の問題をAppleに報告した。これは、攻撃者に悪用される前に実際に悪用可能な脆弱性を発見し、ベンダーへ報告するという、Appleのバグバウンティプログラムがまさに奨励している行為だった。しかし、Bynarioは短期間にあまりにも多くのレポートを提出したため、Appleが新たに設けた報告数の上限に達してしまった。

その後、同社が「CVE-2026-43760」を発見した時点では、通常の窓口から報告する手段がなかった。この脆弱性はmacOSの画面共有機能に存在し、VNC認証を受けた接続者が保護されたファイルを読み取り、root権限でコマンドを実行できるというものだった。Appleの報告数上限を扱った報道によると、BynarioのCEOであるAlfredo Pesoliは、30日間の待機期間が終わるのを待たず、情報を公開することを選んだ。同氏は、この脆弱性の闇市場での価値を10万〜20万ドル（約1,570万〜3,140万円、1ドル＝157円換算）と見積もっていた。

待たずに公開するという判断は、協調的脆弱性開示（Coordinated Vulnerability Disclosure）が本来防ごうとしている事態、つまりベンダーが対応する機会を得る前に、未修正の重大な脆弱性が公開されるという結果を招いた。Appleはその後Bynarioに連絡し、AppleのmacOS Tahoe 26.6向けセキュリティアドバイザリで確認できるように、同バージョンでCVE-2026-43760を修正した。しかし、この一件は、バグバウンティプログラムの報奨金表だけでは解決できない構造的な問題を浮き彫りにした。報告数の制限は大ざっぱな手段である。ハルシネーションに基づく脆弱性の主張を何百件も送りつける「AIスロップ」の生成者と、AIを使って数十件の実在する脆弱性を検証し、文書化する生産性の高い正当な研究者を区別できないからだ。Appleの上限は、その両方を一律に制限してしまう。

■重大な脆弱性はなぜAppleのパイプライン外で公開されたのか

CVE-2026-43760は、macOSの画面共有機能におけるVNCパスワード認証システム内のレガシーコードパスに存在していた。これは、完全なmacOSの認証情報ではなく、パスワードのみの認証を使用する古いVNCクライアントとの後方互換性を維持するためのコンポーネントである。BynarioによるCVE-2026-43760の解説とDigital TrendsのAppleセキュリティ報道によると、Bynarioの研究者がこの経路を調査したところ、認証済みのVNC接続者が、許可された範囲外にある保護対象のファイルを読み取れることを発見した。研究者らはさらに、この基本的な攻撃手法を、認証後にroot権限でコマンドを実行できる実用的なエクスプロイトへと発展させた。

この脆弱性が技術的に注目される理由は、Appleの保護機能を回避した点にある。高度な攻撃者によるエクスプロイトチェーンを阻止する目的で設計された、常時有効のハードウェアベースのメモリ安全性保護機能「Memory Integrity Enforcement（MIE）」は、この攻撃経路を保護対象としていなかった。Bynarioのブログは、このエクスプロイトが「メモリ破損を伴わず、MIEの脅威モデルの範囲外」で機能すると説明している。Appleのセキュリティアドバイザリによると、同社は画面共有サーバーコンポーネントの状態管理を改善することで、この問題に対処した。

この脆弱性が悪用されるには、画面共有またはリモートマネジメントが有効で、さらに従来方式のVNCパスワードアクセスが設定されている必要があった。これらの条件はすべてのMacに当てはまるわけではないが、小規模企業、リモートアクセス環境、古いVNCクライアントを使用している企業環境では一般的である。使用しているOSに対応するmacOS Tahoe 26.6またはmacOS Sonoma 14.8.8へアップデートしていないユーザーは、引き続き影響を受ける可能性がある。

■制限が開示の規範を壊すとき

HNGNが伝えたAppleの声明は短く、慎重に表現されていた。「業界全体でAIが生成したセキュリティ報告が増えていることを受け、研究者が同時にオープン状態にしておける新規レポートの数を最近調整した」。上限に達した研究者は、より多くの報告枠を申請できる。上限を超えた場合は、新たなレポートを提出できるようになるまで30日間待たなければならない。具体的な上限数は公表されていない。

Bynarioの事例は、信頼を前提とするシステムにレート制限を適用した場合に生じる、設計上の根本的なジレンマを示している。制限という仕組みは、異なる扱いが必要な2つのグループを区別できない。AIスロップの生成者と、AIの支援を受けた正当な研究者は、提出数だけを見れば同じように見える。どちらも大量のレポートを作成するからだ。違いは、スロップ生成者が技術用語で飾った未検証の主張を生み出す一方、AIの支援を受けた正当な研究者は、CVE-2026-43760のように、Appleのエンジニアが再現して修正できる実用的な概念実証（PoC）を添えて報告する点にある。

Sophosによるバグバウンティ分析によると、同社のセキュリティ研究者Rafe Pillingは、この構造的な変化を、バグバウンティプログラムが脆弱性を発見する仕組みから、脆弱性を「機械の速度で」検証する仕組みへ移行したと表現した。この見方は的確だが、単純な報告数の上限では解決できない問題を示しているにすぎない。上限は、ボトルネックの場所を移すだけである。正当な研究者がポータルから報告できなくなると、ボトルネックはAppleのトリアージキューから研究者側へ移り、協調的な開示に使える時間が不適切な形で失われ始める。

■Appleは内部でAIを利用する一方、外部のAI支援研究を信用していない

Appleの姿勢における最大の皮肉は、同社が公には取り上げていない構造的な非対称性にある。同社は外部からのAI支援による報告を制限する一方、自社コード内の脆弱性を探すため、AnthropicやOpenAIのAIツールを社内で利用している。Appleのバグバウンティ報告数上限に関する報道によると、Appleは、この社内AIプログラムが、最近のソフトウェアアップデートに通常の約5倍のセキュリティ修正を盛り込むことに貢献したと述べている。

TechTimesの報道によると、Appleは2026年4月にAnthropicの「Project Glasswing」に参加した。これは1億ドル（約157億円、1ドル＝157円換算）規模の取り組みで、Apple、Microsoft、Google、Amazon Web Services、Ciscoなどのテクノロジー企業で構成されるグループに対し、社内での脆弱性探索を目的として、Anthropicの未公開フロンティアモデル「Claude Mythos Preview」への早期アクセスを提供するものだ。開始から1カ月以内に、Glasswingの参加企業は、それぞれのソフトウェアから深刻度が「高」または「クリティカル」に分類される脆弱性を合計1万件以上特定したという。

Appleが設けた線引き、つまり自社が管理するAIパイプラインは信頼する一方、外部から寄せられたAI支援による報告は検証できるまで信頼しないという考え方は、原則としては正当化できる。Appleは自社の内部パイプラインには一貫した品質基準を適用できるが、Feedback Assistantポータルへ報告する何千人もの外部研究者に、事前に同じ基準を適用することはできない。しかし、その非対称性がもたらす現実的な結果は、Bynarioの事例に表れている。AI支援による研究を通じて、実際に機能し、修正可能な重大なエクスプロイトを生み出したスタートアップが、ハルシネーションに基づくレポートでAppleのトリアージキューを埋めるスロップ生成者と同じ扱いを受けた。上限の仕組みが判断材料として使っていたのが、報告の「量」だけだったためである。

■業界がすでに試みている対策

Appleの対応に前例がないわけではない。2026年には、少なくとも4つの主要なバグバウンティプラットフォームまたはプログラムが、同じ圧力を受けて制度を再構築したり、一時停止したり、対象範囲を縮小したりした。それぞれが、採用すべき対策について異なる結論を出している。

curlの作者でリードメンテナーでもあるDaniel Stenbergは、プログラムに提出された報告のうち、脆弱性として確認された割合が15％超から5％未満へ低下したことを受け、2026年1月末に金銭的な報奨を全面的に廃止した。これは、20件中19件を超える報告が無効だったことを意味する。Stenbergは、curlのバグバウンティ終了に関する投稿で、この状況を説明している。その後の結果は示唆に富むものだった。2026年4月までに、確認済み脆弱性の割合は15〜16％へ回復した。ほぼすべての報告がAIの支援を受けているように見えたが、その多くは提出前に検証されるようになった。金銭的な動機を取り除くことで、報奨金だけを狙った質の低い報告を減らしながら、意欲のある研究者には影響を与えずに済んだのである。

GitHubは異なる方法を選んだ。2026年7月27日に一般向けの報奨金額を少なくとも50％引き下げる一方、実績を持つ研究者を対象とした招待制のVIP層を新設した。その考え方は、参加初期の金銭的な動機を弱めて、根拠の乏しいスロップ報告を減らしつつ、VIP層に入る実績を示した本格的な研究者には高額の報奨を維持するというものだ。

Bugcrowdは、提出者の本人確認を必須としたほか、無効なレポートを10件以上連続して提出したアカウントを30日間停止し、報告の量産を行った者を永久追放する措置を導入した。HackerOneは、人間のアナリストへ届く前に、重複している可能性や無効である可能性が高い報告を検出するAIベースのトリアージシステム「Hai Triage」を開始した。

Appleが選んだ、待機期間と例外申請手続きを伴う報告数上限は、これらのアプローチの中で最も精度が低く、Bynarioの事例が示すように、正当な研究者を誤って制限する問題を最も引き起こしやすい。

■ターゲットフラグ：より優れた検証メカニズム

報告数上限と並行して、Appleは、仕組みの面でより合理的な品質管理手段である「ターゲットフラグ」を導入している。これは2025年10月に発表され、同年11月から運用されている。Capture The Flag（CTF）競技に着想を得たターゲットフラグは、AppleのOSに埋め込まれた検証用マーカーである。Appleによるターゲットフラグの発表で説明されているように、研究者のエクスプロイトがターゲットフラグを取得すると、レジスタの制御、任意の読み書き、コード実行など、定められたレベルのシステムアクセスに到達したことを、Appleが自動的に検証できる形で証明できる。Appleは、修正プログラムが公開されるまで数カ月待つのではなく、検証が完了した時点でターゲットフラグ付き報告の報奨を決定する。これは、従来、報奨の確定まで長期間待たされることがあった研究者にとって意味のある変化である。

ターゲットフラグと報告数上限の違いは、Appleがまだ公には十分に説明していない、一貫した考え方の存在を示唆している。ターゲットフラグは、報告数ではなく証拠の質に基づいて選別する仕組みだ。3週間で60件のレポートを提出し、すべてでターゲットフラグを取得した研究者は、悪用可能性を示す証拠のないレポートを3件提出した研究者よりも、正当かつ検証済みの研究であることを強く証明している。Appleの品質管理の目的が、検証済みの研究とスロップを分けることなら、ターゲットフラグは報告数よりも精密な手段である。ただし、2つの仕組みは併用できる。

■AI支援によるバグ発見は実際に悪用される脆弱性を増やすのか？

Appleによる制限の前提、つまりAIが生成したレポートは従来の研究とは質的に異なるリスクをもたらすという考えは、データと照らし合わせて検討する価値がある。VulnCheckの2026年上半期の悪用状況レポートによると、AI支援によって発見されたとされる1,061件の脆弱性のうち、実環境での悪用が確認されたのは14件で、割合は約1.3％だった。この割合は、同じ期間に確認された全脆弱性の悪用率とおおむね一致している。つまり、この指標に基づけば、AIによって発見された脆弱性が、従来の方法で発見されたものより危険だったり、短期間で攻撃に転用されたりする傾向は見られなかった。

同レポートを執筆したVulnCheckの研究者Patrick Garrityは、AnthropicのProject Glasswingが2万3,000件を超える問題を開示し、そのうち126件にCVEが発行され、実環境での悪用が確認されたものは1件だったと指摘している。この比率は、Appleや同業他社が直面する課題が、AIによって発見されたバグが本質的に危険だということではなく、AI支援による膨大な量の報告が、それを検証する人間主体のトリアージ体制を圧迫していることにあると示唆している。

これは、SophosのRoss McKercharとRyan Westmanが、2026年6月のバグバウンティを巡る状況の分析で指摘したパラドックスである。「一方では、AI支援による研究の台頭により、多くのプログラムに有用な情報の少ない『スロップ』が押し寄せている。他方では、フロンティアモデルが、検証可能で再現性があり、実際に悪用可能な脆弱性を機械の速度で生み出し始めている。どちらの傾向も加速しており、どちらも逆戻りすることはない」。BynarioのCVE-2026-43760も、その周囲にあるハルシネーションに基づくレポートも、同じ傾向から生まれたものだ。業界の課題は、両者を正確に分けるフィルターを構築することにある。

■Appleの上限がセキュリティ研究者とMacユーザーに意味すること

AIを使って作業を効率化し、発見内容を検証する独立系セキュリティ研究者にとって、Appleの上限は現実的な制約となる。Bynarioが3週間で50件のレポートを提出したことからも分かるように、効率的に脆弱性を発見する研究者は、発見の質とは無関係な上限に直面することになった。Appleが用意している例外申請手続きは、上限を超えるための選択肢にはなるが、上限の導入前には存在しなかった審査の段階を新たに加えることになる。

Macユーザーにとって当面の重要事項は、CVE-2026-43760が修正されたOSを利用しているか確認することだ。macOS Tahoeを使用している場合はmacOS Tahoe 26.6、macOS Sonomaを使用している場合は、修正がバックポートされたmacOS Sonoma 14.8.8へ更新する必要がある。画面共有が不要なら、「システム設定」→「一般」→「共有」で無効にすれば、この攻撃経路自体を排除できる。画面共有が必要な場合は、従来方式のVNCパスワードオプションを無効にし、リモートアクセスにはmacOSユーザーアカウントによる認証のみを使用することで、この脆弱性が存在した特定のコードパスを無効化できる。

長期的な問題は、Bynarioの事例を受け、現在の報告数上限をAppleが調整するかどうかである。AppleはFinancial Timesの報道後にBynarioへ直接連絡しており、今回の意図しない結果を認識したことがうかがえる。その連絡が、報告数の多い正当な研究者に対する上限の運用方法を構造的に変えることにつながるかは、現時点では分からない。

■注目ポイントQ&A

●Appleのバグバウンティ報告数上限とは何ですか？また、どのように機能しますか？

Appleは2026年6月、研究者がセキュリティポータル「Feedback Assistant」を通じて、同時にオープン状態にしておけるセキュリティバグ報告の数に上限を設けました。上限に達した研究者は、新たな報告を提出できるようになるまで30日間待つ必要があります。Appleは具体的な上限数を公表していません。より多くの報告枠が必要な研究者は、Appleへ直接例外を申請できます。この上限は、Appleのセキュリティ審査チームを圧迫していたAI生成の脆弱性レポートの急増に対応するため導入されました。

●CVE-2026-43760とは何ですか？すでに修正されていますか？

CVE-2026-43760は、macOSの画面共有機能における従来方式のVNCパスワード認証経路に存在する脆弱性です。画面共有またはリモートマネジメントが有効で、従来方式のVNCパスワードアクセスが設定されている場合、認証済みのVNC接続者が、許可された範囲外にある保護対象のファイルを読み取ることができました。Bynarioの研究者はこれを、root権限でコマンドを実行できる実用的なエクスプロイトへ発展させました。AppleはmacOS Tahoe 26.6とmacOS Sonoma 14.8.8でこの脆弱性を修正しています。該当するOSを使用していて、まだ修正版へ更新していないユーザーは、速やかにアップデートする必要があります。画面共有が不要なら、無効にすることでこの攻撃経路を排除できます。

●Appleは外部のバグ報告を制限する代わりに、内部のAIを使ってトリアージできないのですか？

Appleは、自社コード内の脆弱性を探すため社内でAIツールを利用しており、そのプログラムは、最近のアップデートに通常の約5倍のセキュリティ修正を盛り込むことに貢献したと報じられています。しかし、同じ仕組みを外部からの報告に適用することは、技術的により複雑です。社内のAIは管理された条件下でApple自身のソースコードを解析しますが、外部のバグ報告は、技能レベルの異なる研究者から非構造化された自然言語で届きます。さらに、そこで説明されている脆弱性をAppleのエンジニアが独自に再現できなければなりません。脆弱性を説明するだけでなく、実際に悪用可能であることの実証を研究者に求める「ターゲットフラグ」は、報告数だけを制限するよりも精密なアプローチです。

●セキュリティ研究者がAI支援による脆弱性研究をAppleに報告する際、何を知っておくべきですか？

Appleは、AI支援によるセキュリティ研究を歓迎し、社内でもAIを利用していると明らかにしています。報告数の上限は、同時にオープン状態にしておけるレポートに適用されるもので、研究活動そのものを制限するものではありません。Appleの「ターゲットフラグ」を使用し、デバイスのシステム内で実際にどの段階まで攻撃できたかを実証した研究者は、修正プログラムの公開を待つことなく、検証後に報奨の決定を受けられます。ターゲットフラグは、単純な報告数よりも、AIで検証された正当な発見と、AIのハルシネーションに基づくレポートを区別しやすい仕組みです。報告数の上限を超える必要がある研究者は、Appleへ直接、より多くの報告枠を申請できます。

元記事: Apple AI Bug Cap Blocked Critical macOS Screen Sharing Flaw Before Submission