TianoCoreのUEFIファームウェア開発基盤「EDK II」で、PXEによるネットワークブート中に受信したICMPエラーを処理するドライバーに脆弱性が見つかった。2026年10月22日に公開されたGitHubのセキュリティアドバイザリーでは、深刻度を「Critical」、CVSS v4スコアを9.5と評価している。条件がそろえば、Secure Bootやmeasured bootによってOSの構成要素が検証・測定される前に、ファームウェア段階で任意コードを実行される恐れがある。
今回注目すべきなのは、脆弱性そのものに加えて、修正コードが公開された時期だ。攻撃を成立させるには機種ごとの調整が必要とされる一方、修正コードはセキュリティアドバイザリーの公開より24日早く、誰でも閲覧できるGitHubのプルリクエスト（PR）に掲載されていた。脆弱性の詳細が正式に通知される前から、修正内容を手掛かりに問題箇所を調べられる状態だったことになる。この時間差と、修正版ファームウェアが実際の機器に届くまでの遅れが、今回のリスクを考えるうえで重要となる。
504バイトの領域を超えて書き込む欠陥
脆弱性が見つかったのは、EDK IIの「NetworkPkg」に含まれるPXE Base Codeドライバー「UefiPxeBcDxe」だ。セキュリティアドバイザリーによると、このドライバーはネットワークブート中、ICMPエラーメッセージの受信要求を維持し、受信したデータを内部構造体の固定長フィールド「Mode.IcmpError」にコピーする。このフィールドに確保されている領域は504バイトである。
問題は、IPv4用の「PxeBcIcmpErrorDpcHandle」とIPv6用の「PxeBcIcmp6ErrorDpcHandle」の両方で、コピーするデータ量の制限が適切に行われていないことだ。504バイトを超えるメッセージでもコピーが続けられるうえ、書き込み先のポインターを各データ断片の長さではなく、累積した長さに基づいて進めてしまう。その結果、攻撃者が細工した長いICMPエラーメッセージを受信すると、用意された504バイトの領域を超えてデータが書き込まれる。アドバイザリーによれば、受信処理の前段にもメッセージ長を制限する仕組みはないという。
このメモリ破壊によって、主に2種類の被害が考えられる。1つは、後続のICMPエラーを処理する際にDXEコア内でCPU例外が発生し、起動処理が停止するケースだ。これだけでも、ネットワーク経由でのOS展開やシステム復旧を妨害できる。
もう1つは、対象機器のファームウェア構成を把握した攻撃者が、パケット内に偽のイベントを仕込むケースである。メモリ破壊を利用して「CoreSignalEvent()」にそのイベントを処理させ、攻撃者が用意したバイト列をDXEフェーズで実行させる可能性がある。DXEはUEFIファームウェアが各種ドライバーを読み込んで初期化する段階であり、OS側のセキュリティ機構はまだ動作していない。アドバイザリーでは、この段階でのコード実行権限をring 0と説明している。
攻撃に必要なネットワーク上の条件は比較的単純だ。PXEブート中のクライアントのIPアドレスにユニキャストのICMPエラーメッセージを送信できれば、同じローカルネットワーク上にいる必要はなく、認証も求められない。ただし、脆弱性を攻撃できるのはPXEによるネットワークブートが進行している間に限られる。CVSS v4の評価ベクターには「AV:N/AC:L/PR:N/UI:N」が設定されている一方、攻撃成立に追加の前提条件が必要であることを示す「AT:P」も付いている。この前提条件は、実際の悪用可能性を判断するうえで重要だ。
発見者としてアドバイザリーに記載されているのは、AnthropicのAlex MatrosovとGoogleのDan Holmes-Mitraで、両氏は修正案も提供したという。なお、EDK IIのPXE関連コードで脆弱性が見つかったのは今回が初めてではない。2024年1月には、Quarkslabが同じNetworkPkgのPXE（IPv6）スタックに存在する9件の脆弱性を「PixieFail」として公表している。当時、影響を受けるベンダーとしてArm、Insyde、AMI、Phoenix、MicrosoftのProject Muなどが挙げられていた。
脆弱性の正式公表より24日早く公開された修正コード
公開されている記録を時系列で確認すると、修正コードの提出からセキュリティアドバイザリーの公開までに24日間の隔たりがあった。
まず、アドバイザリーが影響範囲の基準としているのは、2026年9月14日時点のEDK IIのmasterブランチだ。その14日後の9月28日、AMIのメールアドレスで署名されたコミットを含むPR#13200が、GitHub上の「tianocore/edk2」公開リポジトリに提出された。
PRのタイトルには「CVE-2026-97631」と問題のモジュール「NetworkPkg/UefiPxeBcDxe」が明記されていた。本文では、大きなパケットによって確保済みバッファの外側にデータが書き込まれることを根本原因と説明し、境界チェックの追加とデータ長の上限処理によって修正する方針を示している。変更規模は1コミットで、22行の追加と30行の削除だった。
10月6日にはPRの提出者がレビューを依頼し、翌7日にはメンテナーが単体テストの追加を求めるとともに、修正案を含む別のブランチを公開した。その後、10月14日にメンテナーは、提出者から応答がないことと、自身が提出したPR#13302との重複を理由にPR#13200を閉じた。PR#13302は同じタイトルでCIを通過し、マージキュー経由で取り込まれたことがGitHub上に表示されている。正式なセキュリティアドバイザリーが公開されたのは、さらに8日後の10月22日だった。
つまり、CVE-2026-97631の修正コードは、正式公表に先立つ24日間、公開PRを通じて誰でも閲覧できる状態にあった。もちろん、PRに書かれていたのは修正内容であり、そのまま利用できる攻撃コードではない。それでも、脆弱性が存在するドライバーと問題のある処理、修正方法まで具体的に示されていたことになる。
Ars Technicaの報道によると、発見者らは当初、2027年1月の協調公開を予定して調整を進めていたという。しかし実際には、共通の通知となるセキュリティアドバイザリーが公開される前に、修正内容だけが先に明らかになった。少なくともメンテナーやレビュアーが公開PRを確認していたことは、GitHub上のコメントから確認できる。一方、攻撃者がこのPRを閲覧していたかどうかや、実際に脆弱性が悪用されたかどうかは、公開情報からは確認できない。
さらに重要なのは、修正コードが上流のリポジトリに取り込まれても、それだけで利用者の機器が保護されるわけではないことだ。10月28日時点のDebianのセキュリティトラッカーでは、bookworm、trixie、forky/sidのedk2パッケージがいずれも「vulnerable」と表示され、unstableについても修正版の状態は「unfixed」となっていた。同じページには上流の修正コミット3件が記載されており、修正コードは存在していても、ディストリビューションのパッケージにはまだ反映されていない状況が確認できる。
実際のPCやサーバーのファームウェアを更新する場合、上流での修正に加え、BIOSベンダーや機器メーカーによる統合、検証、配布が必要になる。Ars Technicaは10月27日の記事で、AMD、Phoenix、AMI、Microsoft、Amazonに問い合わせたものの、公開時点で回答を得られなかったと報じている。このことからも、上流で修正が完了した時点と、実際の機器に修正が届く時点は区別する必要がある。
なお、Debianのトラッカーはtrixieにおけるこの問題を「Minor issue」と分類し、Debian Security Advisory（DSA）を発行しない「no-dsa」として扱っている。トラッカーにはその判断理由が明記されておらず、CVSS v4で9.5というCritical評価との違いを直接説明することはできない。ただし、脆弱性そのものの深刻度と、特定のディストリビューションにおける実際の影響や対応優先度は、必ずしも一致するものではない。
悪用の難しさと、2027年1月までに確認すべきこと
今回の脆弱性について、危険性を過大評価しないために押さえておくべきなのが、任意コード実行までのハードルだ。アドバイザリー自身が、コード実行を成立させるには対象のファームウェアビルドに関する知識が必要だと説明している。ネットワーク経由で細工したパケットを送信できることと、実際に任意コードを実行できることは同じではない。
Eclypsiumの主任研究員Jesse MichaelはArs Technicaに対し、攻撃者は対象システム内の特定のメモリアドレスを推測する必要があると説明している。異なる機器に同じエクスプロイトを使っても、そのまま遠隔コード実行が成立するわけではなく、機種やファームウェアのバージョン、構成に応じた調整が必要になるという。また、Secure Bootのバイパスを修正する場合とは異なり、証明書の失効や鍵の更新、OSやプロビジョニング用メディアの更新までは必要なく、BIOS/UEFIファームウェアの更新で対処できるとも指摘した。
この指摘は妥当であり、攻撃が広範囲に拡大する可能性を考えるうえで重要だ。多種多様な機器に対して同じ攻撃コードを無差別に使用し、次々と任意コードを実行するような攻撃は成立しにくい。攻撃者が利用できるネットワーク上の経路が存在しても、標的ごとに調整が必要なことは大きな制約となる。
一方、標的の機種やファームウェアが分かっている場合、この制約の意味は変わってくる。例えば、データセンター内部にすでに侵入している攻撃者が、特定のサーバー群を狙う場合には、対象環境に合わせた調整が現実的な選択肢になり得る。調整に必要なメモリアドレスはファームウェアのビルドによって決まるものであり、公開された修正差分から直接得られるわけではない。それでも、公開PRによって脆弱な処理を探し出す手間が減ることには意味がある。今回の問題で特に注意すべきなのは、不特定多数への無差別攻撃よりも、標的を絞った攻撃と、修正の適用が遅れる機器だと考えられる。
日本国内でも、PXEを利用して多数のサーバーへOSを一斉展開したり、障害発生時にネットワーク経由で復旧したりする運用環境は、確認の対象となる。Ars Technicaによれば、影響を受けるのはEDK II系のファームウェアを搭載し、問題のあるPXE機能を利用する機器だ。PXE機能が有効でも、実際にネットワークブートを行っていなければ、今回の攻撃経路にさらされる機会は限定される。家庭や一般的なオフィスのPCなど、通常は内蔵ストレージから起動するだけの機器では、直ちに同じリスクが生じるわけではない。まずは使用しているファームウェアが影響を受けるEDK II由来の実装かどうか、そしてPXEブートを利用しているかを確認する必要がある。
今後の判断材料となるのは、当初の協調公開予定だった2027年1月までに、修正版ファームウェアの提供がどこまで進むかだ。AMIやInsydeなどの主要BIOSベンダーが修正を組み込んだファームウェアを出荷すれば、少なくともベンダー段階で修正が滞留する懸念は弱まる。ただし、機器メーカーによる配布や現場での適用が完了するまでは、利用者の機器に残るリスクが解消されたとはいえない。したがって、修正版の出荷状況と実際の適用状況は分けて確認すべきである。
ソフトウェア側では、Debianのセキュリティトラッカーでedk2の状態が「unfixed」から修正済みに変わるかどうかが、更新の進展を測る指標になる。一方、機種別の調整手順を含む概念実証コード（PoC）が公開されれば、これまで攻撃の障壁となっていた技術的な難しさが下がる可能性がある。AMDやPhoenixなど、10月27日時点で回答が得られていなかったベンダーが、修正の提供状況を明らかにするかどうかも注目点だ。
今回、最初に公開されたPR#13200の変更規模は、22行の追加と30行の削除にすぎない。しかし、修正コードが小規模であることと、修正版をすべての対象機器へ届けることの難しさは別問題である。重要なのは、修正が完成した日ではなく、実際に機器へ適用されるまでの時間だ。2027年1月に向けた各ベンダーの出荷状況と、その後の機器メーカーによる更新の進展が、今回の脆弱性によるリスクがどれだけ長く残るのかを判断する材料となる。
