当社のAIエンジンNeutronが、UCバークレーのCyberGymベンチマークで97.1%のスコアを記録しました。 詳細を見る

ディープダイブ

ディープダイブ

EDK II PXE ドライバの RCE、Secure Boot より前に発火(CVE-2026-97631)

サーバーがPXEブート中に超過サイズのICMPエラーメッセージでメモリが破壊され、OS読み込み前に攻撃者のコードが実行されます。PXEネットワークを今すぐ分離してください。

TL;DR

  • マシンがIPv4またはIPv6でPXEブートしている間、認証されていないネットワーク攻撃者は超過サイズのICMPエラーメッセージを送り、UEFIブート環境のメモリを破壊できます。この破壊により、OSが読み込まれる前に選ばれたバイト列が実行されます。TianoCoreは2026年10月22日に勧告GHSA-99cj-7hg9-mp4mを公開しました。
  • 対象はネットワークブートする EDK II ベースのファームウェアすべてで、ブート期間中に攻撃者がPXEリスナーへ到達できる場合です。影響はSecure Bootやmeasured bootがOSコンポーネントを検証・測定するより前に発生するため、これらの防御は効きません。
  • TianoCoreのCVEレコードは緊急、CVSS v4.0 9.5と評価しています。CISAのADPは2026年10月30日に悪用を「なし」と記録し、11月1日に確認したKEVフィードにもこのCVEはありません。引用資料は公開PoCを提供していませんが、未公表の悪用を否定するものではありません。
  • 勧告には修正済みリリースが記載されていません。PXEとプロビジョニングのネットワークを信頼できないトラフィックから分離し、不要なネットワークブートを無効化して、ベンダーのファームウェアに修正が含まれるか確認してください。

影響を受けますか?

以下の条件がすべて成立した場合に影響を受けます。

  • マシンのファームウェアが、脆弱なEDK II PXE Base Codeドライバまたはその派生を含んでいる。
  • PXEネットワークブートが有効で、マシンがIPv4またはIPv6でネットワークブートを行うか試みている。
  • そのブート期間中に、攻撃者がユニキャストのICMPエラーメッセージをマシンのIPアドレス宛に届けられる。ネットワーク距離は問いません。

ローカルディスクのみからブートするマシンは影響を受けません。脆弱性はネットワークブートの経路そのものにあります。

ファームウェア 影響を受ける範囲 修正
EDK II 勧告による「2026-09-14時点のmaster」までの全リビジョン。Ars Technicaは16年前の欠陥と説明 修正は2026年10月15日にmasterへマージ済み。修正を含むタグ付きリリースはなし
Debian 13 trixie の edk2(OVMF) 2025.02-8+deb13u1 なし。トラッカーは脆弱かつ未修正と記載
Debian 12 bookworm の edk2(OVMF) 2022.11-6+deb12u2 なし。トラッカーは脆弱かつ未修正と記載
Debian unstable(forky、sid)の edk2 2026.08+ds-2 なし。トラッカーは未修正と記載
ベンダーのサーバーファームウェア 脆弱なEDK II PXEドライバを含むか確認 10月15日の修正を含むかベンダーに確認

上記のDebianパッケージは未修正です。ベンダーのファームウェアは個別に確認してください。ファームウェアを特定し、ネットワークブートの有無を確認します。

# Firmware vendor and version string, to ask the vendor about EDK II content
dmidecode -s bios-vendor
dmidecode -s bios-version

PXEブートはファームウェアで設定されるため、サーバーごとに、またはプロビジョニングツールで調査してください。インストール済みファームウェアが脆弱なドライバと修正を含むか製造元に確認してください。

修正するには?

勧告には修正済みバージョンが記載されていません。ベンダーが修正済みファームウェアを確認するまで、露出を減らしてください。

  1. PXEとプロビジョニングのVLANを信頼できないネットワークから分離し、ネットワークブート中の悪意あるICMPメッセージの到達を制限してください。
  2. 必要のないマシンではPXEとネットワークブートを無効化してください。脆弱なリスナーそのものが消えます。
  3. サーバーベンダーにファームウェアの計画を確認し、リリース時に適用してください。Ars Technicaが引用するEclypsiumの評価によれば、修正は基本的なコード変更とファームウェア更新だけで、鍵の失効も証明書管理も不要です。

