Acer・東芝などのPCにセキュアブートの穴、2ヶ月経っても塞がらないまま

Acer・GIGABYTE・東芝（Toshiba Corporation）など複数のパソコンメーカーが署名して配っていた小さなソフトに、パソコン起動時の安全装置「セキュアブート」をすり抜けられる弱点が見つかりました。国の脆弱性情報サイトJVN（JVNVU#93024090）と、米CERT/CCの脆弱性情報（VU#457458）で2026年6月に公表された事案です。

この記事は2026年6月19日に公開しました。それから2ヶ月、一次情報をたどり直したところ、公開当時の記述に3つの誤りが見つかりました。うち1つは記事の結論そのものに関わります。お詫びして訂正します。

公表から2ヶ月経った今日の結論を先に書きます。この事案は、いま使われている仕組みでは塞がる見込みが立っていません。危険と分かっているソフトを「もう信頼しない」と登録するDBXという仕組みがあるにもかかわらず、本件の12件はそこに載っていません。載せられない理由も、Microsoft自身が公開の場で認めています。そのうえで利用者ができる現実的な手当ては、BIOSの管理者パスワードを設定し、USBメモリなど外部デバイスからの起動を止めておくことです。ファームウェア更新でもDBX更新でもなく、この2つがいちばん効きます。

失効リストを実際に開いてみました

JVNが勧告を出したのが2026年6月19日です。では、危険と判定されたソフトを締め出すための「失効リスト」に、本件のソフトは入ったのでしょうか。Microsoftはこのリストの原本をGitHubのsecureboot_objectsというリポジトリで公開しています。誰でも中身を開いて読めます。開いて数えました。

照合の手順は単純です。配布されているdbx_info_msft_latest.jsonに載っている全673エントリ（x64が443件、ia32が94件、aarch64が26件、armが110件）と、CERT/CCが本件のページに掲載している12バイナリのハッシュ（Authenticode SHA1が12値、SHA256が10値、合わせて22値）を突き合わせました。

一致は0件でした。ハッシュだけでなく、リストに含まれる企業名フィールド57種も見ましたが、Acer・ASUS・Toshiba・GIGABYTE・Getac・ECS・Uniwill のどれ1つとして含まれていません。勧告から2ヶ月、本件のソフトは1バイナリも失効していないということです。

2026年に入ってから失効リストに追加されたのは、次の13件だけです。

報道などで見かける「2026年6月9日の月例更新で失効した」という話は、別の事案です。あれはVU#616257（CVE-2026-8863）というshimの脆弱性への対応であって、本件のVU#457458に対するものではありません。公開時の記事はここを区別できていませんでした。

なぜ失効リストに入らないのか

「危険だと公表されたのに、なぜ登録されないのか」という疑問には、Microsoft自身が答えています。同社はGitHubのIssue #447（2026年7月10日起票、すでにクローズ済み）で、失効リストが限界に来ていることを認めました。

仕組みを噛み砕くと、こうなります。失効リストは、世界中のパソコンに同じ内容がそのまま配られる設計です。1台ごとに「あなたの機種に関係するぶんだけ」を選ぶ機能がありません。一方、リストを貼り出す場所はパソコンの中の小さな不揮発性メモリ（NVRAM。電源を切っても内容が残る設定保存用の領域）で、広さは機種ごとに決まっています。配る紙は増え続けるのに、貼る場所は最初から決まっていて広げられません。x64向けだけで443エントリという現在の量は、その場所を圧迫するところまで来ています。

Issueには、Windows 11の公式対応機種であるThinkPadでも、セキュアブート変数の更新に失敗すると書かれています。古い機械の話ではありません。同じ問題はfwupd（LinuxでファームウェアやDBXを更新する仕組み）でも起きていて、「Not enough efivarfs space（領域が足りない）」でDBX更新が失敗する報告が出ています。

実際、容量に合わせて中身が削られてもいます。ブートキットBlackLotusに関係する154個のハッシュが「isOptional（任意）」という扱いで配布物から落とされているのです。しかもこの isOptional という扱い方は、公式に文書化されていません。危険度で選ばれたのではなく、入りきらないから外された、という順序です。

