UEFI Shellでセキュアブート回避、4社に脆弱性

2026年9月8日（現地時間）、CERT/CCが「UEFIファームウェアに組み込まれたUEFI Shellを悪用してセキュアブートを回避できる」脆弱性を公表しました。翌9日にはJPCERT/CCもJVNVU#94974158として国内向けに注意喚起しています。現時点でAMI（American Megatrends）、Insyde Software、GIGABYTE、Cisco UCSの4社が影響ありと表明し、CVEは3件（CVE-2026-20293／CVE-2026-33197／CVE-2026-6485）が採番されています。

悪用にはローカルかつ管理者相当の権限が必要なため、これ単体で外部から侵入されるものではありません。ただし成功するとOSが起動する前に任意のコードを実行でき、OSを再インストールしても残る足場を作られます。侵入されたあとの「居座り」を許すかどうかを分ける脆弱性です。

この記事でわかること

  • AMI・Insydeとは何者で、なぜ「うちは使っていない」が通用しないのか
  • 3件のCVEの違いと、実際に何ができてしまうのか
  • 自社PC・サーバーのファームウェアベンダーを確認する具体的な手順
  • 主要メーカーの多くが「状況不明」のままである点をどう扱うか

AMI・Insydeとは何者か（「うちは使っていない」が通じない理由）

AMI（American Megatrends Inc.）とInsyde Softwareは、PCやサーバーのUEFIファームウェア（いわゆるBIOS）そのものを開発している専業ベンダーです。IBV（Independent BIOS Vendor、独立系BIOSベンダー）と呼ばれます。

この2社の名前を資産管理台帳で見たことがある情シスはまずいないはずです。理由は単純で、PCメーカーやサーバーメーカーがIBVからファームウェアの基盤を調達し、自社ブランドの製品として出荷しているからです。利用者が目にするのは「メーカー名のBIOS設定画面」であり、その中身を誰が作ったかは表に出ません。ソフトウェアを「導入した」記憶がないのに影響を受ける、典型的な組み込み型のコンポーネントです。

ただし、どのメーカーのどの型番にAMIやInsydeのファームウェアが載っているかを推測で書くことはしません。CERT/CCのベンダーステータス一覧でも、Dell・Lenovo・HP・富士通・Microsoftを含む多くのベンダーは「不明（Unknown）」のままです。代わりに、自社の手元で確認する方法を後述します。

もう1社のGIGABYTEはマザーボードとPCのメーカー、Cisco UCSはデータセンター向けのサーバー製品群です。Cisco UCSは自社アドバイザリでCVE-2026-20293として個別に公表しています。

何が起きるのか：ブートエントリを増やしてUEFI Shellに入る

UEFI Shellとは、OSが起動する前のファームウェア段階で動くコマンドライン環境です。本来は保守・診断のために用意されているもので、メモリやディスクを直接読み書きするコマンド（dmem、mm など）を持っています。

CERT/CCの説明によれば、今回の問題はUEFIのブートオプション（起動エントリ）管理のロジック上の欠陥です。十分な権限を持つ攻撃者が起動エントリを複数作成することで、セキュアブートの検証を素通りしてUEFI Shellに到達できるとされています。UEFI Shellに入ってしまえば、メモリへの制限のないアクセスが可能になります。

セキュアブートは「署名されたものしか起動させない」という仕組みでブートキットを防いでいます。その検証をすり抜けられるということは、OSより先に読み込まれるマルウェア（ブートキット）を仕込む道が開くということです。ブートキットの厄介さは、OSの再インストールやディスクの交換では消えず、OS上で動くセキュリティ製品からは見えにくい点にあります（この構図はUEFI脆弱性とブートキットで詳しく解説しています）。

3件のCVEの違い

CVE 対象 CVSS（採点元） 内容
CVE-2026-20293 Cisco UCSサーバーおよびUCSベースのアプライアンス 7.1／High（Cisco PSIRT、CVSS v3.1 AV:L/AC:L/PR:L） user／admin権限を持つ認証済み攻撃者、または物理アクセスのある未認証の攻撃者がセキュアブート検証を回避し、未承認のソフトウェアを実行できる
CVE-2026-33197 AMI APTIOV（BIOS） 8.7／High（AMI、CVSS v4.0 AV:L/AC:L/PR:H） 「許可しない入力のリストが不完全」な問題。特権ユーザーがローカルアクセスで任意コード実行に至り、機密性・完全性・可用性に影響
CVE-2026-6485 Insyde Software（UEFI BIOS） 8.2／High（Insyde、CVSS v3.1 AV:L/AC:L/PR:H/S:C） UEFI BIOSに組み込まれたShellが、シェルコマンドまたは起動スクリプト経由でセキュアブート回避に使われうる

