タグ: セキュリティ

投稿日:

HTTP2Shellとは ―Node.jsやPythonに広がるBrotli脆弱性の影響と対策

Share
HTTP2Shell（CVE-2026-111497）とは？影響製品と対策を解説アイキャッチ画像

WebサイトやAPIの安全性を確認する際は、外部からのリクエストだけでなく、アプリケーションが受信するレスポンスにも注意が必要です。HTTP2Shell（CVE-2026-111497）は、GoogleのBrotliデコーダーに存在する脆弱性で、細工された圧縮データの展開によって、情報漏洩や任意コード実行につながるおそれがあります。Node2Shellとも呼ばれるこの問題は、Node.jsに加え、Python関連パッケージやBun、Envoyなど幅広い製品に影響します。本記事では、主な攻撃経路、影響を受ける製品、修正版と対策を解説します。

HTTP2ShellとNode2Shellの関係

Brotliは、Webコンテンツなどのデータを小さくするために使われる圧縮方式です。HTTP通信では、本文がBrotli形式で圧縮されていることをContent-Encoding: brというヘッダーで示します。本脆弱性は、当初Node.jsへの影響が注目されたことから「Node2Shell」と呼ばれていました*1。その後、Brotliを利用する複数の製品にも影響が及ぶことが明らかになり、「HTTP2Shell」という呼称も使われるようになりました。なお、名称にHTTPが含まれていますが、HTTP/2通信に限定された脆弱性ではありません。

問題があるのは、圧縮されたデータを元に戻すデコーダーです。不正なデータの処理を打ち切るべき場面で処理が続き、内部バッファの範囲を超えて書き込むことがあります。結果として、プロセスの停止やメモリ内の情報漏洩、条件によっては遠隔からの任意コード実行（RCE）につながります。

Googleが登録したCVEレコードの評価はCVSS v4.0で9.2、深刻度はCriticalです。一方、Node.jsの公式告知ではHighに分類されています*2。確認すべきなのは、脆弱なBrotliデコーダーを使用し、攻撃者が用意したデータがそこに届くかどうかです。

HTTPリクエストとレスポンスの両方が攻撃経路になる

受信側では、WebアプリケーションがBrotli圧縮されたリクエスト本文を展開する経路が問題になります。Impervaは、Express 5やbody-parser 2系でBrotli圧縮された本文を展開する構成で、細工したデータがNode.jsに内包されるデコーダーへ渡るケースを検証しています*3。⁠

もう一つは、アプリケーションがHTTPクライアントとして通信する経路です。Node.jsの組み込みfetchがBrotli圧縮された応答を展開すると、接続先のサーバーが返したデータがデコーダーに届きます。公開APIへの入力対策とあわせて、外部サイトから情報を取得する機能にも目を向ける必要があります。

図1：HTTP2Shellで確認する二つの攻撃経路

脆弱なBrotliデコーダーに細工されたデータが届く二つの攻撃経路を示した概念図
出典：Imperva, Inc.、Bunプロジェクトの公開情報をもとに作成。
※任意コード実行の成立条件は製品や構成によって異なります。

影響を受ける製品と修正版

影響調査では、開発言語の名前だけで範囲を区切らないことが大切です。Pythonの場合は、Python本体全体の問題として扱うのではなく、Brotliやbrotlicffiといったパッケージの導入状況を調べます。urllib3やrequestsなどは、これらのパッケージが利用できる環境でBrotli応答を自動展開するため、アプリケーションのコードにBrotliの呼び出しが見当たらなくても確認が必要です。

表1：主要コンポーネントの修正版と確認する条件

コンポーネント修正版確認する条件
Google Brotli1.0.10／1.1.1／1.2.11.0.3～1.0.9、1.1.0、1.2.0
Node.js22.23.4／24.22.1／26.12.1各系列の未修正版。内包するデコーダーの利用経路を確認
Python関連パッケージBrotli 1.2.1
brotlicffi 1.2.1.0		仮想環境やコンテナーごとの導入状況を確認
Bun1.4.41.0.21以上1.4.4未満。コンパイル済み実行ファイルも確認
Envoy1.40.0／1.39.3／1.38.6／1.37.8／1.36.12Brotli展開フィルターを設定した環境
Istio1.31.2／1.30.6／1.29.9Brotli展開を有効にした環境。1.29系はサポート終了
出典：Google LLC、Node.jsプロジェクト、GitHub Advisory Database、Bunプロジェクト、Envoy Proxyプロジェクト、Istioプロジェクトをもとに作成。
※主要コンポーネントの修正版と確認条件を整理しています。バージョン番号は各開発元の公表値です。影響製品を網羅したものではなく、利用環境に応じて各製品の公式情報を確認してください。

EnvoyではBrotliの展開フィルターを設定した環境、IstioではEnvoyFilterなどを使ってBrotli展開を有効にした環境が確認対象です。製品名が一致するだけで、すべての構成が同じ攻撃経路を持つとは限りません。反対に、別製品に内包されたライブラリは、アプリケーションの依存パッケージ一覧だけでは見落とすおそれがあります。

コード実行の実証と実際の攻撃を分けて読む

Impervaは、公式のNode.js 24.22.0のLinux arm64イメージを用いた実験で、細工したBrotliデータによるコード実行を報告しています。修正版の24.22.1では同じ入力が拒否されました。ただし、実験環境では成功まで複数回の試行を要しています。この結果を、すべてのOSや構成で同じ攻撃が成立するという意味に広げることはできません。

また、研究環境での実証は、実際の組織に対する攻撃成功の報告とは別です。CVEレコードに収録されたCISAの評価では、2026年10月23日時点のExploitation（悪用状況）が「none」とされています。ただし、これは評価時点の情報であり、その後の悪用の有無を保証するものではありません。修正の優先順位は、被害報告の有無だけでなく、自社環境で攻撃者が用意したデータが脆弱な展開処理へ届くかどうかを踏まえて判断する必要があります。

Go向けBrotli実装にも関連する報告があります。Sweet Securityはv1.2.6でpanicと接続切断を再現しましたが、その実験ではアプリケーション全体は動作を続けていました。Go実装で任意コード実行やプロセス全体の停止が実証されたわけではありません*4。メンテナーは10月23日に修正コミット33c2a98による対応を報告しています*5。

更新する対象を実行環境まで追う

Node.jsを使う環境では、Brotliを内包するNode.jsランタイムそのものを更新する必要があります。Pythonでは仮想環境ごとにパッケージを確認し、コンテナーを使っている場合は、更新後の構成でイメージを再ビルドして再配置します。管理画面に表示された設定値だけでなく、稼働中のプロセスに修正が反映されていることまで確認します。

Bunでは、bun build –compileで作成した実行ファイルにランタイムが埋め込まれます。開発端末のBunを更新しても、すでに配布した実行ファイルは自動では直りません。公式告知はBun 1.4.4への更新と、該当する実行ファイルの再ビルドを求めています*6。製品に組み込まれたBrotliを修正するには、製品側の更新が必要になる点に注意してください。

図2：影響確認から修正の反映までの流れ

影響確認から修正版の適用までの対応を整理した概念図
出典：Node.jsプロジェクト、Aikido Security BV、Bunプロジェクト、Envoy Proxyプロジェクトの公開情報をもとに作成。
※暫定対策は修正版への更新を代替するものではありません。

更新までの暫定対策では展開前に止める

すぐに更新できない場合は、脆弱なデコーダーにBrotli圧縮データが渡らないようにすることが暫定対策となります。受信リクエストでは、Brotli形式の本文を展開する前に拒否する方法があります。外部サイトからのレスポンスについても、Brotli展開を無効にするか、展開前に拒否できるかを確認します。送信するAccept-Encodingからbrを削除するだけでは、接続先がBrotli圧縮されたレスポンスを返す可能性を排除できません。

回避策の設定方法は製品によって異なります。Bunの公式告知では、fetchの呼び出しにdecompress: falseを指定する方法が示されていますが、その呼び出しだけに適用される設定です。ほかのBrotli展開処理まで一括して無効になるわけではありません。回避策の対象範囲を確認したうえで修正版へ更新してください。

HTTP2Shellへの対応では、公開Webサーバーの点検に加え、外部と通信するアプリケーションや製品内の依存ライブラリまで確認を進めます。Brotliを含む実行環境を洗い出し、攻撃者のデータが届く経路を確認したうえで、稼働中のプロセスに修正が反映されたことまで確かめてください。外部から細工されたBrotliデータを受信・展開する可能性があった環境では、修正版の適用に加え、不審なプロセスの異常終了や関連ログなどを確認し、侵害の兆候がないか調査することも重要です。

Webアプリケーションのセキュリティ対策を見直しませんか？

公開WebサイトやAPIの安全性を維持するには、利用するソフトウェアの更新に加え、アプリケーション全体の脆弱性を継続的に確認することが重要です。ブロードバンドセキュリティ（BBSec）では、Webアプリケーションの脆弱性診断を通じて、企業のセキュリティ対策を支援しています。

SQATWebアプリケーション脆弱性診断サービスページバナーリンク

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

お名前.com デスクトップクラウドに不正アクセス ―情報流出の影響・補償内容と利用者の対応

Share
お名前.com デスクトップクラウドに不正アクセス ―情報流出の影響・補償内容と利用者の対応アイキャッチ画像

GMOインターネット株式会社は2026年10月24日、「お名前.com デスクトップクラウド」への不正アクセスに関する続報を公表し、情報流出への対応や不正取引による損失の補償方針を明らかにしました。全プランの停止に加え、利用者には取引口座の認証情報や取引履歴の確認が求められています。今回の事案では、今回の事案では、クラウド環境に保存された認証情報と、接続先の取引口座の確認が欠かせません。本記事では公式発表を基に判明した事実と利用者・企業が取るべき対応を整理します。

※本記事は2026年10月26日時点で公表されている情報を基に作成しています。

問い合わせから調査が始まり全プランの停止へ

調査のきっかけは10月19日の利用者からの問い合わせでした。翌20日に一部サーバーで不正なプログラムが見つかり、新規申し込みの受け付けとコントロールパネルが停止されました。19日は公表された調査開始日であり、攻撃が始まった日を示すものではありません。21日午前4時からは全プランのサーバーが順次停止されました。