つまり本件が失効リストに入らない背景には、「危ないと分かっていても、容量の都合で失効させられない」という構造があります。DBXは無限に足せる名簿ではなく、すでに満杯に近い掲示板です。新しく貼るには、何を貼らないかを決めなければなりません。

誰が署名したかで、直るか直らないかが決まる

容量の話だけでは説明が足りません。同じ2026年4月9日に、shimの11件は失効リストへ追加されているからです。しかもこのshimの件（VU#616257 / CVE-2026-8863）を報告したのは、本件と同じESETのMartin Smolár氏です。同じ研究者が同じ時期に報告した、同じセキュアブート回避の話でありながら、一方は失効し、もう一方は失効していません。

違いは、署名した相手です。

shimはMicrosoftのCA（証明書を発行する認証局）で署名されています。だからMicrosoftは、自分が出したお墨付きを自分の判断で取り消せます。手続きの相手も自分自身なので、話が早い。一方、本件の12バイナリは、Acer・Toshiba・GIGABYTEといった各メーカー自身の証明書で署名されています。Microsoftのお墨付きではないため、Microsoftが取り消す立場にありません。では誰が取り消すのかというと、署名したメーカーです。そして後述のとおり、そのメーカーの多くはCERT/CCの照会に回答していません。

弱点の中身が同じでも、誰が署名したかによって、直るものと直らないものに分かれます。これがこの事案の本質です。セキュアブートは「メーカーの署名があるものは通す」という信頼で成り立っていますが、その信頼を撤回する手続きは、署名を出した側にしか用意されていません。撤回する気がない、あるいは撤回する体制がない相手の署名は、危険と公表されたあとも有効なまま残り続けます。

セキュアブートとは何か、すり抜けがなぜ怖いのか

セキュアブートは、パソコンの電源を入れてからWindowsなどのOSが立ち上がるまでの間に、「正規のメーカーが署名した（お墨付きを与えた）ソフトだけを実行する」しくみです。途中で見知らぬプログラムが割り込もうとしても、署名がなければ動かさないことで、起動の土台にウイルスが入り込むのを防ぎます。多くのWindowsパソコンで最初から有効になっています。

この土台に入り込むウイルスは「ブートキット」と呼ばれ、特に厄介です。OSより先に動くため、Windowsの中で動くウイルス対策ソフトからは見えにくく、OSを入れ直しても、パソコンを再起動しても生き残ります。セキュアブートは、まさにこのブートキットを締め出すための門番です。その門番をすり抜けられる弱点が、今回見つかったものです。

問題は、門番が「メーカーの署名さえあれば通す」点にあります。今回は、メーカー自身が署名して配っていた正規のソフト（パソコンの保守や起動に使う小さなプログラム）の中に、危険な操作を許してしまうものが含まれていました。つまり攻撃者は、新しい不正ソフトを作らなくても、すでにお墨付きのある正規ソフトを悪用するだけで門を通れてしまいます。署名済みの正規部品が穴になる構図は、当サイトで取り上げた公式イメージに初期パスワードが残っていた事例とも通じます。

なお、署名を撤回する側の名簿が「DBX」です。db（信頼するものの名簿）に対して、dbxは「もう信頼しない」ものの名簿にあたります。門番は入場者の顔をこの2つの名簿と照らし合わせて通す・通さないを決めます。本件で起きているのは、危険と公表された顔が、いつまでも「通さない名簿」の側に載らないという状態です。

この門をこじ開けに来るのは誰で、何を残していくのか

この弱点は、ネット越しに誰でも一発で踏める種類のものではありません。攻撃者がまず管理者権限を握るか、パソコンを直接いじれる状態になって初めて成立します。だからこそ、その一歩手前まで来ている相手が誰で、門をこじ開けたあとに何を置いていくのかを思い描いておく意味があります。

