Zoomの「Zoomsday」脆弱性、会議参加者を危険にさらす

研究者らが24時間以内に20件未満のAIプロンプトで実用的な乗っ取りエクスプロイトを構築したと報じられた後、Zoomはクロスプラットフォームの脆弱性にパッチを適用した。

Zoomsday脆弱性では、会議参加者がクリックやダウンロードを必要とせずに別の参加者を標的にできた。この攻撃はZoomの注釈パーサーに到達し、メモリを破損させ、リモートコード実行への経路を作り出した。

Zoomsday reportは、特に不穏な詳細を浮き彫りにした。一般公開されている最先端AIモデルが、A Securityによるリバースエンジニアリングから実用的なエクスプロイトの完成までを、わずか1日で支援したという。

このスピードこそが本件の核心だ。Zoomは公表前に報告されたバグを修正したが、この研究は攻撃用の開発に数カ月にわたる専門的な作業がもはや必要ではないことを示唆している。

A Securityには、その結論を強調する商業上の理由がある。同社の研究速度とAI支援に関する主張は、完全な独立再現による検証をまだ受けていない。Zoomのセキュリティ情報は、脆弱性、影響を受ける製品、研究者、そしてリモートコード実行という影響を確認している。

この結果、セキュリティチームは二つの問題に直面する。Zoomの脆弱性にパッチを適用すると同時に、エクスプロイト開発は遅く高価であるという前提に基づいた防御を見直さなければならない。

Zoomsdayの開示後にZoomが修正した内容

Zoomは、会議トラフィックを通じて別の参加者が、対応クライアントプラットフォーム全体でリモートコード実行の危険にさらされ得ることを確認した。

主な脆弱性であるCVE-2026-53413は、Zoomの注釈機能における境界チェックの欠落に起因していた。注釈機能とは、通話参加者が共有コンテンツ上に描画、入力、図形の配置を行える機能だ。

Zoomのバッファオーバーライトに関する情報によると、会議参加者はこの脆弱性を悪用し、別の参加者のデバイス上でリモートからコードを実行できる可能性があった。ZoomはCVSSスコアを8.3とし、重大度を「高」に分類した。

A Securityは実際の影響をゼロクリックのリモートコード実行と説明した。ゼロクリックとは、標的となる人物がファイルを開いたり、プロンプトを承認したり、リンクをたどったりする必要がないことを意味する。

攻撃者には同じ会議へのアクセスが依然として必要だった。ただし、会議を主催すること、被害者のアカウントを掌握すること、または被害者に注釈機能を使わせることは必要なかった。

この条件により、通常の会議参加そのものが配信経路となった。侵害されたプレゼンターは個々の閲覧者を標的にでき、悪意のある閲覧者も同じ脆弱なパース経路をプレゼンターへ向けることができた。

影響を受けるコードは、Windows、macOS、iOS、Android向けのネイティブZoomクライアントに存在した。A Securityは、より広い影響対象製品群を説明する際にLinuxも挙げている。

問題はZoom独自の注釈プロトコル内にあった。クライアントはZoomの会議インフラを通じて送信されたメッセージから構造化された描画オブジェクトを再構築する。

A Securityによれば、攻撃者はテキスト注釈オブジェクト内に過大な文字数を設定できた。受信側のパーサーはその後、宛先サイズを確認せずに、その数の2倍を固定長128バイトのバッファへコピーしたという。

この処理により、確保済みバッファの範囲外へ書き込み、近接するメモリを破損させる可能性があった。脆弱なシステムでは、慎重に制御された破損によってアプリケーションを単にクラッシュさせるのではなく、プログラム実行をリダイレクトできる。

研究者らはまた、別個の注釈バッファ過剰読み取りであるCVE-2026-53414も報告した。バッファ過剰読み取りは、ソフトウェアが意図された境界を越えたデータにアクセスする際に発生する。

Zoomの過剰読み取りに関するアドバイザリーは、この問題に6.5のスコアを付け、公式の影響をサービス拒否としている。A Securityは、漏えいしたメモリがアドレス空間配置のランダム化の回避にも役立つ可能性があると主張している。