限界は明確です。分離はブート中のマシンへ到達できる相手を減らすだけで、ドライバは修正されません。ネットワークブートの無効化は、それを一切必要としないマシンでのみ効果があります。修正済みファームウェアイメージが動くまで、ネットワーク層より下でこのオーバーフローを止めるものはありません。

根本原因は何ですか?

PXEドライバは、受け取ったICMPエラーメッセージを、機能する境界チェックなしに固定サイズのフィールドへコピーします。そのループは、宛先ポインタをフィールドの先へ進めてしまいます。

ネットワークブート中、NetworkPkg/UefiPxeBcDxeのPXE Base Codeドライバは、ICMPエラーメッセージの受信リクエストを開いたままにします。そして各メッセージを、状態構造体の固定フィールド EFI_PXE_BASE_CODE_ICMP_ERROR(Mode.IcmpError)へコピーします。このフィールドは、8バイトのICMPヘッダ共用体に494バイトのデータ配列が続く形です。

フィールドは MdePkg/Include/Protocol/PxeBaseCode.h で定義されています。

typedef struct {
  UINT8     Type;
  UINT8     Code;
  UINT16    Checksum;
  union {
    UINT32    reserved;
    UINT32    Mtu;
    UINT32    Pointer;
    struct {
      UINT16    Identifier;
      UINT16    Sequence;
    } Echo;
  } u;
  UINT8    Data[494];
} EFI_PXE_BASE_CODE_ICMP_ERROR;

修正前の PxeBcSupport.c のコピーループは、IPv4とIPv6の両方のハンドラで、受け取ったメッセージのフラグメントを次のように処理していました。

  CopiedLen = 0;
  IcmpError = (UINT8 *)&Mode->IcmpError;

  for (Index = 0; Index < RxData->FragmentCount; Index++) {
    CopiedLen += RxData->FragmentTable[Index].FragmentLength;
    if (CopiedLen <= sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR)) {
      CopyMem (
        IcmpError,
        RxData->FragmentTable[Index].FragmentBuffer,
        RxData->FragmentTable[Index].FragmentLength
        );
    } else {
      CopyMem (
        IcmpError,
        RxData->FragmentTable[Index].FragmentBuffer,
        CopiedLen - sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR)
        );
    }

    IcmpError += CopiedLen;
  }

2つの欠陥で境界チェックが無効になります。累積長がフィールドを超えると、else 分岐は残り容量ではなく超過長をコピーします。フラグメントの構成によっては、書き込みが宛先フィールドを超えます。

また、このループは IcmpError を現在のフラグメント長ではなく累積合計 CopiedLen だけ進めるため、書き込みカーソルはフラグメントごとにどんどん範囲外へずれていきます。受信経路のより前の段階にはメッセージ長の制限がありません。そのため、1つの超過サイズのICMPエラーメッセージが、攻撃者が選んだバイトを Mode.IcmpError の先のドライバ隣接データへ書き込みます。

どのように悪用されますか?

勧告によれば、攻撃はブート期間中のユニキャストパケット1つです。

  1. マシンがIPv4またはIPv6のPXEブートに入り、ドライバのICMPエラー受信リクエストが有効になります。
  2. 攻撃者は、マシンのIPアドレス宛てに、IcmpError フィールドより大きく選んだバイトを含むユニキャストのICMPエラーメッセージを送ります。パケットがブート中のクライアントへ届けば、ネットワーク距離は問いません。
  3. 受信経路はそのメッセージをIPv4の PxeBcIcmpErrorDpcHandle またはIPv6の PxeBcIcmp6ErrorDpcHandle へ渡し、コピーループがフィールドの先の隣接メモリへ書き込みます。
  4. 破壊された状態は、決定的なブート停止か、対象ファームウェアのビルドを知る攻撃者による攻撃者供与バイト列の実行という結果になります。詳細は後述の通りです。

CISAのADPは2026年10月30日に悪用を「なし」と記録し、11月1日に確認したKEVフィードにもこのCVEはありません。引用資料は公開PoCを提供していませんが、未公表の悪用を否定するものではありません。

攻撃の流れはどうなりますか?

ネットワークブート中に届く1つの超過サイズICMPエラーだけで、OS前の環境を破壊できます。