来るのは、すでに別のウイルスでパソコンに侵入して管理者権限を握った攻撃者、企業の端末を長く監視し続けたい国家ぐるみのスパイ集団、整備や転売の名目で他人の端末を物理的に触れる立場の人間、そして盗んだノートパソコンを解析する窃盗犯です。彼らがこの門の先に残していくのは、OSの入れ直しでも消えない常駐ウイルス、キー入力やパスワードをのぞき見る盗聴の仕掛け、いつでも遠隔操作できる裏口、そしてウイルス対策ソフトの監視を最初から無効化する土台への居座りです。門をすり抜けられた瞬間、その端末は「初期化しても綺麗にならないパソコン」へと変わってしまいます。

技術的に見ると、攻撃者は事前の偵察で対象の端末がどのメーカー製かを把握し、そのメーカーの署名が付いた脆弱なソフトを正規の手順で読み込ませます。署名があるためセキュアブートはこれを止めません。読み込まれたソフトが備える危険な操作を踏み台に、署名のないプログラム（＝本来の門番なら弾くはずのブートキット）を起動の土台に書き込みます。一度居座れば、OSより先に主導権を握るため、上で動くあらゆる防御の手前から監視と改ざんを行えます。標的型の長期スパイやランサムウェアの初期侵入後の足場固めに使われやすく、こうした集団の手口は主要なハッカー・ランサム集団のまとめでも整理しています。

ただし、ここにはもう1つの条件があります。読み込ませる脆弱なソフトは、その署名元の証明書を信頼している機体でしか通りません。OEMの証明書は基本的に、そのOEM自身が作った機体にしか入っていないためです。Acerの証明書で署名されたソフトを、Acerの証明書を持たないパソコンに持ち込んでも、門番は署名を知らないので通しません。「どのメーカーのパソコンでも一律に危ない」という話ではないのは、この理由によります。

JVNVU#93024090で実際に何が起きるのか

弱点の正体は、メーカーが署名して配っていた一部の「UEFIアプリ」と呼ばれる小さなプログラム（起動前に動くシェルやブートローダ）に、危険な操作がそのまま使える状態で残っていたことです。CERT/CCの情報によると、問題になるのはUEFIシェルの mm（メモリの直接書き換え）と、dmpstore / setvar（起動時の設定領域NVRAMの読み書き）です。UEFIシェルは、OSが立ち上がる前に使える簡易的なコマンド入力環境で、本来は保守や検証のための道具です。

これは「正規の鍵で開く道具を悪用する」タイプの攻撃で、新しい不正ソフトを持ち込む必要がありません。攻撃者は、メーカーの署名が付いた正規ソフトをセキュアブートに正規の手順で通したうえで、その中の危険なコマンドを使い、署名のないプログラムを起動の土台に書き込みます。結果として、本来は弾かれるはずのブートキットが、メーカーのお墨付きを借りて起動できてしまうわけです。OSが立ち上がる前に主導権を握られるため、Windows上のウイルス対策ソフトでは検知が難しくなります。

成立には条件があります。攻撃者があらかじめ管理者権限を持っているか、端末を物理的に操作できること、そしてその署名元の証明書を信頼している機体であることです。ネット越しに何もしていない人がいきなり乗っ取られるものではありません。とはいえ、別のウイルスで管理者権限を奪う手口は珍しくなく、いったんこの段階に達した攻撃者にとっては、検知も駆除も困難な「居座りの完成形」を作れる一手になります。本件が実際に悪用されたという報告は、2026年8月17日時点で確認されていません。

報告者はESETのMartin Smolár氏で、CERT/CCへの報告は2026年2月16日です。個別のCVE番号は付番されておらず、CERT/CCとJVNの管理番号でまとめて扱われています。

自分のパソコンは対象なのか

影響を受けるかは、脆弱なバイナリの署名元と、その署名元の証明書が自分の機体に入っているかで決まります。CERT/CCが挙げている12件の内訳は次のとおりです。公開時の記事はここを「Acer・ASUS・GIGABYTE・東芝ほか」とまとめて書いていましたが、実際の署名元はもっと細かく、一般に流通していないOEM向けのものが混じっています。

