社内システムへのアクセスを「会社が管理している端末かどうか」で制御している会社は多い。その判定の土台に、今回の話は届く。
CERT/CCは2026年8月11日、Vulnerability Note VU#431093 を公開した（最終改訂は8月12日）。Trusted Platform Module（TPM）2.0のリファレンス実装に2件の脆弱性が確認されたという内容である。国内では、JVNが2026年8月12日に JVNVU#96623328 として掲載している。
2件の内容は次のとおりである。
- CVE-2026-6726：偽造されたTPM鍵を介した情報漏えい
- CVE-2026-6727：RSA OAEP復号処理におけるタイミングサイドチャネルの脆弱性
先に結論を書く。この件は「今すぐ全社が緊急対応すべき案件」ではない。攻撃の成立には、TPMのコマンドインタフェースへの特権的なローカルアクセスが必要である。しかし、自社のアクセス制御が何を根拠にしているかを点検する材料としては、かなり良い。
この記事を読むべき人
- 社内システムへのアクセスを「会社支給の端末かどうか」で制御している会社
- ゼロトラストの導入を検討中、または導入したばかりの会社
- 端末をリースやレンタルで調達していて、ファームウェア更新の責任範囲を確認していない会社
- 仮想環境やクラウド上のサーバーでTPM相当の機能を使っている会社
- PCの調達と管理を、総務や現場任せにしている会社
SECURITY OPERATION
日常の脆弱性運用、情シス1人で回せる体制にしませんか？
月次棚卸・重大度判定・パッチ適用代行まで含む「セキュリティ運用伴走」プラン。単発対応からの卒業で、止まらない運用体制を作ります。
何が起きるのか
CERT/CCの記載に沿って整理する。
CVE-2026-6727 は、RSA OAEP復号の実装に存在するタイミングサイドチャネルである。TPMのコマンドインタフェースにアクセスできる特権的なローカルの攻撃者が、処理時間の差を利用して情報を復元し、TPMが管理するRSA鍵（RSA Endorsement Key、EKを含む）で暗号化された暗号文を復号できる可能性があるとされている。対象にはインポートブロブ、クレデンシャルブロブ、セッションソルトが含まれる。一定の条件下では、TPM 2.0のアテステーション（構成証明）の偽造も可能になり得るとされている。
CVE-2026-6726 は情報漏えいの脆弱性である。特権的なローカルの攻撃者が、偽造したTPM鍵について、TPMを認識する認証局（CA）からクレデンシャルを取得できる可能性があるとされている。対象となる鍵の例として、Attestation Key（AK）、DevID鍵、TLS認証鍵が挙げられている。これにより、偽造した鍵を用いた不正なTPM 2.0アテステーションを作り出せる可能性がある。
両方の脆弱性に共通する前提は、TPMのコマンドインタフェースへの特権的なアクセスである。遠隔から認証なしに突かれる類のものではない。
影響として挙げられているのは3点である。TPMが管理するRSA鍵で暗号化された暗号文の復号、偽造したTPM鍵のクレデンシャルの取得、そして正規のTPMから発行されたように見える不正なTPM 2.0アテステーションの作成である。CERT/CCは、全体的な影響は対象となるTPMの実装と、プラットフォームがTPMベースのアテステーションと鍵管理をどのように使っているかに依存する、としている。
経営判断に効くのは3つ目の影響
技術的な詳細より、3つ目に挙げられた「正規のTPMから発行されたように見えるアテステーションの偽造」が何を意味するかを押さえたい。
多くの会社が、次のような制御を導入している。「会社が管理している端末からのアクセスだけを許可する」。この判定の根拠として、端末に組み込まれたTPMが「この端末は改ざんされていない正規の構成である」と証明する仕組みが使われることがある。
その証明が偽造できるということは、「会社の端末である」という判定そのものが揺らぐということである。
ここで確認したいのは、自社のアクセス制御が、この判定にどれだけ依存しているかである。
- 端末の正当性の判定だけで社内システムへの到達を許可しているか
- それとも、利用者の認証、多要素認証、ネットワークの位置、利用時間帯など、複数の条件を組み合わせているか
前者に近い設計であれば、判定の根拠が1つ崩れたときに全部が崩れる。後者であれば、1つが崩れても他の条件が残る。
今回の件を、この設計を見直す機会として使うのが最も実益がある。特権的なローカルアクセスが必要という前提があるため、緊急性は高くない。しかし「デバイスの正当性を、単一の根拠として信頼していないか」という問いは、今回とは無関係にいつか答えが必要になる。
誰がファームウェアを更新するのか
CERT/CCは、脆弱性はTPM 2.0のリファレンス実装に由来しており、TPMベンダーが更新されたファームウェアおよびソフトウェアのリリースに修正を取り込んでいるとしている。利用者は、プラットフォームまたはTPMのベンダーが提供するTPMファームウェアの更新、OSの更新、ソフトウェアのパッチを適用すべきである、と。
ここが実務上いちばん引っかかるところである。
ベンダー情報として、AMDは自社がfTPMを製造しており、2件とも影響を受ける（Affected）と自ら表明している。Intelについては、CERT/CC上のステータスが2件ともAffectedである一方、ベンダー声明は「未受領」と記載されている。この2つは同じ「Affected」でも根拠が違うため、区別して扱いたい。一方、Absolute Softwareは「自社製品は影響を受けるTPM 2.0のリファレンス実装に依存していないため影響を受けない」と自ら表明している。Ampere Computingのように、CERT/CC上は影響を受けない（Not Affected）と表示されているが、ベンダー声明は未受領とされている事業者もある。つまり一覧の「Affected」「Not Affected」には、ベンダー自身が述べたものと、そうでないものが混在している。なお、この脆弱性を報告したのはIntelの研究者4名である。
注意したいのは、更新の届き方が端末やメーカーによって異なる点である。CERT/CCも、TPMファームウェアの更新、OSの更新、ソフトウェアのパッチのいずれもあり得る書き方をしている。Windows Update経由でファームウェアが配布される機種もあれば、メーカー独自の更新ツールやサポートサイトからの個別適用が必要な機種もある。
つまり、自社の端末でどの経路になるかを確認しないと、「更新済みのつもり」で漏れる。次の3点を確認したい。
確認1：自社の端末のファームウェア更新は、誰がどの頻度で実施しているか。「実施していない」が答えである会社は珍しくない。それ自体は今回の件に限らず、リスクの所在として把握しておくべきである。
確認2：リースやレンタルで調達している端末の場合、ファームウェア更新は契約上どちらの責任か。契約書に書かれていない場合、実質的に誰も実施していない状態になりやすい。
確認3：クラウドや仮想環境でソフトウェア実装のTPMを使っている場合、事業者側で更新が済んでいるか。CERT/CCは、ソフトウェアベースのTPM実装を使用しているクラウド事業者も更新を展開している可能性があり、追加の対応が必要かどうかは事業者の案内を確認すべきとしている。
自社が該当するかを確かめる順序
CERT/CCは、全体的な影響は対象となるTPMの実装と、プラットフォームがTPMベースのアテステーションと鍵管理をどのように使っているかに依存するとしている。つまり、CPUのメーカー名だけでは該当判定が終わらない。
確認は次の順序で進めるのが実務的である。
- 端末の型番を特定する。判定に必要なのはCPUのメーカーではなく、その端末を出しているメーカーと型番である。fTPMを使っているか、独立したTPMチップを載せているかは機種によって異なる。
- 端末メーカーのセキュリティ情報を確認する。CERT/CCのベンダー一覧に載っているのは主に部品やプラットフォームの提供元であり、実際に更新を配布するのは端末メーカーであることが多い。
- 現在のTPMファームウェアの版数と、UEFI／BIOSの版数を控える。更新の要否は、この2つの版数で判断されることが多い。
- 仮想環境やクラウドで動かしているサーバーがあれば、事業者の案内を確認する。ソフトウェア実装のTPMを使っている場合、更新は事業者側で行われている可能性がある。
1と3が社内で分からない場合、それは今回の件より先に手を打つべき課題である。端末の型番とファームウェアの版数を把握していない状態では、今後どのファームウェア関連の脆弱性が出ても、毎回同じ調査から始めることになる。
この件で慌てるべきでない理由も、はっきり書いておく
攻撃の成立には特権的なローカルアクセスが必要である。言い換えれば、攻撃者が既に対象の端末で特権を取得している状態が出発点になる。
その状態に至っている時点で、既に別の深刻な問題が起きている。したがって、この脆弱性を単独で最優先の課題として扱う必要は、多くの会社にとってはない。
ただし、次の2つに当てはまる場合は優先度が上がる。
共用端末で、利用者に管理者権限を与えている場合。あるいは、UEFI／BIOSの設定にパスワードがかかっておらず、外部媒体からの起動を制限していない端末を運用している場合。物理的に触れられること自体より、そこから管理者権限に到達できるかどうかが問題になる。
TPMのアテステーションを、取引先や外部サービスに対する「正当な端末である」ことの証明として使っている場合。偽造されたアテステーションが外部に通用する構図になるため、影響が自社内で完結しない。
よくある質問
Q. 自社のPCにTPMが入っているかは、どう確認すればよいか。 A. Windowsであれば、管理者がシステム情報やデバイスマネージャーから確認できる。近年のビジネス向けPCはTPM 2.0を搭載しているのが一般的だが、搭載していることと、それを認証の根拠に使っていることは別である。確認すべきは後者のほうである。
Q. BitLockerなどのディスク暗号化を使っている。これは危険なのか。 A. CERT/CCの記載は、TPMが管理するRSA鍵で暗号化された暗号文の復号、および偽造されたTPM鍵によるアテステーションに関するものである。個別の製品や機能への影響は、その製品がTPMをどう使っているかによる。利用している製品のベンダーが公表する情報を確認してほしい。本稿は個別製品への影響を断定しない。
Q. ファームウェア更新は業務を止めるのか。 A. 一般に再起動を伴う。台数が多い場合は計画的に進める必要があるため、緊急性が高くない今回のような案件は、定例のメンテナンス時期に合わせるのが現実的である。
Q. TPMの更新をしたことがない。今から全台やるべきか。 A. まず、自社が何をTPMに依存させているかを確認するほうが先である。依存していない場合、更新の優先度は他のパッチと同等で構わない。依存している場合は、対象を絞って先に実施する判断ができる。
Q. 端末の入れ替え時期が近い。更新せずに入れ替えを待ってよいか。 A. 選択肢としてはあり得る。ただし、入れ替えまでの期間と、その端末が何にアクセスできるかを踏まえて判断したい。入れ替えが半年以上先で、その端末が基幹システムに到達できるなら、待つ判断には根拠が要る。
Q. ベンダーの一覧に自社の端末メーカーが載っていない。 A. CERT/CCのベンダー情報には、影響あり・影響なし・不明の区分がある。載っていない、または不明とされている場合は、メーカーのサポート窓口に直接確認するのが確実である。
デバイスを信頼の根拠にしている設計を点検したいとき
今回の件で本当に問うべきは、TPMのファームウェアが最新かどうかではない。「端末が正規である」という判定に、どれだけ体重を預けているかである。
アクセス制御の条件が単一の根拠に依存していないかを点検したい場合はセキュリティ診断で対応している。端末の台帳とファームウェアを含む更新の運用を整理したい場合はDX・システム開発、端末のファームウェアまで含めた更新運用を社外に預ける形を検討するならセキュリティリタイナーが該当する。リース契約で更新責任がどちらにあるか判断がつかない場合は、端末の保守範囲を相談するから確認できる。
端末の管理と識別、ログ設計の考え方はデバイス・ID・ログの設計、資産台帳そのものの整備はIT資産管理の進め方で扱っている。本稿は、デバイスの正当性を信頼の根拠にしている場合の点検に絞っている。
参照した情報
- CERT/CC Vulnerability Note VU#431093「TCG TPM 2.0 reference code found vulnerable to information leakage and timing side-channel attacks」（2026年8月11日公開、8月12日改訂）: https://kb.cert.org/vuls/id/431093
- JVN JVNVU#96623328「TCG TPM2.0のリファレンス実装における複数の脆弱性（CVE-2026-6726、CVE-2026-6727）」（2026年8月12日公開）: https://jvn.jp/vu/JVNVU96623328/
CVE-2026-6726およびCVE-2026-6727の内容、攻撃に特権的なローカルアクセスが必要である旨、影響として挙げられた3点、対象にRSA Endorsement Key（EK）、インポートブロブ、クレデンシャルブロブ、セッションソルトが含まれる旨、偽造される鍵の例としてAttestation Key（AK）、DevID鍵、TLS認証鍵が挙げられている旨、TPMベンダーが更新に修正を取り込んでいる旨、クラウド事業者の案内を確認すべき旨、AMDが自ら影響を受けると表明している旨、IntelがAffectedと表示される一方でベンダー声明が未受領である旨、Absolute Softwareが影響を受けない旨を自ら表明している一方でAmpere ComputingはNot Affectedと表示されつつベンダー声明が未受領である旨、およびIntelの研究者による報告である旨は、上記CERT/CCのVulnerability Noteを取得して確認した。
JVNの掲載日および掲載内容が「CERT/CCのアドバイザリを参照してください」とする案内であることは、上記JVNのページで確認した。なお、Trusted Computing Group（TCG）のアドバイザリ TCGVRT010 および TCGVRT0011 の内容については、本稿では確認していない。
「デバイスの正当性を単一の根拠として信頼していないか」という点検の考え方、ファームウェア更新に関する3つの確認、優先度が上がる2つの条件、および慌てるべきでない理由の整理は、端末管理の現場からGXOが組み立てた点検の視点であって、CERT/CCおよびJVNの基準ではない。個別の製品（ディスク暗号化機能など）への影響、および具体的な更新手順は、機器や製品によって異なるため本稿では扱っていない。攻撃の技術的詳細および悪用の観測状況についても扱っていない。