初報では個人情報の流出や悪用は確認されていないと説明されていました*7が、その後、21日以降に利用者から身に覚えのない取引などの報告が寄せられました。第2報によると、同社は22日に警察へ相談しています*2。古い発表だけで安全性を判断せず、更新後の内容まで確認する必要があります。

影響の可能性があるサーバー数と確定被害を区別する

公表された26,739件は、影響を受ける可能性があるサーバーの数です。すべてのサーバーへの侵入や情報流出が確認されたわけではなく、被害を受けた利用者の人数を示す数字でもありません。その後の発表では、利用者情報の外部流出が確認され、不正取引による損失の補償方針も示されました。一部の利用者からは身に覚えのない取引の報告も寄せられています。ただし、個々の利用者の被害状況や不正取引と本件との因果関係については、引き続き確認が必要です。

また、同社が決済情報をサービスのサーバーに保持していないことと、利用者自身が保存した認証情報の安全性は別の問題です。取引ツールやブラウザに保存した情報も確認対象となります。利用者のパソコンなどへの影響についても調査中であり、端末への感染が一律に確認されたわけではありません。

図1：お名前.com デスクトップクラウドの公表内容と対応の経緯

お名前.com デスクトップクラウドの公表内容と対応の経緯
出典：GMOインターネット株式会社「お名前.com デスクトップクラウドへの不正アクセスに関するお詫びとお知らせ（第3報）」「お客様へのお見舞金のお支払いと不正取引による損失の補償について（第4報）」、GMOインターネットグループ株式会社・GMOインターネット株式会社「不正アクセスに関するお詫びとお知らせ（第2報）」、熊谷正寿氏の公式ブログ「今こそ官民連携で日本を守ろう――『能動的サイバー防御』を具申した理由」を基に作成。
※各資料に記載された出来事の日付と公表日を整理したもので、攻撃の開始日を示す図ではありません。

パスワード変更と全セッションの切断を進める

利用者は、取引口座などのパスワードを変更するとともに、認証済みの全セッションを切断する必要があります。同社は、FX取引に使用していないスマートフォンや別のパソコンから変更するよう案内しています。すでにパスワードを変更した場合も、セッションの切断が必要です。パスワードを変更しても、すでに成立している接続が終了するとは限りません。また、遠隔デスクトップの画面を閉じただけでは、取引口座への接続がすべて終了したとは判断できません。切断方法が分からない場合は、利用している金融事業者に確認してください。

図2：利用者が優先すべき3つの対応

認証情報の変更、全セッションの切断、取引履歴・残高の確認という、目的の異なる3つの対応を整理
出典：GMOインターネット株式会社「お名前.com デスクトップクラウドへの不正アクセスに関するお詫びとお知らせ（第3報）」「『お名前.com デスクトップクラウド』ご利用のお客様へ改めてのお願い（第5報）」を基に作成。

口座の履歴と端末を確認し不審な連絡に応じない

第5報は、口座の履歴と残高を確認し、身に覚えのない取引があれば金融事業者に連絡するよう求めています*3。提供されている場合は二要素認証を設定し、保存済みの認証情報や使い回していたパスワードも見直す必要があります。口座ごとに確認した日時と結果を整理し、異常があれば取引日時や内容を確認できる記録を確保しておきましょう。

パソコンやスマートフォンのフルスキャン、データのバックアップも案内されています。これは二次被害を防ぐための予防的な対応です。バックアップしたファイルの取り扱いにも注意が求められています。攻撃者を名乗る連絡には返信せず、届いたURLやファイルを開かないようにしてください。

FX自動売買の停止後は注文・保有ポジションも確認する

「お名前.com デスクトップクラウド」は、MT4・MT5を用いたFX自動売買向けの仮想専用サーバー（VPS）サービスです。手元のパソコンを起動し続けなくても、クラウド上で取引ツールや自動売買プログラム（EA）を稼働させられます。

VPSの停止により、そこで稼働していたEAも動作を継続できなくなります。ただし、取引業者側に登録済みの注文と、VPS上で実行される処理は区別する必要があります。例えばMetaTrader 4では、トレーリングストップの追随処理は取引端末側で動作するため、端末が停止すると更新も止まります。一方、すでに設定されたストップロスは取引サーバー側で処理されます。[10]利用者は、取引業者の公式画面から注文・保有ポジション・取引履歴を確認し、必要に応じて金融事業者に相談してください。

見舞金と損失補償 代替サービスの条件を確認する

見舞金は発表時点の全利用者に5,000円で、損失補償とは別枠です。補償対象は、同社が本件に起因すると認めた不正取引の実現損失で、市場変動による損失、逸失利益、間接損害は含まれません。現行基盤をそのまま再開せず、契約中で継続利用を希望する利用者には、独立した基盤の代替サービスを案内する方針です。乗り換え後6か月無料で、同意のない移行は行わないとしています。見舞金の手続き・支払時期や代替サービスの開始時期などは10月30日23時59分まで、損失補償の申請方法や支払時期などは11月6日までに案内予定です。

これらは案内期限であり、支払日やサービス開始日ではありません。補償手続きの詳細は公式案内をご確認ください。調査で閲覧専用パスワード等を求める例外がありますが、通常のパスワードや暗証番号は求めないとしています。

事前に指摘されていたセキュリティ対策上の課題

GMOインターネットグループ代表の熊谷正寿氏は10月25日の公式ブログで、社内のセキュリティ専門家から事前に改善課題が指摘され、現場でも対応が進められていたと説明しました*4。一方、サービスの可用性への影響や他案件との優先順位などから、必要な対策を十分かつ迅速に実施できなかったとしています。この説明は、技術的な侵入経路の特定とは別に、セキュリティ上のリスクを把握した後の対応判断や、対策の優先順位付けという組織的な課題を示すものです。

企業は認証情報とログの所在を把握する

企業が外部のクラウドサービスを利用する際は、どの部署が、どの業務で利用し、どのような情報や認証情報を保存しているかを把握しておくことが重要です。サービス名や契約担当者だけでなく、利用アカウントや接続先まで整理することで、インシデント発生時に確認すべき範囲を特定しやすくなります。

IPAは2026年10月9日に出した注意喚起「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」で、部署単位で利用する外部サービスも含めた把握と、ログやアカウントの異常確認を求めています。企業は、ログの保存期間や事業者・利用者それぞれが確認できる範囲を把握し、不審なログインやアカウント変更などの異常を確認できる体制を整えておく必要があります。

クラウドの停止を前提に業務継続の手順を整える

クラウドサービスが停止した場合、企業は影響を受ける業務と、停止中も継続できる業務を把握する必要があります。復旧を待つだけでなく、代替環境への移行や一時的な業務停止について、あらかじめ判断基準と対応手順を定めておくことが重要です。IPAの「中小企業のためのクラウドサービス安全利用の手引き」では、サービス停止時の業務への影響、サービス水準、データの保管・取り出し、サポート体制などの確認を促しています。バックアップの有無だけでなく、必要なデータや設定を取り出し、代替環境で利用できるかを確認しておくことが、業務継続に向けた備えとなります。

調査と業務復旧の判断を専門家と進める

クラウドサービスや端末への侵害が疑われる場合、被害範囲の特定や証拠保全を進めながら、業務復旧に向けた対応を検討する必要があります。ブロードバンドセキュリティ（BBSec）では、デジタルフォレンジック調査を通じて、インシデントの原因や影響範囲の調査、証拠保全、再発防止に向けた支援を提供しています。不正アクセスや情報漏洩が懸念される場合は、確認済みの事実や対象システム、取得可能なログを整理したうえでご相談ください。

BBSec緊急対応支援サービスページリンクバナー

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

Apache Tomcatに8件の脆弱性 ―認証回避と情報漏洩の条件と対策

Share
Apache Tomcatに8件の脆弱性 ―認証回避と情報漏洩の条件と対策アイキャッチ画像

Apache Tomcatに、認証回避や利用者間のデータ混線などを引き起こす計8件の脆弱性が公表されました。対策となるバージョンは、Tomcat 9.0.123、10.1.61、11.0.27です。利用中の系統を確認し、該当する修正版への更新を進める必要があります。今回、特に確認したいのは、認証に使うJNDIRealmの設定、HTTP/2と非同期処理の利用、AJP接続の有無です。影響する機能や条件がそれぞれ異なるため、バージョン情報と実際の構成を照らし合わせることが対応の出発点になります。

修正版の公開は10月12日 脆弱性の詳細公表は10月20日

The Apache Software Foundationは、2026年10月12日に今回の問題を修正したTomcatを公開し、10月20日に脆弱性の詳細を公表しました。国内ではJVNが10月21日に8件のアドバイザリを案内しています。更新プログラムの公開日と、脆弱性情報の公表日には違いがあります。8件は、Tomcat 9、10.1、11の各系統を合わせた件数です。AJPの問題はTomcat 11、APR/Nativeコネクターに関する問題はTomcat 9が対象であり、すべての系統に同じ8件が存在するわけではありません。

図1：Tomcatの系統別修正版

Tomcat 9.0.xは9.0.123、10.1.xは10.1.61、11.0.xは11.0.27で今回の脆弱性を修正
出典：The Apache Software FoundationのTomcat 9・10・11脆弱性情報を基に作成。
影響を受けるバージョンは脆弱性（CVE）ごとに異なります。

認証回避の対象はJNDIRealmの特定設定

CVE-2026-101296は、JNDIRealmでGSSAPI以外のSASL認証方式を使用している場合に、正しいパスワードを提示せず認証を通過できる問題です。JNDIRealmは、Tomcatがディレクトリサービスと連携して利用者を認証するための機能です。今回の確認では、まずこの機能を使用しているかを調べ、使用している場合に認証方式まで確認します。サポート中の系統では、9.0.0.M1～9.0.122、10.1.0-M1～10.1.60、11.0.0-M1～11.0.26が影響範囲です。認証を別の仕組みで実装している場合には、その構成を踏まえて影響を判断します。自社の認証処理がJNDIRealmに依存しているかどうかが確認の分かれ目です。

HTTP/2の非同期処理で別の利用者の情報が漏洩する可能性

CVE-2026-101356は、HTTP/2で非同期Servletを処理する際に、内部オブジェクトが適切に再利用されない問題です。非同期処理中にエラーが発生した後、異なる利用者のリクエストや応答が混在し、別の利用者に情報が漏洩するおそれがあります。影響範囲は、9.0.118～9.0.122、10.1.55～10.1.60、11.0.22～11.0.26です。直近のバージョンも含まれるため、以前に更新したという記録だけでは今回の対策状況を判断できません。実際に稼働しているTomcatのバージョンと、非同期Servletの利用状況を確認する必要があります。