アドレス空間配置のランダム化、すなわちASLRは、コードとデータを予測不能な位置へ移動させる。攻撃者は、この防御を回避して確実に実行を誘導する前に、情報漏えいを必要とすることが多い。

三つ目の問題であるCVE-2026-53415は、同じ注釈コンポーネントにおけるuse-after-free動作に関するものだった。use-after-freeとは、プログラムがメモリを解放した後もそれを使い続けることを指す。

Zoomはこの脆弱性について、自社のOffensive Securityチームにクレジットを与えた。同社によれば、会議参加者がネットワーク経由でこれを悪用し、リモートコード実行に至る可能性があった。

パッチの対象は標準的なデスクトップクライアントにとどまらない。影響を受ける製品には、Zoom Workplace、Windows向けZoom Workplace VDI Client、Zoom Rooms、Zoom Meeting SDKが含まれた。

Zoom Workplaceの利用者は、それぞれのブランチでバージョン7.1.5または7.0.6が必要となる。VDIクライアントは、保守対象ブランチに応じて7.0.11または6.6.16が必要だ。

CVE-2026-53415では、7.1.5より前のバージョンがZoom RoomsとMeeting SDKに影響した。Zoomの以前のセキュリティ情報では、最初の二つの脆弱性に対する修正版のしきい値としてバージョン7.1.0が記載されている。

これらの違いは管理された環境で重要となる。メインのデスクトップクライアントだけを確認しても、会議室、仮想デスクトップ、組み込みSDKの展開環境が危険にさらされたままになる可能性がある。

開示の時系列からも、公開レポートは修正に先行していなかったことが分かる。A Securityによれば、同社は2026年6月8日に最初の脆弱性を発見し、その翌日にリモート実行を確認した。

研究者らは6月10日にZoomへ報告した。Zoomは6月11日に報告を受領し、6月22日に最初のクライアント側修正を提供した。

サーバー側の緩和策は7月15日に続いた。Zoomは協調開示が行われる8月11日より前の7月20日、CVE-2026-53415に対する後続のクライアント修正を提供した。

したがって、tom hardwareの報道が扱ったのは、パッチなしで流通している未修正のゼロデイではなく、修正済みの脆弱性だった。現在の緊急のリスクは、修正済みバージョンを下回るクライアントに関するものだ。

なぜ注釈メッセージが乗っ取りにつながり得たのか

この攻撃は、共同描画フォーマットを会議トラフィックから実行可能な制御へ至る経路へと変えた。

Zoomはすべての注釈を完成した画像として送信するわけではない。クライアントは描画要素を構造化オブジェクトにシリアライズして送信し、受信デバイス上でそれらのオブジェクトを再構築する。

フリーハンドの線、テキストボックス、矢印、図形には、それぞれ独自のデータ構造がある。各オブジェクトには種類、ジオメトリ、フラグ、テキスト書式などのプロパティが含まれる。

この設計により、変更のたびに完全な画像を送信する必要が減る。一方で、各受信クライアントは別の会議参加者が選択した多数の値をパースしなければならない。

ZoomのAI支援エクスプロイトは、この信頼境界から始まった。A Securityは、すべての危険な関数を同等に調査するのではなく、リモート参加者が到達可能なデータを処理するコードに焦点を当てた。

研究者らはZoomのAndroidクライアント、バージョン7.0.4から調査を始めた。そのパッケージには、アプリケーションのJavaコンポーネントに加え、121個のネイティブ共有ライブラリが含まれていたと報じられている。

AI支援のランキング処理では、70のライブラリにまたがる3,762個の関数が特定された。メモリコピーや計算されたサイズでのメモリ割り当てといった処理を含むコードパスが優先された。

この最初の手法では、誤解を招く優先順位が生じた。上位にランクされた複数の関数は、別の人物が制御できるデータではなく、ローカルのカメラやレンダリング処理を扱っていた。

そこでチームは問いを反転させた。危険な処理がどこにあるかを問う代わりに、別の参加者が実際の会議トラフィックを通じて到達できる処理はどれかを問うた。