ASUSの名前が入っている1件は「ASUS schenker-tech.de(XMG)」で、ドイツのXMG／Schenker系OEM向けの署名です。店頭で売られている一般的なASUS製PCではありません。ASUSTeK Computer Inc. 自身は、CERT/CCのベンダー一覧で「Not Affected」と回答しています。公開時の記事はこの名前を見てASUSを対象に含めてしまいました。訂正します。

同じく「Toshiba」はToshiba Corporation名義であって、Dynabook株式会社ではありません。日本では「東芝のパソコン＝dynabook」と受け取られますが、この2つは別の会社です。Dynabookのサポートサイトに本件への言及はありません（同社が2026年2月17日付で出しているセキュアブート証明書の期限切れに関する告知は、別の話です）。dynabook製PCのドライバーに関する脆弱性は別の記事で扱っています。

ベンダー各社の回答状況は次のとおりです。「影響あり」と認めたのはGIGABYTE1社だけで、署名元の多くは回答していません。

それでも慌てる必要はありません

「塞がる見込みが立っていない」と書くと不安に思われるかもしれませんが、危険度の見方は落ち着いています。理由を並べます。

まず前提が重い。攻撃者は先に管理者権限を奪うか、端末を直接操作できる状態になっている必要があります。そこまで到達している時点で、この脆弱性がなくても相当なことができる状況です。加えてその署名元の証明書を信頼している機体でしか成立しません。OEMの証明書は基本的にそのOEM自身の機体にしか入っていないため、たとえばXMG向けの署名が付いたバイナリを他社製PCで通すことはできません。

次に、悪用の実績です。実際に悪用されたという報告は確認されていません。ESET、CERT/CC、Microsoftのいずれも、実環境での悪用には触れていません。米政府CISAが「実際に攻撃されている脆弱性」としてまとめているKEVカタログも確認しました。2026年8月14日版の1,665件を対象に、UEFI・Secure Boot・bootkit・shim・GRUB・BlackLotus のどのキーワードでも該当は0件です。ブートキットとして有名なBlackLotusのCVE-2023-24932ですら、KEVには収載されていません。KEVの読み方はこちらの記事にまとめています。

悪用されやすさを機械的に推定するEPSSという指標もあります。本件には個別のCVEがないため数値がありませんが、同じ研究者が報告した別件のshim（CVE-2026-8863）は0.00110で、全体の下位1.5%にあたります。この種の脆弱性が、広く自動的に狙われるものではないことの傍証になります。

起動の土台に居座られたときの被害が重いことと、いま実際に踏まれる確率が高いことは、別の話です。本件は前者が重く、後者は低い——そう読むのが妥当なところです。

どう対処すればいいのか

公開時の記事は「ファームウェア更新とDBX更新で塞ぐ」と書きました。前者は各メーカー次第、後者は前述のとおり本件では機能していません。実際にできることを、正直に順序立てて書き直します。

1. Windows Updateは当ててください。ただし本件のためではありません。2026年に控えるセキュアブート証明書の期限切れ対応と、別件であるshimの失効を取り込むためです。こちらは実際に4月・6月の更新に入っています。Microsoftのセキュアブート証明書とCA更新の案内に経緯が出ています。本件のハッシュはここに含まれていないので、更新を当てても本件が塞がるわけではない、という点は正確に押さえておいてください。

2. GIGABYTE製品を使っている方へ。唯一「影響あり」と回答したベンダーです。ただし対応はファームウェア更新ではありません。BIOS更新パッケージから署名済みUEFIシェルを削除し、古い配布物をサーバから消したというのが同社の対応です。すでにダウンロード済みの BIOS_flash_tool.zip や古いBIOSのZIPが手元に残っている場合は削除し、2026年6月12日以降の配布物を使ってください。手元のファイルが危険物のままなので、消す作業に意味があります。あわせて同社は、BIOS管理者パスワードの設定と、外部デバイスからの起動の無効化を挙げています。

3. BIOSパスワードと、USB起動の無効化。これがいちばん効きます。この攻撃は物理アクセスか管理者権限が前提です。BIOS（UEFI）設定画面に管理者パスワードを掛け、USBメモリや外付けドライブからの起動を無効にしておけば、脆弱なバイナリを持ち込んで実行させる経路そのものが塞がります。署名の失効を待つより、持ち込ませない設定のほうが確実です。会社の端末なら、ディスク暗号化（BitLocker等）と管理者権限の絞り込みも同じ方向の備えになります。