Tomcat 11のAJPで前の応答データが後続の応答に混入

CVE-2026-103119は、WebサーバーとTomcatの連携に使うAJPの処理に関する問題です。大きな非ブロッキング書き込みを行うと、応答本文が同じ接続上の現在のリクエストと次のリクエストに分かれて渡されることがあります。Apacheは、後続リクエストの失敗が起こりやすく、前の応答データが後の応答に漏れる可能性もあると説明しています。対象はTomcat 11.0.0-M25～11.0.26で、11.0.27で修正されています。AJPを使用する構成では、コネクターとアプリケーションの書き込み処理を確認します。

図2：重要な3件で異なる成立条件と影響

JNDIRealmの特定SASL認証による認証回避、HTTP/2非同期処理の混線、AJPの大きな非ブロッキング書き込みによる応答混線の条件と影響を比較
出典：The Apache Software Foundationの脆弱性情報を基に作成。
※各脆弱性の主な成立条件と影響を示したものであり、実際の影響は対象バージョンや利用環境によって異なります。

残る5件も使用機能に応じた確認が必要

今回公表された8件のうち、残る5件はTLS 1.3、HTTP/2、JSP、FIPSモード、APR/Nativeコネクターに関する問題です。それぞれ影響する機能や条件が異なるため、自社の利用環境と照らし合わせて確認する必要があります。

表：その他5件の脆弱性と主な影響

CVE番号主な対象・問題
CVE-2026-93446TLS 1.3接続が断続的に失敗する可能性
CVE-2026-88041HTTP/2のトレーラー情報が後続リクエストに混入
CVE-2026-74049JSTLのリダイレクト後もページ処理が継続
CVE-2026-74048FIPSモードの有効化失敗後も非FIPSモードで動作を継続
CVE-2026-80353APR/NativeコネクターのUnixドメインソケットに権限のないローカル利用者がアクセスできる可能性
出典： The Apache Software Foundation「Apache Tomcat 9・10・11 vulnerabilities」および各CVEのセキュリティアドバイザリを基に作成

深刻度の数値と実際の構成を併せて判断する

ASF独自の評価は、認証回避、HTTP/2の混線、AJPの混線の3件がImportant、残る5件がLowです。CVSSの区分とは異なります。例えばCVE-2026-101356について、Red Hatの公式ページはCVE.orgのCVSS 3.1評価を9.1、自社の評価を5.3と掲載しています。同社は、製品の提供形態やプラットフォームなどによって評価が異なると説明しています。

対応の優先順位を決める際は、こうした評価に加え、自社で問題の機能を使用しているか、誰が対象サービスへアクセスできるかを確認します。該当する認証設定や通信処理を使用している場合は、外部からのアクセス可否や想定される影響を踏まえ、修正版の適用を優先的に検討してください。更新までに時間を要する場合は、脆弱性ごとに有効な緩和策の実施も検討する必要があります。

更新までの緩和策と更新後の確認

今回の基本対策は、利用している系統の修正版への更新です。商用製品などに組み込まれたTomcatを利用している場合は、製品ベンダーに今回のCVEへの対応状況と更新方法を確認してください。Red Hatのように修正を旧版へ取り込む提供元もあるため、パッケージの見かけのバージョンだけで未修正と判断できない場合があります。

Red HatはCVE-2026-101356に対する緩和策として、HTTP/2の利用を停止するための設定変更や、影響を受ける非同期Servletを同期処理へ変更する方法を案内しています。HTTP/2の無効化にあたっては、コネクターの設定や通信方式を確認する必要があります。いずれも個別の問題に対する措置であり、業務への影響を確認したうえで判断する必要があります。

更新後は、稼働中のプロセスが修正版に切り替わったことを確かめ、認証や主要な画面・APIの動作を確認します。複数台で構成している場合は、更新対象を一覧にして適用状況を残すと、対応漏れを確認しやすくなります。緩和策を実施した環境では、更新後に設定を戻すかどうかも含めて管理してください。

Apache Tomcatでは、2025年にもリモートコード実行につながる脆弱性（CVE-2025-24813）が公表されています。今回とは異なる問題ですが、継続的なバージョン管理と適切な設定の重要性を示す事例です。
関連記事：「Apache Tomcatの脆弱性 CVE-2025-24813 ― PoC公開と攻撃事例、必要な対策」

サポート終了版への影響とTomcat 9.0の移行計画

古いTomcatも確認対象です。CVE-2026-101296とCVE-2026-74049について、Apacheはサポート終了済みの8.5.0～8.5.100、7.0.0～7.0.109も影響すると明記しています。さらに、ほかのサポート終了版も影響する可能性があるとしています。現在サポートされている系統の表に載っていないことを、安全性の根拠にはできません。

Tomcat 9.0.xのサポート終了日は2027年3月31日です。一方、Apacheは終了前に9.1.xを提供し、2030年12月31日までリリースを継続する計画を示しています。9.1.xではHTTP・HTTPS・AJP向けのAPR/nativeコネクターが利用できなくなり、Tomcat Native 1.3.xのサポートも終了する予定です。一方、Tomcat Native 2.0.xのサポートは継続されます。現在の脆弱性への更新を進めながら、自社のコネクター構成に合わせて移行準備を進めることが必要です。

BBSecの脆弱性診断でシステム全体の安全性を点検

Apache Tomcatの脆弱性への対応では、修正版の適用に加え、公開サーバーやWebアプリケーションにほかの脆弱性や設定上の問題がないかを確認することも重要です。株式会社ブロードバンドセキュリティ（BBSec）では、サーバーやネットワーク機器を対象とした「ネットワーク脆弱性診断」、WebアプリケーションやAPIを対象とした「Webアプリケーション・API脆弱性診断」を提供しています。SQAT®脆弱性診断サービスでは、ツール診断とエンジニアによる手動診断を組み合わせ、検出した問題の分析と推奨対策を報告します。Tomcat本体の更新と併せて、公開システムやWebアプリケーション全体のセキュリティ対策を見直したい場合は、BBSecにご相談ください。

お問い合わせページリンクボタン

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

PHPの重大な脆弱性「PHP2Shell」に続報 ―公開前の攻撃試行を確認、更新後も侵害調査が必要

Share
PHPの重大な脆弱性「PHP2Shell」に続報アイキャッチ画像

PHPの重大な脆弱性「PHP2shell」について、詳細公表前から攻撃が試みられていたことが明らかになりました。修正版の適用だけでは、公表前に侵害を受けていなかったことの確認にはなりません。企業には、PHPの更新と並行して、過去のログや関連する証跡を確認し、侵害の有無を調査することが求められます。本記事では、AWSの観測結果とJPCERT/CC、IPAの注意喚起を基に、更新後も確認すべきポイントを整理します。

「PHP2shell」の脆弱性の仕組みや影響を受ける環境、修正バージョンについては、前回記事「PHPの重大な脆弱性『PHP2shell』の修正版公開」で紹介しています。

公開前の攻撃試行をAWSが確認 成功した侵害とは区別

Amazon Threat Intelligenceは、攻撃観測用の仕組み「MadPot」の記録を分析し、10月17日にPHP2Shellを悪用しようとする攻撃を観測したと報告しています*5。これは脆弱性の詳細が公表される4日前にあたります。同チームは、その後も複数の攻撃試行を確認していますが、実際のシステムで攻撃が成功したかどうかは不明としています。

また、同チームは少なくとも10月17日以降の活動を調査対象とするよう促しています。観測された攻撃試行は、企業で情報漏洩などの実被害が発生したことを示すものではありませんが、公表日以降のログだけでは、それ以前の不審な活動を把握できない可能性があります。企業はログの保存期間を確認し、関連する記録が上書き・消去されないよう保全するとともに、修正版の適用と侵害の有無の調査を並行して進めることが重要です。

「PHP2shell」の対象となる2件の重大な脆弱性

「PHP2shell」は、PHP本体に存在するCVE-2026-109618とCVE-2026-109619の2件の脆弱性を指します。いずれも深刻度はCVSS v4.0で9.2（Critical）と評価されており、条件によっては遠隔から任意のコードを実行されるおそれがあります。PHP公式は、PHP-FPMやApacheのmod_phpなど、複数の実行環境に影響が及ぶ可能性を示しています。攻撃の成立条件は環境によって異なるため、利用しているPHPのバージョンや実行方式を確認し、公式情報に基づいて対応する必要があります。

PHPの修正バージョンと旧バージョンの対応

PHPプロジェクトは10月21日、PHP 8.2.35、8.3.36、8.4.27、8.5.12を公開しました。各系列の修正版より前のバージョンを利用している場合は更新が必要です。ただし、Linuxディストリビューションなどが修正をバックポートしている場合もあるため、利用中の提供元が今回の2件のCVEに対応しているかを確認してください。修正バージョンの一覧や旧系列の取り扱いについては、前回記事で紹介しています。

PHPの更新と暫定対策で確認すべきこと

今回の修正対象は、CMSやプラグインの下で動くPHP本体です。CMSの管理画面で更新済みと表示されていても、それだけではPHPの修正が適用されたことを確認できません。ホスティング事業者がPHPを管理している場合は、事業者に更新状況と利用者側で必要な操作を確認します。

企業側では、コーポレートサイトやECサイト、問い合わせフォーム、部門や委託先が管理するWebシステムについて、PHPの利用有無、実行方式、バージョン、管理者を確認します。複数のサーバーやコンテナで稼働している場合は、環境ごとに更新状況を管理し、一部の更新だけで完了としないことが重要です。適用後は必要な再起動などを行い、修正の反映状況と、ログインやフォーム送信、購入手続きなどの主要機能の動作を確認します。

PHP公式は、修正版への更新が根本的な対策であり、設定変更などの緩和策だけではすべての攻撃経路を防げないとしています。WAFによる防御も更新の代わりにはならないため、暫定対策を講じた場合も修正版の適用を進める必要があります。

更新までに時間を要する場合は、公式情報に基づく緩和策を検討し、対象システムの公開を継続できるか判断する必要があります。IPAは、有効な暫定対策を講じられない場合、外部からのアクセス遮断やサービスの一時停止も含めた対応を検討するよう案内しています。未更新の環境については、担当者と対応期限を明確にし、暫定対策と修正版の適用状況を区別して管理することが重要です。