実際の通話中の動的トレーシングにより、Zoomの注釈ライブラリであるlibannotate.soが特定された。このライブラリは、先行する静的解析では45位にとどまっていたという。

この反転は重要だ。脆弱性研究は到達可能性に依存するためである。攻撃者が入力を与えられず、リモートから起動もできないなら、危険そうに見える関数の攻撃上の価値はほとんどない。

注釈は両方の条件を満たしていた。他の参加者からの複雑なメッセージを処理し、標的ユーザーが描画していない時でも、この機能のパーサーはアクティブなままだった。

このプロトコルは、個数プレフィックスおよび長さプレフィックス付きのフィールドを使用していた。つまり、送信者が受信者に対し、処理すべき要素数やバイト数を示す数値を提供する。

あるテキスト書式構造には、それぞれ128バイトの固定バッファが四つ含まれていた。パーサーはネットワークから32ビットの文字数を受け取り、1文字あたり2バイトをコピーした。

脆弱な関数は、数がゼロでないことを確認していた。A Securityによれば、その数を128バイトの宛先と比較していなかったという。

そのため、悪意のあるパケットは64文字を超えるUTF-16文字数を宣言できた。パーサーはバッファを越え、隣接するスタックまたはヒープメモリへコピーを続けることになる。

研究者らは、745バイトの注釈メッセージで脆弱な経路に到達したと報告している。Zoomの通常の暗号化トランスポートがパケットを配信し、被害者の未改変クライアントが危険なパースを実行した。

macOSでは、A Securityは関連する注釈コンポーネントにスタックカナリアとポインタ認証がないことを確認した。どちらの保護機構も、メモリ破損をコード実行へ転換する難度を上げることができる。

チームによれば、オーバーフローによってプログラムカウンタと複数のレジスタを制御できたという。その後、既存の命令列を利用し、ZoomプロセスからSafariを起動した。

ブラウザの起動は目に見えるデモンストレーションであり、報告された攻撃の限界ではない。Zoom内で実行されるコードは、アプリケーションおよびログイン中のユーザーに関連付けられたアクセス権を継承し得る。

このアクセスは、会議ソフトウェアでは特に機微なものになり得る。利用者は一般に、カメラ、マイク、画面録画、連絡先、ローカルファイルへの権限を付与している。

Androidでは別の手法が必要だった。研究者らは、同程度のサイズのヒープオブジェクトを配置し、隣接するオブジェクトへオーバーフローさせ、その仮想関数ポインタを部分的に変更する方法を説明している。

ヒープシェーピングと呼ばれるこの技法は、制御された破損を可能にする程度までメモリレイアウトを予測可能にしようとするものだ。その後のオブジェクト操作で、変更されたポインタをトリガーできる可能性がある。

これらの詳細は、A Security自身の技術的開示によるものだ。Zoomのアドバイザリーはバグを確認しているが、完全な悪用チェーンについてはより少ない情報しか提供していない。

この区別は重要だ。ZoomはCVSSベクターにおいてユーザー操作が必要と公式に説明している一方、A Securityは実際の攻撃を被害者にとってゼロクリックと位置付けている。

この違いは、必ずしも事実関係の矛盾を示すものではない。悪意のある攻撃者の会議に参加する行為は、悪用にそれ以上の操作を必要としない場合でも、スコアリング規則上は操作と見なされる可能性がある。

Zoomsday脆弱性は、クローズドソフトウェアに関するよくある前提にも疑問を投げかける。独自プロトコルは防御側からソースコードへのアクセスを奪うが、決意した研究者による挙動の再構築を妨げるわけではない。

AIは、ランキングの提案、フィールドのマッピング、悪用手順の提案によって、その再構築を加速させた。最初の自動ランキングが誤った攻撃面を追った際には、人間の判断が調査を正しい方向へ導き直した。

本当の圧力はAI支援によるエクスプロイト開発の速さから来る

報告された20プロンプトのワークフローは専門家の作業を圧縮するが、誰でも初心者が攻撃を再現できることを示すものではない。

A Securityによれば、1人の研究者が20件未満のプロンプトと24時間未満で、調査から機能するエクスプロイトへ移行した。使用されたモデルは、制限された政府システムではなく一般公開されているものだった。