4. Acer・Toshiba Corporationほかは、対応状況が分かりません。CERT/CCの照会に回答しておらず「Unknown」のままです。各社のサポートページを見て、自分の機種向けの更新やセキュリティ情報が出ていないかを確認するくらいしか手がありません。出ていなければ、上の3番が現実的な備えになります。

自分の環境を確認する方法

Windowsでは、管理者権限のPowerShellから次の3つで状態を見られます。

1つ目はセキュアブートが有効かどうかの確認、2つ目は「信頼している証明書の一覧（db）」、3つ目は「信頼しないものの一覧（dbx）」の表示です。-Decoded は中身を人間が読める形で出すためのパラメータで、KB5093574（2026年4月28日）で追加されました。それ以前の環境では使えません。詳細はGet-SecureBootUEFIのドキュメントにあります。

ここも正直に書きます。本件のハッシュはまだ失効リストに入っていないので、これらのコマンドで「本件は対策済み」と表示されることは、現状ありえません。3つ目のコマンドで見えるdbxに、本件の12バイナリは載っていません。分かるのは、2つ目のコマンドで自分のパソコンがどのメーカーの証明書を信頼しているかだけです。そこにAcerやToshibaの証明書があるなら、そのメーカーの署名が付いたバイナリは自分の機体で通る、という意味になります。

セキュアブートを無効にしている場合は、失効リストそのものが評価されません。ただし本件はセキュアブートを迂回する脆弱性ですから、無効にした時点ですでに守られていない状態です。心配なら、まず有効に戻すところからになります。

なぜ署名済みの正規ソフトが穴になるのか

セキュアブートの安全性は「署名された正規ソフトは安全だ」という前提に支えられています。ところが、その正規ソフト自身が危険な操作を許してしまうと、攻撃者は新しい不正ソフトを作らずに、お墨付きのある部品を踏み台にして門を通れます。今回のように、保守用のUEFIシェルにメモリやNVRAMを直接いじるコマンドが残っていると、それがそのまま「合法的に通れる抜け道」になってしまうわけです。

この「信頼の連鎖のどこか1か所が崩れると全体が崩れる」構図は、近年のセキュリティで繰り返し問われているテーマです。ただし今回の事案が示したのは、それだけではありません。崩れた1か所を撤回する手段が、署名を出した側にしか用意されていないという点です。撤回の主体がいない署名は、公表されたあとも有効なまま残ります。失効リストの容量が尽きかけていることも重なって、「危険と分かっているのに名簿に載らないもの」が積み上がっていきます。

JVNだけを見ていると、情報が古くなります

今回の取材で気づいた実務的な話を書いておきます。日本語で読めるJVNVU#93024090は、2026年6月19日に公開されたあと、最終更新も6月19日のままです。更新履歴もありません。中身はCERT/CCへ転送するだけの内容で、対象製品も対策もJVN上には書かれていません。

一方、本家のCERT/CC VU#457458は、2026年6月23日にRevision 2へ改訂されています。JVNだけを見ている限り、この改訂には気づけません。JPCERT/CC単独の注意喚起や、IPAの重要なセキュリティ情報も確認されていません。国内報道はScanNetSecurityが2026年6月22日に出した記事のみで、内容はJVNの紹介にとどまります。

JVNは翻訳と転送を担う窓口であって、一次情報そのものではありません。気になる案件を追うときは、JVNのページからリンクされている本家（CERT/CCやベンダーのアドバイザリ）まで開いて、改訂番号と日付を見てください。本件のように、本家だけが更新されていることがあります。

よくある質問

Q. ASUSのパソコンを使っています。危ないのでしょうか？

A. 対象ではありません。ASUSTeK Computer Inc. はCERT/CCの一覧で「Not Affected（影響なし）」と回答しています。影響を受ける12件のうちASUSの名前が付くのは「ASUS schenker-tech.de(XMG)」の1件だけで、これはドイツのXMG／Schenker系OEM向けの署名です。この記事は公開当初、この署名名を見てASUSを対象に含めていました。誤りでしたので訂正します。