修正版の適用と並行して侵害の有無を確認する

侵害調査では、少なくとも10月17日以降のアクセスログやエラーログを確認します。JPCERT/CCが挙げる不審なファイルアップロード形式のリクエスト、異常なPHPSESSID Cookie、メモリ関連エラーやHTTP 500エラー、PHPワーカーの異常終了などが調査の手掛かりとなります。ただし、これらの痕跡が見つからなくても、侵害がなかったと断定することはできません。利用環境や取得できる証跡に応じて調査範囲を判断し、侵害が疑われる場合は証拠を保全したうえで必要な対応を進めてください。あわせて、不審なプロセスの実行、外部通信、ファイルの作成・変更など、サーバー側の状態も確認します。

図：修正版の適用と侵害調査を並行して進める

修正版の適用と侵害調査の流れ
出典：Amazon Web Services「Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot」、JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」を基に弊社作成。
※修正版の適用と侵害調査を並行して進めるための主な確認事項を示した概念図です。実際の対応は利用環境や取得可能な証跡に応じて判断する必要があります。修正版の適用や特定の痕跡が確認されないことは、過去に侵害されていないことを保証するものではありません。

BBSecが支援する脆弱性情報の収集と継続的な監視

緊急更新を進めるうえでは、自社に関係する情報を見つけ、未対応のシステムを追える状態が必要です。株式会社ブロードバンドセキュリティ（BBSec）の「脆弱性情報提供　SAS（Secure Net Alert Mail Service）」は、登録したシステム情報に基づいて必要な脆弱性情報を絞り込み、配信するサービスです。本サービスは対応ステータスの管理機能も備え、日々の脆弱性管理を支援します。またプランに応じてJVNやNVDの公開情報を利用します。PHP公式や利用中の事業者が出す案内も直接確認し、情報提供サービスと組み合わせて対応を進めることが大切です。

公開資産の把握に課題がある場合は、「アタックサーフェス調査（SQAT® ASM）」も活用できます。インターネット上の公開情報から、攻撃者に見える資産や脅威となり得る情報を調査するサービスです。調査結果を社内の資産台帳と照合し、管理担当や更新状況を確かめる手掛かりにできます。

公開前の活動を含む侵害調査と、その後の監視体制にも課題がある場合は、「G-MDR®」も選択肢になります。各種セキュリティ対策を統合して監視・相関分析し、24時間365日の体制で検知、遮断・封じ込め、被害調査や対応を支援するサービスです。平時の脅威分析や、有事のフォレンジック対応支援も提供します。対象システムや利用できるログ、対応範囲は個別に確認してください。

今回のPHP更新を進めながら、情報の見落とし、未把握の公開資産、監視や調査の不足も確かめておきましょう。自社でどこまで対応できるかを整理し、必要な支援をBBSecへご相談ください。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

eMudhraの中間CA秘密鍵が復元可能に ―証明書の信頼問題と企業のTLS対策

Share
eMudhraの中間CA秘密鍵が復元可能に ―証明書の信頼問題と企業のTLS対策アイキャッチ画像

HTTPS通信では、サーバー証明書の検証によって接続先の正当性を確認します。しかし、その信頼の根拠となる認証局の秘密鍵が第三者に悪用されると、なりすましの危険が生じます。2026年10月、認証局eMudhraの中間CA証明書8件に対応する秘密鍵が、第三者でも容易に復元できる状態だったことが明らかになりました。MozillaやGoogleは対象証明書の信頼を遮断する対策を進め、関連ソフトウェアの更新も行われています。企業が確認すべきなのは、自社サイトで使用するSSL／TLS証明書だけではありません。外部サービスへ接続する業務アプリの証明書検証機能も対象です。本記事では、問題の概要と影響範囲、API通信を含むシステムの確認事項を整理します。

※本記事は2026年10月22日時点で公表されている情報を基に作成しています。認証局の調査結果や各ソフトウェアの対応状況は、今後変更される可能性があります。

中間証明書とは サーバー証明書を信頼につなぐ役割

中間証明書は、ルート認証局から個々のサーバー証明書へ信頼をつなぐ証明書です。一般的な証明書チェーンでは、ブラウザやOSなどが信頼するルート証明書を起点に、中間CA証明書、その下のサーバー証明書へと署名の関係が続きます。接続する側はこの関係などを検証し、相手の証明書を受け入れてよいか判断します。

Webサイトの運営者が持つ秘密鍵と、中間CAが証明書に署名するための秘密鍵は役割が異なります。後者を第三者が使用できる状態になると、攻撃者は対象の中間CAが正規に発行したかのように見える証明書を偽造できるおそれがあります。今回、問題となったのはこの署名用の秘密鍵です。通信経路に介入できる攻撃者が偽の証明書を提示し、接続側が受け入れると、通信内容を読み取られたり書き換えられたりするおそれがあります。

図1：中間CAの秘密鍵とサーバー証明書の信頼の関係

中間CAの秘密鍵とサーバー証明書の信頼の関係
出典：株式会社インターネットイニシアティブ「サーバ証明書の仕組みに関すること」、Mozilla Corporation（Firefox Security Team）「Protecting Firefox users following the compromise of eMudhra intermediate certificates」、Mozilla Foundation（Bugzilla）「eMudhra: Private key compromise of Intermediate Certificates（Bug 2083449）」を基に弊社作成。
※TLSの証明書チェーンと攻撃成立の条件を簡略化した概念図です。実際には複数の中間CAやクロス署名が存在する場合があります。秘密鍵の復元だけで通信の盗聴・改ざんが成立することを示すものではありません。

eMudhraの中間CAで秘密鍵の生成に問題が発覚

Mozillaの調査記録によると、対象8件のうち6件はTLS用、2件はコード署名用です。Mozillaは2026年10月17日20時06分（UTC）に報告を受け、通常設定のFirefox向けには同日22時59分までにOneCRLによる遮断を配信しました。日本時間では10月18日5時06分の受領から、同日7時59分までの対応です。対象の鍵は楕円曲線暗号P-384を使っていましたが、秘密鍵の値はすべて256未満の整数でした。独立して検証した研究者Scott Helme氏も、公開証明書から対象の鍵をノートPCで1秒未満に復元できたと報告しています。十分なランダム性を持つ値が必要なところ、極端に小さな値が使われていたことが問題であり、適切に生成されたP-384の鍵まで容易に復元できるという話ではありません。

eMudhraは、2025年4月30日の鍵生成作業で、鍵を移送するためのwrap/unwrap工程に問題があり、正常な鍵とは別に弱い鍵が生成されたと説明しています。同社はHSM（ハードウェアセキュリティモジュール）を使用していたとしていますが、10月21日の更新時点で正確な根本原因は確定していません。現段階では、同社が説明する作業工程の問題と、今後の調査で確定する原因を分けて捉える必要があります。

ブラウザだけでなく業務アプリの証明書検証も確認

Chromeは10月17日に対象TLS中間CAの公開鍵をCRLSetで遮断しました。Googleによると、その遮断前に対象の中間CA配下のTLS証明書はCertificate Transparency（CT）のログに登録されていませんでした。このため、CTを必須とする標準設定のChromeなどでは、対象CAを使った偽造証明書が信頼される状態ではなかったと説明しています。

CTは、証明書の発行を公開ログで検証できるようにする仕組みです。認証局が証明書を失効させたという情報や、ブラウザ独自のブロックリストとは役割が異なります。失効情報やブロックリストを受け取らないアプリに、ブラウザと同じ対策が自動的に行き渡るとは限りません。業務アプリで証明書を検証するのは、HTTPライブラリやOS、独自の信頼ストアなどです。SDKだけの更新で対策が済むとは限りません。自社サイトの証明書の発行元が別でも、外部APIへ接続するアプリが対象CAを信頼する場合は確認が必要です。

図2：証明書を提示する側と検証する側の確認範囲

証明書を提示する側と検証する側の確認範囲
出典：Mozilla Foundation（Bugzilla）「eMudhra: Private key compromise of Intermediate Certificates（Bug 2083449）」、Google LLC（Chrome Root Program）「Compromised eMudhra Intermediate Certificatesへの公式投稿」、Cloudflare, Inc.「8 eMudhra certificates are compromised. Here’s what you need to know」を基に編集部作成。
※企業における確認対象を整理した概念図です。記載したすべての製品や環境が影響を受けることを示すものではありません。対応の要否は、実際の証明書チェーン、検証機能の実装、ソフトウェアの更新状況によって異なります。

中間CA証明書の失効とルートCAの信頼取り消し

eMudhraは、問題の8件の中間CAからエンドユーザー向け証明書を発行していなかったと説明しています。ただし、それだけで第三者による偽造の可能性がなくなるわけではありません。誰かが秘密鍵を復元し、認証局の正規の発行手続きを経ずに証明書を作ることが問題だからです。

Mozillaは、中間CAだけを個別に拒否する仕組みを持たないソフトウェアも保護するため、上位のルート証明書「emSign ECC Root CA – G3」の信頼を緊急に取り消す方針を示しました。GoogleもChrome Root Store v43で同ルートを削除する予定です。Googleが示した安定版への反映予定は、10月27日午前の米国太平洋夏時間で、10月22日時点では今後の対応に当たります。

ルートの信頼が外れると、問題の弱い鍵を使っていない別の中間CA配下であっても、そのルートにつながる正規のサーバー証明書が検証に失敗する場合があります。eMudhraは当初、移行が必要な証明書を約3万件と見積もりました。この数字は被害件数やWebサイト数ではありません。対象の階層を利用している場合は、有効期限を待たず、提供元の案内に沿って代替の証明書チェーンへ移行する必要があります。

FirefoxやGoなどの修正版と適用時の注意

Mozillaは10月20日、OneCRLの更新を受け取れない設定の利用者も保護するため、Firefox 158.0.1、Firefox ESR 115.43.1／153.5.1を公表しました。さらにAndroid版は10月21日に158.0.2が公開され、起動時に同梱のOneCRLブロックリストを適用する処理が修正されています。Android版では158.0.1だけを確認して対応済みとせず、この追加修正を含む更新を適用します。