その主張は、この物語により広い意味を与える。エクスプロイト開発の希少性は従来、希少な専門知識、高い人件費、限られた標的知識、そして長期にわたるテストに依存してきた。

AIは、こうした制約の一部を軽減できる。逆コンパイルされた関数を要約し、攻撃対象領域の優先順位を提案し、メッセージ形式を再構築し、焦点を絞った監査手順を生成できる。

研究者には依然として、IDA、動的インストルメンテーション、リバースエンジニアリングの知識、実機でのテストが必要だった。IDAは、元のソースコードなしにコンパイル済みソフトウェアを調査するための逆アセンブラである。

このワークフローでは、実行中のプログラムを観察または変更する動的インストルメンテーション・ツールキット、Fridaも用いられた。モデルがテキストを生成できるだけで、どちらのツールも有用になるわけではない。

公開されたプロンプトには、幅広い領域知識が反映されている。JNIエントリーポイントのマッピング、危険なシンクのスコアリング、プロトコルのオペコード復元、メモリ安全性の分析を求めている。

初心者では、回答を評価したり、構造的に欠陥のある順位付けに気付いたりするのは難しい。この事例では、最初の自動化された作業キューは、リモート参加者が到達できないコードに集中していた。

人間の研究者はその失敗を認識し、問題の定義を変更した。次の段階ではネットワークから到達可能な会議機能を追跡し、有用な標的として注釈機能を発見した。

このやり取りは、「AIがバグを発見した」という表現だけでは不十分な理由を示している。モデルは分析を支援したが、ツールの選定、問いの設定、行き止まりの排除、結果の検証は研究者が担った。

それでも、支援の高速化は高度な研究の経済性を変える。熟練した実務者は、より多くの仮説を検証し、より多くのコードをカバーし、クラッシュをより早くエクスプロイトへ転換できる。

学術研究もすでにこの方向性を示している。LLM exploit agentsに関する2024年の研究では、説明が与えられた場合、GPT-4が既知の多くのワンデイ脆弱性を悪用できることが示された。

ワンデイ脆弱性は、すでに公開情報が存在する点でゼロデイとは異なる。Zoomsdayは公開されたプロトコル仕様のないクローズドなソフトウェアを標的としており、報告された成果はより難度が高い。

この研究は、未知の脆弱性に対する普遍的な成功率を示すものではない。A Securityが公表したのは成功事例であり、多数の失敗した標的を含む統制されたベンチマークではない。

これは選択バイアスを生む。セキュリティ企業は当然ながら最も強力な発見を公表し、失敗した実験は注目を集めにくい。

「20未満のプロンプト」という表現にも、標準的な測定方法はない。1つのプロンプトで大規模かつ多段階の分析を要求でき、ツールが生成した広範なコンテキストに依存することもある。

プロンプト数は、モデルのトークン数、ツール呼び出し、研究者の準備、計算資源の利用、事前の専門知識を測定しない。直接的な労働指標として扱うべきではない。

Tom's Hardwareの枠組みは驚異的な速度を捉えているが、読者は検証済みの製品への影響と、研究者によるより広範な経済的結論を分けて考えるべきだ。

Zoomのセキュリティ情報は、影響を受けたコンポーネント、リモート攻撃経路、製品範囲、コード実行リスクを独自に裏付けている。ただし、完全な20プロンプトのワークフローまでは独自に認証していない。

A Securityの詳細なプロンプト抜粋により、この主張は検証しやすくなっている。しかし、同じ条件下で研究プロセス全体を独立チームが公に再現したわけではない。

この懐疑的な読み方は、結果の重要性を否定するものではない。証拠が裏付ける内容と、企業の主張にとどまる内容を明確にするものだ。

裏付けられる結論は、AIが迅速かつ成功した脆弱性調査において経験豊富な研究者を支援したということだ。裏付けのない飛躍は、今や誰もが支援なしに同じエクスプロイトを作成できるという考えである。

防御側は、すべての犯罪者が突然国家レベルの技量を得たと仮定することなく、能力ある攻撃者の高速化を想定して計画すべきだ。専門知識が不要になる前に、有資格の実務者の数は増え得る。