3件とも攻撃元区分はローカル（AV:L）で、権限も必要です。CVSSが7〜8点台にとどまるのはそのためで、「未認証・リモート」の脆弱性のような緊急性はありません。一方で、Cisco UCSの1件だけは「物理アクセスがあれば認証不要」とされている点に注意が必要です。データセンターやサーバールームの物理的な入退室管理が、そのまま防御線になります。

現場目線：優先度は高くないが、放置していい種類でもない

正直に言えば、この脆弱性は「今すぐ全台のBIOSを更新せよ」と号令をかける類のものではありません。前提となる管理者権限をすでに取られている時点で、攻撃者は他にもできることが山ほどあります。優先度は、未認証RCEやすでに悪用が確認されている脆弱性より確実に下です。

それでも無視しにくいのは、BIOS更新が「思い立ったときにすぐできる作業ではない」からです。OSのパッチと違って配布基盤に乗りにくく、機種ごとに手順が異なり、失敗すれば端末が起動しなくなるリスクがあります。ノートPCなら「電源接続必須・作業中は電源を切らせない」という利用者への周知も要ります。結果として、多くの組織でBIOSは出荷時のまま何年も動き続けます。

つまりこの手の脆弱性は、単独で対応するのではなく「次にキッティングするとき」「次に定期メンテナンスするとき」に確実に拾える仕組みを作れているかが問われます。今回を、自社のファームウェア更新が何年止まっているかを棚卸しするきっかけにするのが現実的だと考えます。

自社が該当するかを確認する手順

ベンダー名は製品情報から確認できます。Windows端末では、PowerShellで次のコマンドを実行します。

Get-CimInstance -ClassName Win32_BIOS | Select-Object Manufacturer, SMBIOSBIOSVersion, ReleaseDate

Manufacturer にPCメーカー名ではなく「American Megatrends」「Insyde」等が表示される機種があります。GUIで確認する場合は msinfo32 の「BIOSバージョン/日付」でも同じ情報が読めます。ReleaseDate が数年前のままなら、今回の件に関わらず更新対象の候補です。

そのうえで、次の順に確認するのが実務的です。

  1. PC・サーバーのメーカー公式のセキュリティアドバイザリを確認する。対策ファームウェアの提供有無は、最終的に各メーカーの配布物に依存します。
  2. Cisco UCSを使っている場合はCiscoのアドバイザリを優先確認する。CVE-2026-20293として個別に公表されており、物理アクセスによる悪用の可能性が示されています。
  3. 主要メーカーが「不明」のままなら、今は続報待ちで構わない。ただし待つと決めたことを記録に残し、次のキッティング・メンテナンスのタイミングで再確認する。
  4. ローカル管理者権限の棚卸しを行う。前提条件が管理者権限である以上、これが一番効きます。利用者に恒常的な管理者権限を配っていないか、共有の管理者パスワードが使い回されていないかを見直す。

4点目は今回の脆弱性に限らず効果があります。端末の権限設計や資産管理の考え方を整理し直すなら、IPAの中小企業の情報セキュリティ対策ガイドラインが土台として使えます。また、ファームウェア層の侵害はOS上のログに残りにくく、発覚時の初動が難しい領域です。想定訓練をしておきたい場合は、IPAのセキュリティインシデント対応 机上演習教材が無償で利用できます。

まとめ

  1. UEFI Shellを経由してセキュアブートを回避できる脆弱性が3件公表された。影響を認めているのはAMI、Insyde、GIGABYTE、Cisco UCSの4社。Intelとフェニックスは影響なしと表明している。
  2. 悪用にはローカルの管理者相当の権限が必要で、緊急性は高くない。ただし成功するとOS再インストールでも消えない足場を作られる。Cisco UCSのみ物理アクセスでの悪用可能性が示されている。
  3. Dell・Lenovo・HP・富士通など主要メーカーの多くは状況不明のまま。今は続報待ちで構わないが、自社端末のファームウェアベンダーと最終更新日を確認し、次の更新機会に拾える運用にしておく。

関連記事

出典

タイトルとURLをコピーしました