Go 1.27.3および1.26.10では、対象の中間CA証明書を含む証明書チェーンを検証時に拒否する処理が追加されました。Goの脆弱性情報ではCVE-2026-111943、GO-2026-6809として管理されています。Go製アプリを運用する場合は、修正を取り込んだ製品版の有無を確認し、自社開発なら修正版でビルドした実行ファイルを配備することが対応になります。CloudflareはWARPなどのクライアントとcloudflaredの更新を公開しています。コンテナやアプリの依存関係も確認し、必要な再起動・再配備まで行います。

証明書の期限管理に検証経路の管理を加える

まず、WebサイトやAPIが提示する証明書チェーンを把握し、信頼が取り消される階層に依存していないかを確認します。同時に、外部のサービスへ接続する業務アプリについて、使用している証明書の検証機能と信頼ストアを調べます。証明書を提示する側と検証する側を分けると、証明書の交換が必要なのか、ソフトウェアやCA証明書の更新が必要なのかを整理できます。更新後は、実際の業務アプリで動作を確認します。ブラウザでの確認結果を、別の検証機能を使うバッチ処理やAPIクライアントの安全性の根拠にはできません。証明書エラーが出ても検証を無効にせず、チェーンや設定の原因を調べます。

今回の事案は、サーバー証明書が有効期限内であっても、認証局に対する信頼の変更によって証明書の交換やソフトウェアの更新が必要になることを示しています。企業には、証明書の発行元や有効期限だけでなく、証明書チェーンや検証に使用するソフトウェア、更新の管理体制まで把握し、継続的に確認することが求められます。

関連記事｜TLS通信の安全性を確認するために

TLS通信の安全性を維持するには、証明書の信頼性に加え、暗号設定やTLSバージョンの適切な管理も重要です。基本的な仕組みから具体的な確認方法まで、以下の記事で紹介しています。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

GitLabにCVSS 10.0の重大な脆弱性 ―未認証RCEとAIエージェントの問題、企業が確認すべき対策

Share
GitLabにCVSS 10.0の重大脆弱性アイキャッチ画像

GitLabは2026年10月12日、重大な脆弱性を修正する更新を公開しました。認証なしで遠隔から任意のコードを実行できるRCE（Remote Code Execution：リモートコード実行）の脆弱性「CVE-2026-97229」に加え、AIエージェントに関する別の問題も対象です。自社でGitLabを運用する企業は、利用形態とバージョンを確認して更新を優先し、認証情報や権限の管理も点検する必要があります。

CVE-2026-97229の対象と修正版を確認する

今回GitLabが修正した2つの脆弱性は、影響を受けるエディションやバージョン、攻撃に必要な認証の有無が異なります。自己管理型の運用担当者は、該当する系統の修正版を確認してください。対象バージョンと修正版は下図のとおりです。

図：GitLabで修正された2つの脆弱性と影響を受けるバージョン

出典：GitLab「GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8」（https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/）を基に弊社作成
※2つは別の脆弱性であり、攻撃の連鎖を示すものではありません。

まず、自社の利用形態を確認する必要があります。「GitLabを使っている」という情報だけでは、更新の担当者を決められません。自己管理型であれば、管理対象のインスタンスとバージョンを運用担当者が照合します。社内の複数部門が別々に運用している場合は、主要な開発環境だけで確認を終えず、管理対象全体を洗い出す必要があります。公式発表は攻撃が成立し得る条件と修正を説明したものであり、本記事で参照した発表から実際の被害発生は確認できません。深刻度の数値と、自社環境で侵害が起きたかどうかの判断は区別してください。更新後も、必要に応じてログや変更履歴を確認します。

【2026年10月22日追記】
GitLabは10月21日、新たにCVSS 10.0の脆弱性CVE-2026-110264の修正版を公開しました。10月12日の更新を適用した環境も影響を受けるため、改めてバージョンの確認が必要です。
詳細は「GitLabにCVSS 10.0の重大な脆弱性 ―10月21日公開の修正版と企業が確認すべき対策」をご覧ください。

開発基盤を守る理由は ソースコードだけではない

CI/CDは、ソースコードの変更からビルド、テスト、配布などを継続的に実行する仕組みです。開発作業を自動化するため、実行環境にはリポジトリや配布先へアクセスする権限が必要になります。OWASPも、CI/CDでは高い権限を持つ識別情報が利用されることがあり、実行基盤の保護、資産・バージョン管理、最小権限が重要だと説明しています*2。

したがって、管理対象はGitLab本体のバージョンにとどまりません。自社のCI/CDが何を読み出し、どの環境へ書き込み、どの認証情報を使用するのかを把握しておく必要があります。これは今回、ソースコードの改ざんや認証情報の窃取が確認されたという意味ではなく、開発基盤を運用する際の確認範囲を示したものです。GitLabの公式文書では、悪意あるCI/CDスクリプトが変数の値を取得し、外部へ送信する危険性も説明されています。変数をログ上で伏せる「マスク」は、悪意ある処理から秘密情報を守る保証にはなりません。パイプライン設定を変更するレビューで、外部通信や秘密情報の参照が加わっていないかを確認することが大切です。

GitLab Duoの問題は 別の脆弱性として扱う

CVE-2026-96893は、AIへの指示に細工した内容を混入させるプロンプトインジェクションの問題です。上図で示したとおり、AIエージェントに処理を任せる際の指示と、実行される操作の権限が論点になります。未認証RCEとAIエージェントの問題では、認証の要否や影響を受けるバージョンが異なります。両者を一つの攻撃経路として描いたり、「AIを使わなければ今回の更新は不要」と判断したりしないよう注意が必要です。プロンプトインジェクションへの一般的な対策では、AIが受け取る内容の検査に加え、実際に呼び出すツールの権限を制限することが重要です。OWASPは、ツール呼び出しを利用者の権限やセッションと照合し、APIの操作範囲を絞ることを勧めています。AIへの指示文だけに安全性を委ねず、重要な操作には人による承認を組み込む設計が必要です。

更新とあわせて 認証情報と操作履歴を点検する

運用を見直す際は、変更内容を追跡できるかを確かめます。たとえば、管理権限を持つアカウントの変更、パイプライン設定の更新、想定外のジョブ実行を、申請やレビューの記録と照合できる状態にします。すべての操作を無制限に記録するのではなく、調査に必要な情報を取得し、機密情報がログへ入り込まないように設計します。OWASPもCI/CD全体の可視性とログ分析の重要性を示しています。認証情報の扱いにも手順が必要です。漏えいや不正利用が疑われるトークンなどは、関係するシステムと影響を把握したうえで失効・再発行します。OWASPのシークレット管理指針は、不要になった情報や侵害の可能性がある情報の失効、必要最小限の権限、有効期限の管理を重視しています。単に新しい値を作るだけでなく、古い値が使えなくなったことと、正規の処理が新しい値で動くことまで確認する運用が求められます。

緊急アップデートに対応できる体制を平時からつくる

今回の対応を一度の更新で終わらせず、今後の脆弱性公表にも対応できる運用体制を整えることが重要です。開発部門が製品を管理し、情報システム部門がサーバーを管理しているなら、脆弱性情報の受信、影響判定、更新の承認、実施後の確認を誰が担当するのかを明確にします。更新が必要だと分かっても、停止の承認者や確認手順が不明では作業を進められません。資産の一覧と担当者、利用バージョン、重要な連携先を同じ単位で把握し、対応結果を残すことが、情報を実際の修正へ結び付ける土台になります。

脆弱性への継続的な対応とAIの安全な活用を支援

ブロードバンドセキュリティ（BBSec）が提供している「脆弱性情報提供」は、登録したシステム情報に応じて必要な脆弱性情報を絞り込み、通知するサービスです。情報収集が担当者個人に依存している場合や、対応状況の管理に課題がある場合の支援策として活用できます。通知を受けた後の影響判定や更新の責任分担も含め、自社に適した運用を検討することが重要です。またAIエージェントの利用ルールを整える場合には、「AIサービス提供者・利用者向けサイバーセキュリティ対策支援サービス」もご活用いただけます。ガイドラインの整備や教育を通じて、AIをどの業務で、どの権限で利用するかを組織として整理する取り組みを支援します。修正版の適用と、継続的な情報収集・運用ルールの整備を組み合わせ、開発基盤の安全性を保っていきましょう。

セキュリティ対策について相談する

脆弱性情報の継続的な収集や、AIの安全な利用に向けたセキュリティ対策について、お困りのことがございましたら、BBSecまでお気軽にご相談ください。

【参考情報】

公開日：2026年10月20日
更新日：2026年10月22日

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

GitLabにCVSS 10.0の重大な脆弱性 ―10月21日公開の修正版と企業が確認すべき対策

Share
GitLabにCVSS 10.0の重大な脆弱性 ―10月21日公開の修正版と企業が確認すべき対策アイキャッチ画像

GitLabを10月に更新したばかりでも、もう一度バージョンを確認する必要があります。GitLab Inc.は2026年10月21日、未認証の利用者による任意コード実行につながる可能性がある脆弱性CVE-2026-110264の修正版を公開しました。CVSS v3.1の基本値は最高値の10.0で、GitLab 7.0以降の複数のバージョン系列に影響します。自社でGitLabを運用している場合は、今回の修正対象と稼働中のバージョンを照合してください。本記事では、影響範囲と修正版、前回のセキュリティ更新との違いを整理し、更新時の確認とログ監視の進め方を解説します。

CVE-2026-110264で公表された内容

今回の問題は、細工された正規表現をコンパイルする際の整数オーバーフローに関するものです。GitLabの公式告知では、一定条件下で、認証されていない利用者がGitLabサーバー上で任意のコードを実行できる可能性があると説明しています。攻撃が成立する具体的な条件は、告知本文では詳述されていません。対象はGitLab Community EditionとEnterprise Editionです。GitLab.comは修正済みです。GitLab Dedicatedでは、19.3系の19.3.5-internal0、19.4系の19.4.2-internal0以降に修正が含まれます。利用者側で更新が必要なSelf-Managed環境と、GitLab側が管理する環境を区別して確認しましょう。影響するバージョンを使用している場合は、GitLabの推奨に従い、できるだけ早く修正版へ更新してください。

影響を受けるGitLabのバージョンと修正版

GitLabは今回、7系列に修正版を提供しました。下図はCVE-2026-110264について、影響を受ける範囲と修正が入ったバージョンを対応させたものです。

図1：CVE-2026-110264の影響範囲と修正版