この変化は、まずソフトウェアベンダーに圧力をかける。パッチ適用、内部テスト、開示プロセスは、短縮されたエクスプロイト開発の時間軸に対抗して機能しなければならない。

企業のセキュリティチームにも圧力がかかる。高度な武器化が数日、あるいは数時間で起こり得る状況では、月次のパッチサイクルを正当化することはより難しくなる。

最後に、AIプロバイダーにも圧力がかかる。正当な脆弱性研究を改善するモデルは、攻撃的な開発コストを下げる知識も移転し得る。

制限だけでリスクは解消されない。同じ能力は、ベンダーが欠陥を発見し、テストを生成し、クラッシュを分析し、リリース前の修正を優先する助けにもなる。

結果として生じる競争は、人間対AIではない。AI支援を受けた防御側が、同じ拡大し続けるソフトウェア領域で、AI支援を受けた研究者や攻撃者と競争する構図である。

暗号化はプライバシーを保護したが、Zoomの緩和策を複雑にした

エンドツーエンド暗号化により、Zoomは悪意ある注釈トラフィックを検査できなかった一方で、会議内の攻撃者は有効な暗号鍵を保持していた。

Zoomは、クライアント側のパッチとサーバー側のフィルターの両方で対応した。このフィルターは、危険な注釈メッセージが脆弱なクライアントに届く前に検出して阻止できた。

この緩和策は、Zoomのデフォルトの強化された暗号化を使用する会議を対象としていた。こうしたセッションでは、Zoomのインフラが十分なメッセージ内容を検査でき、フィルタリング規則を適用できた。

エンドツーエンド暗号化された会議ではトレードオフが生じた。E2EEはZoomのサーバーによる保護された会議内容の閲覧を防ぐため、サーバーが悪意ある注釈オブジェクトを識別する能力も制限される。

すでに会議に参加している攻撃者は、有効な暗号化トラフィックの送信に必要な鍵を保有していた。したがって暗号化は、パケットが脆弱なパーサーに届くまでの間、そのパケットを保護した。

これは、E2EEが本来の目的を果たせなかったことを意味しない。サービスプロバイダーを含め、暗号化セッション外の当事者に対する機密性を保護した。

単に、認可された参加者が暗号化チャネル内に配置した内容を検証しなかっただけである。機密性とメモリ安全性は別の問題を解決する。

A Securityによると、サーバー側の緩和策後も、古い脆弱なクライアントはE2EE会議でリスクにさらされ続けた。恒久的な修正には、安全なパース動作を備えたクライアント版のインストールが必要だった。

この違いは、組織がZoomの7月15日のサーバー側緩和策をエンドポイント更新の代替として扱えない理由を説明している。この緩和策は、パッチが普及するまでの間に露出を減らした。

管理者は、VDIクライアント、Roomsシステム、Meeting SDKを組み込む製品を含め、影響を受けるすべての導入環境を棚卸しすべきだ。個人端末や外部ゲストは、この作業を複雑にする可能性がある。

Zoomでは、管理者が最小クライアントバージョンを強制できる。この制御により、更新されていない内部ユーザーやゲストが保護された会議に参加するのを防止できる。

運用上の課題は、緊急の強制適用と会議の可用性のバランスを取ることにある。サポート対象外のデバイスは、顧客との通話、面接、医療相談、緊急時の調整を妨げる可能性がある。

セキュリティチームは、明確な期限と修正版を通知すべきだ。その後は、自発的な再起動に無期限に依存せず、古いクライアントをブロックすべきである。

管理対象デバイスには、エンドポイント管理システムを通じて更新を配布できる。ダウンロード済みのパッケージが更新済みのプロセスを保証するわけではないため、インストール後に実行中のバージョンを確認すべきだ。

パッチ適用を完了するまでの間、会議コントロールは追加の層を提供する。待機室、パスコード、認証済みユーザーの要件、制限された会議リンクにより、脆弱な攻撃対象領域に到達できる人物を減らせる。

これらの制御はパーサーを修正できない。それでも、未知の参加者が悪用に必要な会議内の位置を得るのを防げる。

