ゼロデイ脆弱性とは、ソフトウェアの開発元がまだ把握していない、または修正パッチを出せていない段階の脆弱性のことです。開発元が対策に使えた日数が「0日」であることからこう呼ばれ、この脆弱性を突く攻撃を「ゼロデイ攻撃」と呼びます。
ゼロデイ脆弱性とは何が特別なのか
通常の脆弱性は、発見、開発元への報告、修正パッチの公開、利用者による適用という順で処理されます。ゼロデイ脆弱性では、修正が出る前に脆弱性の存在や攻撃の手口が表に出ています。そのため利用者は「アップデートを当てる」という基本の防御策をまだ使えません。
修正パッチが公開されると、その脆弱性は厳密にはゼロデイではなくなります。ただしパッチを当てていない端末は、その後も攻撃の対象として残ります。
「使い方」「料金」を調べている方へ
ゼロデイ脆弱性は製品やサービスではないため、導入手順も料金表もありません。「誰が作っているか」「競合はどこか」という問いもそのままでは当てはまりません。関係者は、脆弱性を見つけるセキュリティ研究者と、修正する開発元です。
エンジニアや企画・DX担当者が実務で考えるべきなのは「どう備えるか」です。対策の費用は、使っている製品や社内の体制によって大きく変わります。このため当記事では相場を示しません。攻撃に悪用する具体的な手順も扱いません。
最近の事例：AIエージェントとセキュリティ製品
当サイトで報じた例を2つ紹介します。
1つ目はMetaのAIエージェント「Muse」です。macOSのセキュリティ専門家Patrick Wardle氏が、深刻なゼロデイ脆弱性を発見しました。Museには文書化されていない設定があり、それを任意のアプリから変更できました。その中には、音声の文字起こしを送る先のエンドポイントを差し替える設定も含まれていました。その結果、ローカルで動くアプリやターミナルのコマンドからエージェントを完全に掌握できる状態でした。攻撃者のサーバーへユーザーの音声入力データやアクセストークンを送らせることもできる恐れがありました。Metaは急きょ修正パッチを配布しています。
2つ目はMicrosoft Defenderです。Windowsのゼロデイを相次いで公開している研究者NightmareEclipseが、概念実証コード「BigDiskBuster」を公開しました。Defenderは動作を続けますが、更新が始まるとディスクの空きを一時ファイルで埋めて更新を失敗させます。その結果、定義ファイルは古いまま固定されます。守る側のソフトそのものが標的になった例です。
企業・エンジニアが取るべき対策
上の2つの事例から、次の対策が導けます。
修正パッチはすぐ適用できるようにしておきます。Museのように、修正が予告なく急きょ配布されることがあります。
更新が実際に成功したかを確かめます。Defenderの例では、ソフトが「動いている」ことと「最新である」ことは別の問題でした。
AIエージェントに渡す権限とトークンは必要最小限にします。Museの例では、エージェント経由でアクセストークンが流出する恐れがありました。
端末で動くアプリを管理します。Museの攻撃の入口は、同じ端末で動く別のアプリやコマンドでした。
投資・事業の観点で押さえること
ここからは当サイトの推測です。今回の2つの事例は、新しいAIエージェントと、広く使われている防御ソフトの両方でゼロデイが見つかったことを示しています。AIエージェントは音声やトークンのような機密性の高いデータを扱います。そのため、導入を検討する企業にとって、提供元の脆弱性対応の速さは評価項目の1つになり得ます。