CVE-2026-110264の影響範囲と修正版の表
出典：GitLab Inc.「GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13」（https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/）を基に作成。
※各行は影響を受けるバージョンと今回の修正版の対応を示しています。直接アップグレードできる経路や、同時公表された他の脆弱性の修正範囲を示すものではありません。数値データの集計・推計は行っていません。

通常の保守対象は現行版と直前2回の月次リリースで、確認時点では19.5、19.4、19.3が該当します。今回はそれより古い系列にも修正が提供されていますが、古い系列の通常保守が再開されたことを意味するものではありません。緊急の修正適用と、保守対象バージョンへの移行計画をあわせて検討してください。

10月12日の修正版も今回の確認対象

10月12日に公表されたCVE-2026-97229も、認証不要のコード実行につながる可能性があるCVSS 10.0の脆弱性でした。ただし、こちらの影響範囲は19.2以降で、修正版は19.2.8、19.3.5、19.4.2でした。これらのバージョンは今回のCVE-2026-110264では影響範囲に含まれます。

10月12日に公表された脆弱性の詳細については、「GitLabにCVSS 10.0の重大な脆弱性 ―未認証RCEとAIエージェントの問題、企業が確認すべき対策」をご覧ください。

さらに9月23日には、正規表現処理に関するCVE-2026-89078とCVE-2026-93577が修正されています。この2件は認証済みユーザーを前提とし、CVSSはそれぞれ9.9でした。同じ製品で似た説明の脆弱性が続いても、対応済みかどうかはCVEごとに確認する必要があります。運用記録には更新日だけでなく、対応したCVE番号と適用後のバージョンを残しておくと、新たな告知との照合がしやすくなります。

更新経路と停止時間を確認してパッチを適用

古いGitLabを使用している場合、図1の修正版へ一度で更新できるとは限りません。GitLabはアップグレード経路に必須の中継バージョンを設け、各段階でバックグラウンドのデータベース移行が完了してから次へ進むよう案内しています。現在のバージョンと導入方式を確認し、公式の更新手順に沿って作業を組み立てます。

更新前にはバックアップと復旧手順を準備します。GitLabの公式ドキュメントは、シークレットと設定ファイルもバックアップ対象に含めることや、本番環境を複製した環境で更新計画を試すことを案内しています。更新後はログイン、リポジトリの取得や更新、CI/CDジョブなど、実際に使う機能が動作するかを確認します。

今回の19.4.3と19.3.6には通常のデータベース移行が含まれます。公式告知では単一ノード環境で更新時の停止が生じると説明し、複数ノード環境には所定の無停止更新手順を案内しています。停止の有無を、パッチ番号の変更だけで判断しないことが大切です。

ログを確認し侵害の兆候を見逃さない

2026年10月22日時点で確認できた米CISAの「KEVカタログ（Known Exploited Vulnerabilities）」の10月21日版には、CVE-2026-110264は掲載されていませんでした。ただし、掲載されていないことだけで悪用の有無や自社環境の安全性は判断できません。

GitLabは本件に関する攻撃試行の検知を支援するため、「Onigmo native worker crash」と「Org mode render error burst」の2つの検知ルールを公開しています。公式の検知基盤TLDRでは、必要なログやSigma形式のルール、対応手順などを提供しています。利用する場合は、必要なログを収集できているかを確認し、自社環境に合わせてルールを調整します。パッチ適用による脆弱性への対処と、不審な操作の確認は、目的が異なる作業です。GitLabはアプリケーションログや監査イベントなどを集約し、調査に必要な保存期間を定めることを推奨しています。新たな管理者やアクセストークンの作成、承認ルールの変更など、確認すべき活動も示しています。検知の範囲は設定や契約プラン、収集できるログによって変わります。

図2：GitLabの更新とログ確認の進め方

GitLabの更新とログ確認の進め方のフロー図
出典：GitLab Inc.「Before you upgrade」「Security incident detection」「Security incident response」のを基に弊社作成。
※更新とログ確認を並行して進める際の整理例です。GitLabが定めた唯一の手順を示すものではなく、ログに異常が見つからないことは侵害がない証明にはなりません。数値データの集計・推計は行っていません。

不審な操作や認証情報の漏えいが確認された場合は、社内のインシデント対応手順に従って調査と対処を進めます。GitLabの対応ガイドでは、漏洩したトークンの権限や影響範囲を把握したうえで失効・更新を判断し、関連する監査ログを確認するよう案内しています。業務への影響も踏まえ、担当者を決めて対応することが必要です。

BBSecのサービスで継続的な対応を支援

今回のように短い間隔で新たな修正が公表される場合、利用中の製品に関係する情報を見つけ、担当者へ届け、対応が終わったかを追える運用が役立ちます。脆弱性情報を受信しても、対象システムや対応状況と結びついていなければ、確認のたびに調べ直すことになります。ブロードバンドセキュリティ（BBSec）の「脆弱性情報提供　SAS（Secure Net Alert Mail Service）」は、登録したシステム情報に基づいて必要な脆弱性情報を絞り込み、メールや管理画面で確認できるサービスです。CVSS計算機能や対応ステータス管理機能も備え、日々の脆弱性管理を支援します。対応方法について助言するセキュリティ・アドバイザリとの連携も可能です。

自社の製品構成に合った情報収集や、対応状況の管理を見直したい場合は、BBSecへご相談ください。対象製品や配信条件、必要な支援範囲を確認しながら、継続して運用できる方法を検討できます。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

PHPの重大な脆弱性「PHP2shell」の修正版公開 ―影響範囲とAIによる発見の経緯

Share
PHPの重大な脆弱性「php2shell」の修正版公開アイキャッチ画像

PHPの重大な脆弱性「PHP2shell」への対応は、更新の準備から修正版を適用する段階に移りました。PHPプロジェクトは2026年10月21日、認証なしでサーバー上のコードを実行されるおそれがある2件の脆弱性を修正し、利用者に速やかな更新を求めています。またOpenAIも同日、AIを活用した発見と、PHPの開発者やセキュリティ事業者による対応の経緯を公表しました。本記事では、修正バージョン、影響範囲、暫定策の限界を整理し、AI時代の脆弱性管理で企業が見直したい運用を解説します。

※本記事は2026年10月22日12時時点で公表されている情報を基に作成しています。脆弱性の影響範囲や対策については、PHP公式および利用製品の提供元が公表する最新情報をご確認ください。

PHP本体に存在する2件の重大な脆弱性「PHP2shell」

対象はCVE-2026-109618とCVE-2026-109619です。いずれも深刻度はCVSS v4.0で9.2のCriticalとされています。前者はメモリ不足が起きた際、不完全な内部データを後の終了処理で使ってしまう問題です。後者は、リクエストの処理後に解放されたメモリへの参照が残り、同じワーカーが後続のリクエストを処理するときに使ってしまう問題です。

PHP公式は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するPHP環境をリスクのある対象として挙げています*2。特にmod_phpでは、アプリケーションのコードが動く前に認証不要の攻撃が成立する実証があり、最もリスクが高いと評価しています。

ただし、攻撃が成立する条件や実証の範囲は、実行方式、設定、アプリケーションなどによって異なります。すべての構成で同じ攻撃が同じように成立するわけではありません。構成による違いを理由に更新を見送らず、公式のアドバイザリと利用環境を照合することが必要です。

PHPの修正バージョンと旧バージョンの対応

10月21日に公開された修正版は、PHP 8.2.35、8.3.36、8.4.27、8.5.12です。各系列でこれらより前のバージョンを使っている場合は、修正版への更新を進めます。Linuxディストリビューションや長期サポート事業者のパッケージでは、提供元のセキュリティ情報と修正済みパッケージを確認してください。旧版を維持したまま修正を取り込むバックポートでは、上流のPHPとバージョン表記が一致しない場合があります。表示番号だけで結論を出さず、提供元が今回の2件のCVEに対応しているかを確認することが大切です。

PHP 8.1以前は、PHPプロジェクトの通常の更新対象から外れています。ただし、今回は問題の重大さから、PHP 7.4、8.0、8.1向けに最小限のソースバックポートも提供されました。これを通常サポートの再開と捉えず、保守事業者の対応を確認しながら、サポート対象への移行を進めてください。

図1：PHP2shellに対応したPHPの修正バージョン

PHP2shellに対応したPHPの修正バージョンの表
出典：The PHP Group「Security advisory: Critical remote code execution vulnerabilities, update now」「RCE via OOM corruption」「RCE via stale global state」を基に弊社作成。
※2026年10月21日公開の修正バージョンを系列ごとに示しています。修正版より前のバージョンは更新確認の対象です。ただし、旧系列やLinuxディストリビューション等によるバックポートは表に含めていません。提供元のCVE対応情報も確認してください。

OpenAIが公表したAIによる発見と協調開示

OpenAIによると、セキュリティ企業Califは「Patch the Planet」の取り組みでGPT-5.6 Solを使い、重大な欠陥を特定しました*2。また、Wizも独立して両方の脆弱性を発見・報告しています。修正とリリースを主導したのはPHPのメンテナーで、OpenAIなどが調査・テスト・調整を支援しました。

発見の経緯には、以前から把握されていた問題も含まれます。The PHP Foundationは、CVE-2026-109618の原因となったメモリ不足処理の問題について、2024年に兆候を認識していたと説明しています*3。その後の研究報告によって深刻な影響が明確になりました。AIによる研究が進む一方で、報告の判断やパッチの作業には人が関与しているとも説明しています。

協調開示では、問題の公表に向けて開発者が修正を検証し、配布元やサービス事業者が更新や防御策を準備します。今回も、PHPの修正を利用者に届けるまでに複数の組織が関わりました。企業の運用でも、情報を受け取る担当、対象システムを把握する担当、更新を実施する担当の間で作業が止まらない体制が欠かせません。

図2：脆弱性の発見から企業の更新までをつなぐ役割

PHP脆弱性対応フロー図
出典：OpenAI「Patch the Planet：エージェントによる重大な脆弱性の発見と世界規模の対応連携」、The PHP Foundation「Today’s PHP Security Release, and How We’re Strengthening PHP Security」を基に弊社作成。
※今回の主な役割を簡略化した概念図です。矢印は連携を示し、厳密な時系列や組織間の指揮命令関係を示すものではありません。企業による適用・確認は運用上の対応を示しています。

設定変更やWAFだけで対策を終えない