任意機能を制限することも攻撃対象領域を減らす。注釈、ホワイトボード、ファイル転送、リモート制御を必要としない組織は、アカウントレベルでそれらを無効化できる。

機密性の高い通話では、ブラウザクライアントが一時的な選択肢になる可能性もある。A Securityは、ブラウザサンドボックス内で動作する同クライアントには、ネイティブの注釈機能とホワイトボード機能がないと指摘している。

ブラウザ参加には、機能面と使いやすさのトレードオフがある。音声、映像、アイデンティティ、アクセシビリティの要件をテストせずに、普遍的な推奨事項とすべきではない。

パッチ適用後もエンドポイント検知は重要である。会議アプリケーションが予期せずシェル、ブラウザ、スクリプトインタープリターを起動した場合は、アラートを発すべきだ。

集中型のクラッシュ報告は、失敗した悪用の試みも明らかにできる。メモリ破壊攻撃では、攻撃者が信頼性の高い実行を達成する前に、標的アプリケーションを繰り返しクラッシュさせることが多い。

組織は、原因不明のクラッシュの前後におけるZoomプロセスの活動を確認すべきだ。また、すべてのクラッシュが通常の不安定性を反映していると決めつけず、関連するエンドポイントテレメトリーを保存すべきである。

引用された情報源のいずれも、実環境での広範な悪用を確認していない。この不在は、数億台のデバイスが実際に侵害されたという主張を防ぐべきだ。

Zoomは大規模組織と個人ユーザーに利用されているため、潜在的な到達範囲は広かった。潜在的な露出、確認済みの悪用、成功した侵害は、3つの異なる測定値である。

A Securityは、Fortune 100の70％がZoomを利用しているとしている。この統計は研究者によるもので、組織での導入状況を示すものであり、脆弱なクライアント数を示すものではない。

Zoomも研究者も、開示時点で影響を受けるバージョンを実行していたデバイス数の検証済みの数字を公表していない。数億人を扱う見出しは、理論上の到達範囲を表している。

ZoomのAIエクスプロイトは、被害者数を水増ししなくても深刻だった。主要なオペレーティングシステムにまたがる、同一会議内からのコード実行経路は、それだけで十分な緊急性を生む。

Tom's Hardwareの報道後にセキュリティチームが注視すべきこと

パッチの導入状況、エクスプロイトの再現、AI支援研究の変化が、Zoomsdayが封じ込められた事例になるか、長く残るセキュリティ上の指標になるかを決める。

最初のシグナルは、修正版クライアントの導入状況である。企業は、Zoomが世界全体の割合を公表するのを待つのではなく、自社の導入データを測定すべきだ。

7.1.5および7.0.6より前のバージョンを使用するクライアント数が減少すれば、当面のリスクは低下する。古いクライアントが残り続ければ、現実的な露出は継続する。

VDIブランチはバージョン番号が異なるため、別途報告すべきだ。Zoom RoomsとMeeting SDKの導入環境も、個別の資産クラスとして扱うべきである。

2つ目のシグナルは、独立したエクスプロイト分析である。A Securityは非公開でコード実行を実証し、広範な技術的詳細を公開したが、公的な再現があれば脅威評価はより明確になる。

信頼できる第三者の概念実証があれば、どのオペレーティングシステムと構成が依然として最も悪用しやすいかを確認できる。また、未修正デバイスに対する犯罪者の適応も加速させるだろう。

逆に、独立した試行が成功しなければ、省略された前提条件や信頼性の限界が明らかになる可能性がある。それは修正をインストールする必要性を変えることなく、実際的な脅威を狭める。

セキュリティベンダーは、公開された詳細を検知ルールに反映する可能性が高い。有用な指標には、不正な形式の注釈トラフィック、異常なZoomの子プロセス、識別可能なクラッシュシグネチャが含まれ得る。

こうした検知では、E2EEによる可視性の制限を考慮しなければならない。ネットワークツールは、Zoomのサーバーや企業ゲートウェイが復号できないコンテンツを検査できない。