flowchart LR A["PXEブート中の
ネットワーク上の攻撃者"] --> B["フィールドより大きい
選んだバイトを含む
ユニキャストICMPエラー1通"] B --> C["受信ハンドラ
PxeBcIcmpErrorDpcHandle
またはIPv6版"] C --> D["コピーループがMode.IcmpErrorの
先へ書き込む
(境界チェックの欠落)"] D --> E["DXEフェーズでの
メモリ破壊"] E --> F["ブート停止、またはCoreSignalEventが
偽イベントを配信して実行、
OS読み込み前のring 0"]

攻撃者に何ができますか?

勧告は2つの結果を説明しており、どちらも認証不要でOS前の段階です。

  • 決定的なブート停止。ドライバのプライベートデータの破壊は、次のICMPエラーでDXEコア内のCPU例外を引き起こします。その結果、マシンはネットワークからブートできなくなります。これはOSプロビジョニングとリカバリの拒絶です。
  • ブート環境での任意コード実行。対象ファームウェアのビルドを知る攻撃者は、同じパケットに偽イベントを仕込み、CoreSignalEvent() にDXEフェーズで攻撃者供与のバイト列を配信させられます。コードはring 0で、OSのセキュリティ機構が何も存在しない時点、Secure Bootやmeasured bootがOSコンポーネントを検証・測定するより前に実行されます。

勧告の条件はPXEブート中にICMPエラーを届けられることで、攻撃者をローカルネットワーク内に限定していません。実際の到達性はルーティング、ファイアウォール、プロビジョニングネットワークの分離に依存します。

修正はなぜ機能しますか?

修正コミット 64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec は、両方のコピーループをフラグメント単位の境界で書き直します。IPv4ハンドラは次のようになります。

  for (Index = 0, IcmpError = (UINT8 *)&Mode->IcmpError, CopiedLen = 0;
       (Index < RxData->FragmentCount) &&
       (CopiedLen < sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR));
       Index++, IcmpError += FragmentLen, CopiedLen += FragmentLen)
  {
    FragmentLen = MIN (
                    RxData->FragmentTable[Index].FragmentLength,
                    (UINT32)(sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR) - CopiedLen)
                    );
    CopyMem (IcmpError, RxData->FragmentTable[Index].FragmentBuffer, FragmentLen);
  }

各反復は、フィールドに残っている空間以下だけコピーします。カーソルを同じフラグメント長だけ進め、フィールドがいっぱいになった時点で停止するため、Mode.IcmpError の終わりを超える書き込みは起きません。

IPv6ハンドラにも同じ変更が入り、マージされたプルリクエストは両経路のフラグメントコピーテストと、コピー前にICMPエラーバッファを消去するコミットを追加しています。修正は、勧告が名指しするICMP受信経路について完全です。

修正は2026年10月15日にEDK II masterへマージされました。11月1日時点の最新タグはedk2-stable202608で、Debianも上記パッケージを未修正としています。これらの資料だけでは、すべてのベンダーのファームウェアの状況は確認できません。ベンダーに確認してください。

侵害されたかどうかを確認するには?

勧告には侵害の指標が公開されていません。脆弱なハンドラはOSより前に実行されるため、OSログだけでは悪用を否定できません。失敗した試行ではホストに有用な記録が残らない可能性があります。

DoS経路の観測可能なシグナルは、ブート中のマシンではなくプロビジョニングサーバーのログにあります。

# PXE boot requests seen by a dnsmasq or dhcpd provisioning server
grep -h "PXEClient" /var/log/syslog | tail -20

プロビジョニングネットワーク上の説明のつかないブート停止は、証拠ではなく手がかりとして扱ってください。正当なネットワークの問題も同じ症状を起こします。脅威モデルにプロビジョニングネットワーク内の常駐攻撃者を含める場合は、それらのブートイメージが運ぶ秘密をローテーションしてください。ベンダーが修正済みファームウェアを納品した後、イメージの整合性を帯域外で検証してください。

時系列

  • 2026-09-24: TianoCoreがCVE-2026-97631を予約します。
  • 2026-09-28: AMIがCVEを明記し修正を含むプルリクエストをEDK II上に公開し、Ars Technicaによれば発見者らの1月予定の開示計画を破ります。
  • 2026-10-15: 作り直された修正(プルリクエスト13302)がEDK IIのmasterブランチへマージされます。
  • 2026-10-22: TianoCoreが勧告GHSA-99cj-7hg9-mp4mとCVEレコードを公開します。
  • 2026-10-27: Ars Technicaがこの欠陥と開示の分析を公開します。
  • 2026-10-28: 勧告がメーリングリスト oss-security に届きます。
  • 2026-10-30: CISAのADPが悪用は確認されていないと記録します。