PHP公式は、更新が唯一の完全な対策であり、暫定策は特定の攻撃経路への露出を減らすものとしています。例えば、session.upload_progress.enabled=0は、確認済みのセッション関連経路を抑える設定です。CVE-2026-109619のすべての経路を防ぐものではなく、反映には全ワーカーの再起動も必要です。エラー表示を消すだけでも対策にはなりません。

Cloudflareは10月21日の公表で、顧客を狙う攻撃トラフィックを観測し、WAFの防御を回避しようとする変化も確認したと報告しています*4。これは同社の観測であり、すべての環境で侵害が成功したことを示す情報ではありません。同社はWAFによる防御を提供しつつ、PHP自体の更新も求めています。

更新までの時間が必要な場合は、運用担当者と事業者が公式の緩和策を確認し、利用機能や可用性への影響を検討します。設定を変更した記録と、修正版を適用した記録は分けて管理してください。暫定策を講じたことで更新作業が止まらないよう、未更新の環境には担当者と対応期限を設定します。

CMSの更新状況に加えてPHPの稼働環境を確認する

今回の修正対象は、CMSやプラグインの下で動くPHP本体です。CMSの管理画面で更新済みと表示されていても、それだけではPHPの修正が適用されたことを確認できません。ホスティング事業者がPHPを管理している場合は、事業者に更新状況と利用者側で必要な操作を確認します。

企業側では、コーポレートサイトやECサイト、問い合わせフォーム、部門や委託先が管理するWebシステムについて、PHPの利用有無、実行方式、バージョン、更新元、管理者をそろえます。複数のサーバーやコンテナで動かしている場合は、一部の更新だけで完了としないよう、環境ごとに対応状況を残してください。適用後は、提供元の手順に従って再起動などの必要な処理を行い、実際にWebリクエストを処理している環境に修正が反映されたことを確認します。ログイン、フォーム送信、購入手続きなど、業務上重要な操作の動作確認も行います。米国国立標準技術研究所（NIST）も、パッチ管理には更新の識別、優先順位付け、取得、適用だけでなく、適用確認までを含めています。

並行して、アクセスログやエラーログの記録・保全状況を確認します。更新の完了は、過去に侵害されていないことの証明にはなりません。不審な通信やファイル、予期しないプロセスなどが見つかった場合は、記録を保全し、組織のインシデント対応手順に沿って調査につなげてください。

BBSecが支援する脆弱性情報の収集と公開資産の把握

緊急更新を進めるうえでは、自社に関係する情報を見つけ、未対応のシステムを追える状態が必要です。ブロードバンドセキュリティ（BBSec）の「脆弱性情報提供　SAS（Secure Net Alert Mail Service）」は、登録されたシステム情報に基づき、関連する脆弱性情報を絞り込んで提供するサービスです。対応ステータスの管理機能も備え、日々の脆弱性管理を支援します。SASの配信情報は、プランに応じてJVNやNVDの公開情報を利用します。PHP公式や利用中の事業者が出す案内も直接確認し、情報提供サービスと組み合わせて対応を進めることが大切です。

公開資産の把握に課題がある場合は、「アタックサーフェス調査（SQAT® ASM）」も活用できます。インターネット上の公開情報から、攻撃者に見える資産や脅威となり得る情報を調査するサービスです。調査結果を社内の資産台帳と照合し、管理担当や更新状況を確かめる手掛かりにできます。

まずは今回のPHP更新を着実に進め、その過程で情報の見落としや担当の不明確さが見つかったら、日々の管理方法も見直してください。脆弱性情報の選別や公開資産の把握にお困りの場合は、BBSecへご相談ください。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

CVE-2026-99999 PwnEscapeとは ―Linux仮想化基盤への影響と企業の対策

Share
CVE-2026-99999 PwnEscapeとはアイキャッチ画像

CVE-2026-99999（通称PwnEscape）は、LinuxカーネルのIPv4ネットワーク処理に存在する脆弱性です。仮想マシンからホストのメモリ情報が漏えいする問題が確認され、研究者の検証環境ではホストの停止や管理者権限でのコード実行も実証されています。

本記事では、実証結果と実際の被害を区別しながら、PwnEscapeの仕組みや影響範囲、修正版の確認方法を解説します。

PwnEscapeで問題となったLinuxのチェックサム処理

チェックサムは、通信データの誤りを検出するために使われる値です。仮想化環境では、その計算をゲスト側ですべて済ませず、ホスト側などの後続処理に任せる仕組みがあります。その際、どこから計算し、結果をどこに書くかを示すメタデータも受け渡されます。

図1：PwnEscapeがホストへ影響する経路

PwnEscapeで仮想マシンからホストへ影響が及ぶ仕組み。ゲストVMから渡された不正なチェックサムメタデータが、ホストのIPv4ヘッダーを後から変更し、メモリ漏えいなどにつながる流れ。
出典：Linux Kernel Organization「Commit 6785011」（https://github.com/torvalds/linux/commit/6785011f8b16abf40b1e9d8b2e332232b3e68822）、CVE-2026-99999（https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/99xxx/CVE-2026-99999.json）、Vercel Inc. Findings from the $1M Vercel Sandbox challenge（https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge）を基に弊社作成。
※通信処理を簡略化しています。通常のインターネット通信の受信による攻撃を示すものではありません。
※攻撃には、ゲストVMなどから問題の処理経路へ到達できる条件が必要です。実証環境と確認された影響は図2をご参照ください。

PwnEscapeでは、このメタデータの検証が不足していました。ホストがIPv4ヘッダーを読み取った後、不正な指定に従ってチェックサム処理を行うと、すでに確認したヘッダーを書き換えてしまいます。後続の処理が変更後の情報を信頼することで、メモリ漏えいなどの問題につながります。Linuxの修正は、チェックサムを完成させる前に、計算開始位置がIPv4ヘッダーと重ならないかを検証するものです。

Vercel本番環境と研究者環境で実証された範囲

図2：公表資料で確認できる実証環境と結果

公表資料で確認できる実証環境と結果。Vercel本番Sandboxではホストメモリ漏えい、研究者所有のKVMとFirecracker環境ではホスト停止と管理者権限でのコード実行が実証されたことを比較した図。
出典：Vercel Inc. Findings from the $1M Vercel Sandbox challenge（https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge）を基に弊社作成。
※Vercel本番環境でのホスト乗っ取りや、顧客情報へのアクセスが確認されたことを示すものではありません。
研究者による実証結果と、実際の攻撃への悪用状況は区別して記載しています。

Vercelは2026年10月14日、Sandboxのセキュリティ調査結果を公表しました*5。研究者Paulos Yibelo氏が、microVM内から送信する細工したパケットによってホストメモリを漏えいさせる攻撃を発見し、Vercelの本番Sandboxで実証したと説明しています。ホストのクラッシュと、ホスト上での管理者権限によるコード実行は、研究者が所有するKVMおよびFirecrackerの環境で実証されています。これらはVercel Sandboxに相当する構成での実証結果であり、Vercelの本番環境でホストの乗っ取りが確認されたことを意味するものではありません。また、Vercelは顧客のファイル、秘密情報、アプリケーションデータへのアクセスを示す報告はなかったと説明しています。

実際の攻撃への悪用状況については、公表資料の評価に違いが見られます。Red Hatには悪用を示唆する記述がある一方、CVE公式データに含まれるCISAの2026年10月16日付評価では「Exploitation: none」とされています。ただし、この評価は悪用が存在しないことを保証するものではありません。本記事では悪用の有無を断定せず、研究者による実証結果と区別して扱います。

信頼できないVMを実行するホストでは優先的な確認が必要

優先して確認したいのは、利用者が持ち込むコードや、信頼できないゲストVMを実行するLinuxホストです。AlmaLinuxは、クラウド、VPS提供基盤、コード実行用サンドボックスなど、他者のVMを運用する環境で特に重要な問題だと説明しています*2。障害がホストに及べば、その上で動く複数のVMも影響を受けます。「KVM escape」という呼び方は、ゲストとホストの隔離境界を越える影響を表しています。欠陥の所在はホスト側のLinuxネットワーク処理です。CVE公式レコードの攻撃元区分はLocalで、説明されているのはゲストやローカルの仮想デバイスを経由する経路です。通常のインターネット通信を受信するだけで任意のLinuxサーバーが侵害される、という意味ではありません。

一方、VMを動かしていないことだけで影響なしとも判断できません。Red Hatは、ローカルの攻撃者から問題の処理に到達する可能性も説明しています。利用している製品、カーネルの修正状況、攻撃に必要な操作を許しているかを、ベンダーの情報に沿って確認する必要があります。

CVSS 9.3の意味と修正版の確認方法

Linux CNAによるCVSS v3.1の評価は9.3（Critical）です。Red Hatは8.8、Importantと評価しており、必要な権限の扱いが異なります。点数だけで一律に判断せず、自社の環境で攻撃条件が成立するかと、ホスト停止時に影響する業務を併せて確認することが大切です。

CVE公式レコードは、影響するコードがLinux 2.6.27にさかのぼることを示しています。各安定版系列で修正を含むバージョンとして、5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.57、7.2.11が記載されています。ただし、企業向けディストリビューションには、従来のカーネルを維持したまま修正を取り込むバックポートがあります。例えばAlmaLinuxは8、9、10向けに、それぞれのパッケージ体系で修正版を案内しています。上流Linuxのバージョン番号との大小比較だけで、対策済みかどうかは決められません。

提供段階にも注意が必要です。AlmaLinuxの2026年10月16日付発表では、AlmaLinux 8、9、10向けの修正カーネルがtestingリポジトリで提供されており、10月21日時点でも公式発表に本番向けリポジトリへの移行は記載されていません。また、Ubuntuの公式情報では、主要なlinuxパッケージの対応状況が「Needs evaluation（評価待ち）」となっています*3。脆弱性の修正コードが公開されていても、利用製品の本番向け更新が提供されているとは限らないため、各ベンダーの最新情報を確認する必要があります。

ホストの更新を完了し対応状況を残す

対策の基本は、修正が適用されたホストカーネルへの更新です。AlmaLinuxは更新後の再起動と、稼働カーネルの確認を案内しています。仮想化ホストの再起動はゲストにも影響するため、事前にVMの移行や停止を計画する必要があります。運用では、利用している製品とホストの一覧に、ベンダーが示す修正版、更新の実施日、更新後に稼働しているカーネルをひも付けて管理すると、確認漏れを減らせます。クラウドサービスを利用していてホストを直接管理できない場合は、サービス提供者の案内と契約上の管理範囲を確認し、必要に応じて対応状況を問い合わせてください。