そのため、E2EE通話ではエンドポイントテレメトリーがより重要になる。防御側は、Zoomが何を起動するか、どのリソースにアクセスするか、どの程度の頻度でクラッシュするかを監視すべきだ。

3つ目のシグナルは、AI支援による攻撃的研究が、他のクローズドなエンタープライズアプリケーションでも同等の結果を生むかどうかである。単一の成功事例だけでは、傾向を定義できない。

強力な証拠には、再現可能な発見、開示された手法、独立した検証、従来の研究ワークフローとの明確な比較が含まれる。

弱い証拠とは、技術的な記録を伴わない、劇的なプロンプト数の提示にすぎない。セキュリティ購入者は、研究者が時間、人間による入力、ツール利用、失敗した試行をどのように測定したのかを確認すべきだ。

モデル提供企業も次の段階を左右する。より高性能なサイバー向けモデルは、防御側によるコード監査、報告のトリアージ、パッチ作成の迅速化に役立つ可能性がある。

同じモデルは、パッチによって脆弱性の所在が明らかになった後のエクスプロイト開発も短縮し得る。この二面性により、慎重なアクセス制御と監視が重要になる。

ベンダーは、公開したパッチが敵対的分析のための地図になると想定すべきだ。したがって、情報開示後に展開を遅らせることは、ますます大きなリスクを伴う。

また、公開研究者に先んじてプロトコルパーサーをテストすべきだ。予期しない入力を送信してクラッシュを見つけるファジングは、特にカウントベースのバイナリ形式に関連性が高い。

メモリ安全な言語は一部のバグ分類を減らせるが、ネイティブコンポーネントの置き換えには時間がかかる。既存のCおよびC++パーサーには、境界チェック、堅牢化、継続的な敵対的テストが必要だ。

Zoomの対応は、前向きな兆候を一つ示している。A Securityによると、同社は1日以内に報告を受理し、12日後に最初のクライアント修正を提供した。

Zoomはまた、公開開示前にサーバー側の緩和策を追加し、CVEの割り当てと連携して公開を進めた。この対応により、技術的開示から公開された悪用ガイダンスまでの期間は限定された。

ただし、ベンダーの迅速な対応だけでは、すべての顧客デバイスを更新できない。資産の可視性と強制されたクライアント基準は、依然として顧客の責任である。

ナレッジワーカーは、雇用主が主力のノートPCを管理している場合でも、個人用デバイスを更新すべきだ。スマートフォンや自宅のコンピューターから参加した会議でも、参加者が制御するトラフィックを処理する。

主催者は、再利用可能な会議リンクを公に配布することを避けるべきだ。会議の内容や参加者が機密性の高い場合は、待機室と認証済みアクセスを利用すべきである。

ZoomのMeeting SDKを組み込む開発者は、出荷済みバージョンを確認しなければならない。個人用のZoomアプリケーションを更新しても、別製品にバンドルされた独立したSDKは変更されない。

セキュリティリーダーも、インシデントに関する前提を見直すべきだ。ファイルを共有せず、リンクをクリックしなくても、ビデオ通話は攻撃対象領域になり得る。

この教訓はZoomを超えて広がる。コラボレーションクライアントは、他のユーザーから送られるチャット内容、メディアストリーム、共有文書、リアクション、描画、リモートコントロールメッセージを解析する。

各機能がプロトコルの攻撃対象領域を生み出す。最も安全な会議ポリシーでも安全でない解析を補うことはできないが、到達可能な機能が少なければ、攻撃者の選択肢も減る。

Zoomsday脆弱性後の中心的な問いは、AIがエクスプロイト研究者を独力で置き換えたかどうかではない。証拠はその主張を裏付けていない。

問うべきは、経験豊富な研究者が今や通常の企業パッチ適用を上回るペースで作業できるのか、ということだ。この事例は、その答えを「はい」とする信頼できる根拠を示している。

組織は今すぐ、すべてのZoomクライアントと組み込みコンポーネントを確認し、完全展開にかかる時間を測定すべきだ。その間隔こそが、実際の露出期間である。

次のtom hardwareの見出しは、もう一人のAI支援研究者が類似の経路を見つける前に、防御側がその期間を短縮できれば、重要性を失うだろう。