エンバーゴーは勧告の24日前に破られました。AMIの公開プルリクエストは9月28日に現れ、TianoCoreは10月22日に公開しました。

エンバーゴーを破ったプルリクエストから勧告まで24日
図1:開示の日付。9月28日のAMIの公開プルリクエストから10月30日のCISA ADP評価まで。出典:GitHub、TianoCore勧告、Ars Technica(2026年11月1日確認)

FAQ

自分のディスクからブートするマシンは影響を受けますか?

いいえ。欠陥はPXEドライバのネットワークブート経路にあり、PXEブートを試みないマシンはこの受信ウィンドウを開きません。ネットワークブートが無効だと仮定せず、実際の動作とファームウェア設定を確認してください。

なぜSecure Bootはこれを止めないのですか?

破壊された状態と配信されるバイト列は、OSが読み込まれる前のDXEフェーズで実行されます。この時点ではSecure Bootもmeasured bootもOSコンポーネントを検証・測定していません。ブートの後の段階にあるファームウェアのセキュリティ機構は、攻撃者のコードを見ることすらありません。

インストールすべきファームウェア更新はありますか?

勧告には修正済みリリースが記載されていません。修正は2026年10月15日にEDK II masterへマージ済みですが、11月1日時点の最新タグと上記Debianパッケージは未修正です。ベンダーのファームウェアに修正が含まれるか確認し、更新があれば適用してください。

攻撃者に必要なものは何ですか?

ブート中のマシンへのネットワーク到達性、フィールドより大きいユニキャストのICMPエラーメッセージ、そして対象ファームウェアのビルドに関する知識です。悪用にはターゲット固有のアドレスが必要で、Eclypsiumによればモデル・バージョン・構成ごとに調整が要します。

実際に悪用されていますか?

CISAのADPは2026年10月30日に悪用を「なし」と記録し、11月1日に確認したKEVフィードにもこのCVEはありません。引用資料は公開PoCを提供していませんが、未公表の悪用を否定するものではありません。

なぜ今回開示されたのですか?

発見者のAnthropicのAlex MatrosovとGoogleのDan Holmes-Mitraは、1月の調整された開示を予定していました。AMIが2026年9月28日、修正とCVE番号を含むプルリクエストを公開しました。それが発見者らに知られた後、Ars TechnicaによればTianoCoreが勧告を公開しました。

参考文献

  • 勧告GHSA-99cj-7hg9-mp4m、TianoCore、CVSS v4.0 9.5: https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m (2026年10月22日公開、2026年11月1日確認)
  • CVE-2026-97631レコード、TianoCore CNA: https://www.cve.org/CVERecord?id=CVE-2026-97631 (2026年11月1日確認)
  • EDK IIの修正コミット64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec: https://github.com/tianocore/edk2/commit/64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec (2026年11月1日確認)
  • マージ済みの修正プルリクエスト13302: https://github.com/tianocore/edk2/pull/13302 (2026年10月15日マージ、2026年11月1日確認)
  • エンバーゴーを破ったAMIのプルリクエスト13200: https://github.com/tianocore/edk2/pull/13200 (2026年9月28日オープン、2026年11月1日確認)
  • Ars Technicaの欠陥と開示の分析: https://arstechnica.com/security/2026/10/code-execution-flaw-in-uefi-firmware-threatens-most-servers-on-planet-earth/ (2026年10月27日公開、2026年11月1日確認)
  • oss-securityの告知: https://www.openwall.com/lists/oss-security/2026/10/28/4 (2026年10月28日公開、2026年11月1日確認)
  • CVE-2026-97631のDebianトラッカー、edk2パッケージは脆弱かつ未修正: https://security-tracker.debian.org/tracker/CVE-2026-97631 (2026年11月1日確認)
  • 修正コミット時点のMdePkgにおけるEFI_PXE_BASE_CODE_ICMP_ERROR定義: https://github.com/tianocore/edk2/blob/64c7b0c9e7a43a9ef6d70943d36aaf5eaef507ec/MdePkg/Include/Protocol/PxeBaseCode.h (2026年11月1日確認)
  • CISAのKEVカタログ、CVE-2026-97631について確認したフィード: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (2026年11月1日確認)
  • EDK IIのリリース: https://github.com/tianocore/edk2/releases