暫定策を採用するときも、適用条件の確認が欠かせません。CloudLinuxはチェックサムオフロードの無効化などを紹介していますが、部分的かつ未検証の緩和策と明記しています*4。設定変更を修正済みカーネルへの更新と同等に扱わず、利用製品の案内に従って判断する必要があります。

AIを活用した研究でも確認の中心は実証結果

研究者は、PwnEscapeの調査でAIを利用したと説明しています*5。人間が研究の方向付けや検証を主導し、AIをソースコードの解析や攻撃経路の検討に活用したという内容です。今回の事例は、研究者がAIを活用して脆弱性の発見や検証を進めたものです。AIが自律的に本番環境を侵害した、という説明にはなっていません。企業側の対応では、発見手法への注目に加え、どの製品に影響するか、どこまで実証されたか、修正は提供されているかを追う必要があります。今回のように評価や提供状況が資料ごとに異なるケースでは、情報源と確認日を残すことが、その後の判断を支えます。

脆弱性情報の収集と対応管理を支えるBBSecのSAS

脆弱性情報を見つけた後は、自社に関係する製品を選別し、必要な対応とその進捗を管理することが重要です。ブロードバンドセキュリティ（BBSec）の「脆弱性情報提供　SAS（Secure Net Alert Mail Service）」は、登録したシステム情報を基に必要な脆弱性情報を絞り込み、メールと管理画面で提供します。脆弱性ごとの対応ステータス管理や、環境に応じた脅威判定に用いるCVSS計算機能も備えています。日本語の情報を重視するベーシック、情報の早さを重視するエクスプレスなど、運用に合わせたプランを選べます。入手した情報への対応方法については、セキュリティ・アドバイザリのオプションで助言を受けることもできます。

さらに、対応計画や社内ルールを含めて体制を見直したい場合には、BBSecの「情報セキュリティ・アドバイザリ」が、現状の把握、実施計画のレビュー、対策推進への助言を通じて支援します。脆弱性情報の収集負担や対応管理に課題がある方は、SASの活用と併せてご相談ください。

PwnEscapeへの対応では、まず自社またはサービス提供者が管理するホストの修正状況を確認することが出発点です。担当者と対応期限を定め、修正版への更新が実際の稼働環境に反映されたところまで追跡してください。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

IDCFクラウドへのランサムウェア攻撃がJR東日本グループにも影響 ―情報漏洩の調査結果と事業継続の課題

Share
IDCFクラウドへのランサムウェア攻撃がJR東日本グループにも影響アイキャッチ画像

クラウドへのサイバー攻撃は、サーバーの停止にとどまらず、サービスを利用する企業の顧客対応や情報管理にも影響します。2026年10月9日、JR東日本とビューカードは、IDCフロンティアへの不正アクセスに伴うメール配信への影響と、個人情報が漏洩した可能性を公表しました。その後、10月15日には、両社とも個人情報の漏洩はなかったと判断した旨の報告を受けたと発表しています。一方、クラウド基盤の障害は多くの利用企業に影響し、バックアップや復旧体制の重要性を浮き彫りにしました。本記事では、各社の公表資料をもとに、クラウド利用企業が点検したい情報保護と事業継続の課題を整理します。

※本記事は2026年10月19日時点で公表されている情報をもとに作成しています。

IDCFクラウドの障害と 利用企業への影響

IDCフロンティアは10月8日の第3報で、10月7日未明から発生した障害の原因を、第三者によるランサムウェア攻撃と説明しました。対象はIDCFクラウド東日本リージョン1の一部で、仮想サーバーの停止や再起動できない事象が発生し、利用する495の企業・自治体に影響したとしています。同社は対象環境の顧客データについて取り出しや復元が困難との見通しを示していました。しかし、10月14日の第5報では、スナップショット機能を利用していた194顧客について、バックアップデータの取り出しが可能であることを確認したと発表しました。対象となる495の企業・自治体のうち、これらの顧客には復元の可否やデータの提供方法について個別に連絡しています。

また、第5報では、障害の影響を受けた仮想サーバー内のデータについて、外部への持ち出しを示す痕跡などは確認されず、データ流出はなかったと判断したことを公表しました。一方、IDCFクラウドポータルでは48社の登録情報に対する不正な照会が確認されています。ただし、これらの情報が外部へ持ち出された痕跡は確認されていません。

10月9日の第4報では、親会社のソフトバンクと連携した対応体制を公表しています。さらに、10月18日の第6報では、安全性を確認した「IDCFクラウド バックアップ」の提供再開を発表しました。なお、スナップショット機能は引き続き提供を停止しています。IDCFクラウド TypeSとIDCFプライベートクラウドは、本事象の対象外とされています。

えきねっと・大人の休日倶楽部・VIEW’s NETへの影響と調査結果

JR東日本は10月9日、えきねっと会員約167万件、大人の休日倶楽部会員約39万件を対象に、個人情報が漏洩した可能性を公表しました。メール配信用外部サービスが一部利用できなくなり、メールアドレスを含む電子メールログデータなどが閲覧・取得された可能性を否定できないとしていました。対象情報は、えきねっとではメールアドレス、大人の休日倶楽部ではメールアドレス、会員番号、クレジットカード有効期限、生年月日です。ただし、10月15日には、メール配信用外部サービス会社から、これらの個人情報の漏洩はなかったと判断した旨の報告を受けたと発表しています。

またビューカードも10月9日、VIEW’s NET登録者向けメール配信への影響と、約403万件のメールアドレスが漏洩した可能性を公表しました。その後、10月15日には、メールアドレスの漏洩はなかったと判断した旨の報告を受けたと発表しています。

図：JR東日本・ビューカードが当初公表した漏洩可能性の対象件数

えきねっと約167万件、大人の休日倶楽部約39万件、VIEW’s NET約403万件の対象情報の違い。単純合計は延べ約609万件でいずれも漏えい可能性。
出典：JR東日本・ビューカードの2026年10月9日および10月15日の公表資料をもとに弊社作成
※件数は2026年10月9日時点で漏洩の可能性があると公表された情報の単純合計であり、実際の漏洩件数や重複を除いた人数ではありません。
※2026年10月15日、JR東日本およびビューカードは、個人情報の漏洩はなかったと判断した旨の報告を受けたと発表しています。

メールログも 保護すべき顧客情報として扱う

今回、JR東日本は当初、電子メールログデータなどが閲覧・取得された可能性を公表しました。その後、個人情報の漏洩はなかったと判断した旨の報告を受けたと発表していますが、顧客情報の保護を考えるうえでは、会員データベースだけでなく、メール配信に利用する外部サービスやログも確認対象となります。NCSCのクラウドセキュリティ原則でも、認証情報や設定情報に加え、ログや派生するメタデータを保護する重要性が示されています。

自社で見直す際には、どのログに個人情報が入るのか、誰が閲覧できるのか、どの目的でどれだけ保存するのかを整理します。業務記録として残す情報と、事故調査のために必要な監査記録を把握し、漫然と蓄積しない運用へつなげることが実務上のポイントです。同時に、調査に必要な記録まで消してよいわけではありません。NCSCは、監査情報の入手方法や保存期間を確認し、改ざん・削除から保護することを求めています。ログは情報資産であり、事故を調べる証拠でもあるため、保存と保護の両方を設計する必要があります。

バックアップは 使えない状況を想定して確かめる

IDCフロンティアは当初、対象環境の顧客データの取り出しや復元は困難との見通しを示していましたが、10月14日の第5報では、一部顧客のバックアップデータを取り出せることが確認されました。さらに、10月18日には「IDCFクラウド バックアップ」の提供再開が公表されています。この経過は、バックアップの有無だけでなく、障害発生時に実際に利用できるかを確認する重要性を示しています。自社の備えを点検する際は、元の環境が停止した状態でもバックアップを取り出し、復元できるかを確かめる必要があります。

NCSCのSaaS利用ガイダンスでは、重要データの保護されたバックアップを持つことに加え、元のデータを襲った事故が全バックアップにも及ばない構成を求めています。自社のクラウド運用へ応用するなら、保管先の分離だけでなく、バックアップを操作できる権限や認証への依存も点検対象です。復旧の手順には、別環境を誰が準備するか、どの時点のデータへ戻すか、業務再開を誰が承認するかまで含めます。実際に取り出して復元し、業務が動くところまで確認して初めて、計画の不足が見えてきます。サイバー攻撃では原因調査や封じ込めと復旧を調整する必要があるため、通常の機器故障と同じ手順でよいかも見直したい点です。

配信停止時の顧客対応と 漏洩調査を並行する

メール配信ができない場合、案内する内容だけでなく、伝える手段の確保が課題になります。企業の対応計画では、顧客向けメールの停止と情報漏洩の疑いが同時に起きる場面を想定し、公式サイトなどの代替窓口と、問い合わせを受ける担当を定めておきます。

利用者への案内では、確定した情報と調査中の事項を区別することが重要です。今回、JR東日本とビューカードは当初、個人情報の漏洩の可能性を公表しましたが、その後の調査結果を受けて、漏洩はなかったと判断した旨を追加公表しています。このように、調査の進展によって公表内容が変わる場合もあるため、利用者に最新の状況を正確に伝える体制が必要です。また、対象者への通知では、正規の案内かどうかを確認できる方法を示すことも大切です。クラウド事業者の復旧報告を待つだけでなく、自社の顧客対応をどの条件で進めるか決めておく必要があります。

BBSecのIT-BCP策定支援で 復旧できる計画へ

クラウド利用を前提にした事業継続計画では、利用環境の停止、データの復元、顧客への連絡を一緒に検討します。ブロードバンドセキュリティ（BBSec）の「ランサムウェアに対応したIT-BCP策定支援」は、サイバー攻撃を想定したIT-BCPの策定・見直しを支援するサービスです。現状のシステム分析を踏まえた計画策定支援や、企業主体の取り組みにコンサルタントが伴走するメニューを提供しています。また、復旧段階を中心とした「IT-BCP発動演習ワークショップ」もあります。[8] 自社の計画にクラウド停止を織り込めているか、バックアップからどの手順で業務を戻すかを具体化したい場合は、BBSecへご相談ください。平時の計画と演習を通じて、判断や作業が止まる箇所を明らかにしておくことが、事業継続への備えになります。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る