Q. 「東芝」とありますが、dynabookのパソコンは対象ですか？

A. 影響を受けるバイナリの署名元はToshiba Corporation名義で、国内でPC事業を担うDynabook株式会社ではありません。Dynabookのサポートサイトに本件への言及はありません。同社が2026年2月17日付で出しているセキュアブート証明書の期限切れに関する告知は、本件とは別の話です。

Q. Windows Updateを当てれば直りますか？

A. 本件については直りません。危険なソフトを締め出すDBX（無効化リスト）に、本件の12バイナリは登録されていないためです。Windows Updateを当てる意味はありますが、それは証明書の期限切れ対応と、別件であるshimの失効を取り込むためです。本件の備えとしては、BIOS管理者パスワードの設定と、外部デバイスからの起動の無効化が現実的です。

Q. ネットを見ているだけで突然乗っ取られますか？

A. いいえ。今回の弱点は、攻撃者が先に管理者権限を握るか、端末を直接操作できることが前提で、しかもその署名元の証明書を信頼している機体でしか成立しません。何もしていない人がネット越しに一発で乗っ取られるものではありません。実際に悪用されたという報告も確認されていません。

Q. すでにブートキットを仕込まれていないか心配です。

A. 一般利用者が自力で確実に確認するのは困難です。動作が不審で心配な場合は、メーカーや専門業者に相談してください。企業では、端末の調達・廃棄時の管理やディスク暗号化、管理者権限の絞り込みが予防に有効です。

まとめ

JVNVU#93024090は、Acer・GIGABYTE・東芝（Toshiba Corporation）ほかが署名して配っていたUEFIアプリ12件に、起動時の安全装置セキュアブートをすり抜けられる弱点が見つかった事案です。公開時にこの記事が対象として並べていたASUSは、実際には「影響なし」と回答しており、ASUS名義の1件はXMG／Schenker系OEM向けの署名でした。訂正します。

公表から2ヶ月経って見えてきたのは、被害の大きさよりも、直し方の側にある行き詰まりです。Microsoftの失効リストに本件のハッシュは1件も入っておらず、リスト自体が容量の限界に達していることをMicrosoft自身が認めています。同じ研究者が報告したshimの11件は4月に失効しました。違いは弱点の中身ではなく、Microsoftの認証局で署名されていたか、各メーカー自身の証明書で署名されていたかです。誰が署名したかで、直るものと直らないものが分かれます。

利用者の側でできることははっきりしています。Windows Updateは当てる（本件のためではありませんが、当てる理由はあります）。GIGABYTE利用者は古いBIOS配布物を手元から消す。そして全員に効くのは、BIOSの管理者パスワードと、外部デバイスからの起動の無効化です。物理アクセスを前提とする攻撃には、物理的な入口を閉じる設定がいちばん効きます。悪用の報告は確認されておらず、KEVにも載っていません。慌てる必要はありません。

更新履歴

参照元

• ▸ JVN - JVNVU#93024090 Vendor-signed UEFIアプリケーションにおけるセキュアブートバイパスの脆弱性（2026年6月19日公開・同日最終更新）
• ▸ CERT/CC - VU#457458（2026年6月23日 Revision 2）
• ▸ Microsoft - secureboot_objects（失効リストの原本を公開しているリポジトリ）
• ▸ Microsoft - dbx_info_msft_latest.json（全673エントリ）
• ▸ Microsoft - secureboot_objects Issue #447（DBXの容量問題、2026年7月10日起票）
• ▸ CERT/CC - VU#616257（shim / CVE-2026-8863。2026年4月9日にDBXへ登録された別件）
• ▸ Microsoft - Windows Secure Boot の証明書とCA更新について
• ▸ CISA - Known Exploited Vulnerabilities Catalog（2026年8月14日版・1,665件で照合）
• ▸ ScanNetSecurity - 複数のベンダーが署名したUEFIアプリケーションにセキュアブート回避の脆弱性（2026年6月22日）