タグ: 脆弱性

投稿日:

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に戻る

投稿日:

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を悪用しようとする攻撃を観測したと報告しています*7。これは脆弱性の詳細が公表される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に戻る

投稿日:

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に戻る

投稿日:

WordPressの脆弱性CVE-2026-87902で攻撃を観測 ―更新と侵害確認のポイント

Share
WordPress CVE-2026-87902の対策アイキャッチ画像

WordPressの脆弱性「CVE-2026-87902」を狙い、PHPファイルの書き込みやコード実行につなげようとする攻撃が観測されています。WordPressは2026年9月22日に修正版7.1.2を公開し、速やかな更新を推奨しています*6。サイト運用者は修正版を適用するとともに、更新前に不正アクセスを受けていなかったか確認することが重要です。

CVE-2026-87902とは何か

CVE-2026-87902は、ページテンプレートの解決処理に存在するパストラバーサルの脆弱性です。認証されていない攻撃者が、利用中のテーマのディレクトリ外にある、読み取り可能なローカルPHPファイルを処理に取り込ませることができます。テーマとサーバー側の条件が重なると、リモートコード実行（RCE）につながる可能性があります。

影響条件には、有効な親テーマまたは子テーマの直下にpage-で始まるディレクトリがあることと、Webサーバーの実行アカウントから読み取り可能な対象PHPファイルが存在することなどが含まれます。公式情報では、PEARに含まれるpearcmd.phpと、PHP設定のregister_argc_argvがOnになっている環境を、RCEに至る経路の一つとして挙げています。[2] したがって、WordPressを使用しているという理由だけで、すべてのサイトで同じようにコード実行が成立するわけではありません。一方で、テーマやPHP環境を確認できていない段階で、自社サイトを影響対象外と判断することも避ける必要があります。

図1：CVE-2026-87902の成立条件と影響

出典：WordPress「GHSA-7hp8-65ch-5whp」（https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-7hp8-65ch-5whp）をもとに作成
※ローカルPHPファイルの読み込みからRCEに至るには追加の条件があり、pearcmd.php経由の例ではregister_argc_argv = Onであることが条件となります。

7.1.1への更新だけでは今回の対策にならない

CVE-2026-87902は、WordPress 7.1系列だけの問題ではありません。公式アドバイザリでは、7.1系列の影響範囲を7.1.0～7.1.1、修正版を7.1.2としています。また、旧系列にも修正版が提供されており、例えば7.0系列は7.0.6、6.9系列は6.9.9で修正されています。利用中のWordPressの系列と、公式アドバイザリに掲載されている修正版の一覧を照合する必要があります*2。更新作業を外部の制作会社や保守会社に任せている場合は、「対応しました」という連絡だけでなく、適用後のバージョンと実施日時も共有してもらうと管理しやすくなります。自動更新を利用しているサイトでも、処理が完了しているかを実際に確認しておきましょう。WordPress公式は、管理画面の更新機能に加え、対応している環境では自動バックグラウンド更新が開始されると案内しています。

観測された攻撃と侵害成功を区別して読む

Patchstackは2026年9月23日の更新で、単なる脆弱性の探索に加えて、pearcmd.phpを介して攻撃者が用意したPHPの内容をファイルへ書き込もうとするリクエストを報告しています*3。観測されたペイロードには、動作確認用の文字列を残すもののほか、アクセス時にシェルコマンドを実行させるものも含まれていました。これは、CVE-2026-87902を狙った実際の悪用活動が行われていることを示す報告です。一方で、Patchstackが観測したリクエストが、そのまますべての対象サイトで侵害に成功したことを意味するわけではありません。自社サイトについては、攻撃リクエストが到達していたか、ファイルが作成されていないか、コードが実行されていないかをそれぞれ確認する必要があります。

調査の手掛かりとして、Patchstackはpagenameに不審なトラバーサル表現を含むリクエストや、pearcmd、config-show、config-createに関係する痕跡、/tmpや/var/tmpに作成された不審なPHPファイルなどを挙げています。これらは、担当者がログやファイルを確認する際の手掛かりです。該当する語句やファイルが存在することだけで侵害を断定することはできません。また、ログの保存期間や取得対象によっては記録そのものが残っていない場合もあるため、該当する痕跡が見つからないことだけで侵害を否定することもできません。

更新と並行して確認したいサイトの状態

サイトに不審な変化が確認された場合は、発見時刻、表示内容、直前に行った運用変更などを記録し、ホスティング事業者や保守会社に連絡します。WordPress公式の侵害対応ガイドでも、状況を記録することやホスティング事業者に確認すること、クリーンアップ前に環境のスナップショットを保存することなどが案内されています*4。原因を調べる前に不審なファイルを一括して削除すると、侵入経路や影響範囲を確認するための情報を失う可能性があります。そのため、不正アクセスが疑われる場合は、修正や削除を進めるだけでなく、必要な記録やデータを保存することも検討します。

実務では、更新を行う担当者と、侵害の有無を確認する担当者を明確にしておくことも重要です。更新によって脆弱な処理を修正できても、すでに追加された不審なファイルや不正なアカウントの有無は別途確認する必要があります。調査によって侵害が判明した場合は、影響範囲を把握したうえで封じ込めを進め、復旧後の認証情報の変更や再発防止策も含めて対応を検討します。

図2：更新と侵害確認を並行して進める対応例

出典：WordPress 7.1.2 Release（https://wordpress.org/news/2026/09/wordpress-7-1-2-release/）および「FAQ My site was hacked」（https://wordpress.org/documentation/article/faq-my-site-was-hacked/）をもとに作成。
※封じ込め・証拠保全・更新の具体的な順序は、被害状況に応じて判断します。

日常のWordPress運用に残したい対策

今回の対応を終えた後は、誰がどのサイトを管理しているか、更新情報を誰が受け取るかまで見直しておきましょう。例えば、コーポレートサイトとは別に運用している採用サイトやキャンペーンサイトについても、同じ管理台帳で確認できるようにしておくと、脆弱性が公表された際に対象サイトを探すところから始めずに済みます。WordPress公式のセキュリティ強化ガイドでは、WordPress本体やサーバ側ソフトウェアを最新の状態に保つこと、アクセスを適切に制限すること、データベースやファイルをバックアップすることなどが案内されています*5。実務では、バックアップを取得しているかだけでなく、復元に必要なデータがそろっているか、復旧を依頼する連絡先が明確になっているかまで確認しておくことが重要です。

侵害が疑われる場合はBBSecの緊急対応支援へ

不審なPHPファイルが見つかった、サイトが改ざんされた、更新前に侵害されていなかったか自社だけでは判断できない、といった場合には、BBSecのデジタルフォレンジックを含む緊急対応支援をご相談いただけます。デジタルフォレンジックは、サーバや端末などに残されたデータを調査し、何が起きたのかを明らかにするための調査です。BBSecでは、インシデント発生時の事象把握、証拠保全・データ収集、原因調査、再発防止に向けた事後対策方針の検討などを支援しています。

緊急コンタクトセンターでは、取引の有無にかかわらず24時間365日相談を受け付けています。相談時には、対象サイト、利用しているWordPressのバージョン、異常を発見した時刻、すでに実施した作業などを整理しておくと、状況を伝えやすくなります。

BBSec緊急コンタクトセンター連絡先電話番号
※外部サイトにリンクします。

平時の対策や復旧後の見直しには、Webアプリケーション・API脆弱性診断「SQAT® for Web」を活用できます。自動ツールによる診断とエンジニアによる手動診断を組み合わせ、攻撃の入口となる可能性のある問題箇所を確認するサービスです。脆弱性診断と、過去の侵害状況を調べるデジタルフォレンジックでは目的が異なります。すでに侵害が疑われている場合は、まず現在の状況や懸念点を伝えたうえで、ブロードバンドセキュリティ（BBSec）までご相談ください。

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

【参考情報】

編集責任：木下

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

最新情報はこちら

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

投稿日:

デジタル庁GSSに不正アクセス ―約24.6万件の情報漏洩の可能性と企業の対策

Share
デジタル庁GSSに不正アクセス ―約24.6万件の情報漏洩の可能性と企業の対策アイキャッチ画像

デジタル庁は2026年9月11日、ガバメントソリューションサービス（GSS）への不正アクセスにより、職員や業務関係者の個人情報約24.6万件が漏洩した可能性があると公表しました*6。今回の事案では、VPN機器の既知の脆弱性が悪用され、保守運用担当者のアカウントを利用した大量のファイルアクセスが検知されています。本記事では、公表情報をもとに事案の経緯と影響を整理するとともに、企業が脆弱性管理やセキュリティログ監視で見直したいポイントについて解説します。

GSS不正アクセスの検知から公表までの経緯

GSSは、デジタル庁が運用し、各府省庁などが業務に利用するサービスです。今回の調査は、6月25日に保守運用担当者のアカウントによるサーバー上の大量ファイルアクセスを検知したことから始まりました。VPN機器の脆弱性を使って第三者が侵入していたと判明したのは7月9日です。同日、当該アカウントを停止し、侵害された機器と外部との通信を遮断したと説明されています。6月25日は検知日であり、侵入開始日を示すものではありません。7月15日に個人情報保護委員会へ報告し、対象者や情報の内容の調査を進めたうえで9月11日に公表しました。

公式Q&Aによると、影響範囲や侵入経路、漏えいした可能性のある情報の特定に時間を要したとしています。公表時点では、修正プログラムの適用や関係アカウントの認証情報変更、通信遮断などの措置を実施済みで、その後、新たな不正アクセスや不審な通信は確認されておらず、政府業務への支障も生じていないと説明しています。*2。

図1：GSS不正アクセスの検知から公表まで

出典：デジタル庁「ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について」（https://www.digital.go.jp/news/2026-0911-01）および「ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について」に関するQ&A」（https://www.digital.go.jp/press/5fc99139-a4e2-4b7b-8b0c-d475e926143f）を基に作成

約24.6万件の個人情報が漏洩した可能性

約24.6万件の内訳は、GSS利用機関の職員や業務に携わった公務員等の情報が約18.9万件、業務に携わった事業者や個人の情報が約5.7万件です。漏洩した可能性のある個人情報には、氏名、メールアドレス、電話番号、住所などが含まれます。属性別では、氏名が約23.6万件、メールアドレスが約23.1万件、電話番号が約9.4万件、住所が約0.1万件とされています。これらの属性には重複があるため、単純に合計することはできません。

デジタル庁は、一般の国民の個人情報や、マイナンバー、金融機関口座情報、年金番号は含まれないと説明しています。ただし、公務員以外でも、関係省庁の業務に携わった企業の従業員や個人事業主などは対象に含まれます。また、約24.6万件すべてについて、外部への持ち出しが確認されたわけではありません。不正アクセスの痕跡があり、漏えいの可能性を否定できない情報も対象にした数字です。9月14日時点で確認した公表資料では、関連する二次被害は確認されていません。

深刻度「中」でも悪用

今回の脆弱性は、攻撃が確認される前に公表されていた既知の問題でした。デジタル庁は、当初の深刻度評価に応じた一般的対応より早く対処を進めたものの、修正プログラムの適用前に悪用されたと説明しています。この情報だけで、脆弱性を把握していなかった、あるいは放置していたとは判断できません。VPN製品名やCVE番号なども公表されていません。企業で見直したいのは、脆弱性の深刻度と、自社での対応優先度をつなぐ判断です。

CVSSを管理するFIRSTは、CVSSの基本評価値は脆弱性そのものの深刻度を表し、単独でリスク評価に使うべきではないと説明しています*3。利用環境や脅威の状況を加えて評価する考え方が、公式ガイドに示されています。

これを自社の運用に落とし込むなら、スコアの横に「どこから接続できる機器か」「侵害された場合に何へアクセスできるか」「業務や情報にどのような影響があるか」を記録する方法が考えられます。同じ深刻度でも、外部から接続できるVPNと、接続元を限定した機器では、確認すべき条件が異なります。これは今回のGSSの詳細構成を推定する話ではなく、自社で優先順位を判断するための実務上の整理です。パッチ適用に調整が必要な場合は、ベンダーが示す回避策や接続制限の適用可否も併せて検討します。その際、「次回メンテナンスで更新する」という予定だけで終わらせず、更新までに残るリスクと担当者、再判断の条件を記録しておくと、悪用情報が追加された際の見直しにつなげやすくなります。

図2：脆弱性対応の優先順位を考える視点

出典：FIRST「CVSS v4.0 User Guide」、デジタル庁「本事案に関するQ&A」をもとに弊社作成
※GSSの実際の運用・判断手順を示すものではありません。

保守アカウントを信頼しきらず、操作の実態を確かめる

もう一つの論点が、保守運用担当者のアカウントを通じたアクセスです。今回の公表資料では、アカウントをどのように悪用できる状態にしたのか、認証情報をどう取得したのかまでは明らかにされていません。パスワードの使い回しや多要素認証の未導入が原因だった、と断定することはできません。

企業側で検討したいのは、認証の成否に加え、アクセス後の行動を確認できる状態です。例えば、保守作業の予定と実際のアクセス時刻を照合し、対象サーバー、操作内容、ファイルへのアクセス量が作業目的と整合するかを確認する、といった運用が考えられます。大量アクセス自体には正当な作業もあるため、件数だけで不正と決めつけず、普段の利用や作業申請と照らし合わせることが大切です。その判断を支えるのが、VPNの接続記録、認証ログ、サーバーの監査ログなどです。NISTのログ管理ガイドでは、ログ管理の基盤整備や、組織全体で継続的にログを管理するプロセスの構築について示しています*4。

企業では、必要なログを取得・保存するだけでなく、複数のログを時系列で確認できる状態を整え、異常を検知した際の対応や役割分担まで含めて運用を設計することが重要です。

ゼロトラストも、日々の脆弱性管理と監視が土台になる

GSSはゼロトラストアーキテクチャを採用していたと説明されています。ただし、具体的な構成や対策は非公表です。今回の事案だけから、ゼロトラスト全体の有効性や、特定の対策が機能しなかった理由を評価することはできません。NISTはゼロトラストを、ネットワーク上の場所や資産の所有者だけで、利用者や機器を暗黙に信頼しない考え方として整理しています*5。

企業が確認すべきなのは、自社でどのアクセスを検証し、どこまでを許可し、どの記録から異常を判断できるかです。VPNの更新、アクセス権限の確認、ログ分析を、導入した製品や構成に合わせて継続する必要があります。

BBSecのログ分析・活用支援で、確認できる範囲を広げる

「ログは保存しているが、保守アカウントの不正利用をどう見つけるか決まっていない」。そうした課題には、取得対象と分析目的の整理から取り組む方法があります。BBSecの「セキュリティログ分析／活用支援」は、蓄積したログの分析から、ログ取得環境の整備に向けたコンサルティング、Splunkを用いた統合ログ管理・分析環境の構築、運用までを支援するサービスです。現状の管理ポリシー、取得状況、体制、運用プロセスを確認し、改善プランを検討しましょう。自社のVPNや認証基盤、サーバーについて、取得するログと検知したい事象を具体化すれば、追加すべき記録や運用上の課題を検討できます。既存ログの活用や分析環境の見直しを進めたい企業は、BBSecにご相談ください。

【参考情報】

編集責任：木下

セキュリティ対策についてお困りの方へ

自社のセキュリティ対策についてお悩みの場合は、ブロードバンドセキュリティ（BBSec）までお気軽にご相談ください。

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

最新情報はこちら

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

投稿日:

Cisco FMCの脆弱性が実悪用 ―Qilinランサムウェアへの悪用事例と対策

Share
Cisco FMCの脆弱性が実悪用アイキャッチ画像

Cisco Secure Firewall Management Center（FMC）の脆弱性を悪用した攻撃が確認されています。FMCはファイアウォールなどを集中管理する製品であり、侵害された場合には、管理基盤だけでなく組織内のシステムへの影響も確認する必要があります。本記事では、FMCに影響する2件の脆弱性の概要と、実際の攻撃で確認された活動を整理し、企業が進めるべき確認と対応について解説します。

※本記事は2026年9月16日時点で公開されている情報に基づき作成しています。

Cisco FMCはファイアウォールなどを集中管理する製品

2026年9月9日、Cisco Talosは、Cisco Secure Firewall Management Center（FMC）の2件の脆弱性が実際の攻撃で悪用されていると公表しました*6。確認された攻撃活動には、FMCへの侵入後に組織内の端末へQilinランサムウェアを展開した事例も含まれています。

FMCは、Ciscoのファイアウォールや侵入防御などを集中管理するための製品です。通信の許可・遮断、アプリケーション制御、脅威への対策といったポリシーを管理し、ネットワークで起きている事象を分析する役割を持ちます*2。この役割を踏まえると、管理基盤の安全性は、配下の機器を運用するうえでの前提になります。業務用サーバーの更新計画に加え、管理者が使うセキュリティ製品そのものについても、利用バージョン、アクセス経路、管理権限を把握する必要があります。

また、「Cisco製のファイアウォールを利用している」という情報だけでは影響を判断できません。今回の対象はFMCソフトウェアなど、公式アドバイザリが指定した製品です。Ciscoは両脆弱性について、Secure Firewall ASA Software、Secure Firewall Threat Defense（FTD）Software、Firewall Device Manager（FDM）は影響を受けないとしています。管理対象の機器と、その機器を管理する製品を分けて確認しましょう。

※なおCVE-2026-20079については、Cisco Security Cloud Control（SCC）Firewall Managementも対象ですが、SaaSとしてCisco側ですでに修正済みで、ユーザーによる対応は不要とされています。

CVSS 10.0と5.3 二つの脆弱性の違い

CVE-2026-20079は、FMCのWebインターフェースにおける認証回避の脆弱性です。認証されていない遠隔の攻撃者が認証を回避し、影響を受ける装置でスクリプトを実行して、OSのroot権限を取得できる可能性があります。CVSS v3.1基本値は10.0です。rootはOSにおける強い管理権限であり、管理基盤そのものを操作される問題として受け止める必要があります。

CVE-2026-20316は、低権限アカウントの静的な認証情報が存在することに起因する脆弱性です。認証されていない遠隔の攻撃者がそのアカウントでログインし、機微なデータへアクセスできる可能性があります。CVSS v3.1基本値は5.3ですが、Ciscoは他のFMCの脆弱性と組み合わせて権限昇格に利用できることから、独自の深刻度分類では「High」と評価しています。ここで判断を誤りやすいのが、5.3という数字を見て対応を後回しにすることです。今回のように実悪用が確認され、別の問題と組み合わされると影響が広がる場合は、基本値だけでは優先順位を決められません。ベンダーによる評価の理由と、実際の攻撃での利用状況まで読むことが大切です。

図1：FMCの脆弱性悪用と侵害後の活動

出典：Cisco Talos「Active exploitation of Cisco Secure Firewall Management Center vulnerabilities」（https://blog.talosintelligence.com/fmc-ongoing-exploitation/）を基に弊社作成

Qilinランサムウェアの侵入経路は静的認証情報の悪用

Talosは、FMC上で確認した侵害後の活動を3つの群に分けています。UAT-12197はCVE-2026-20079を悪用し、Webシェルなどを設置して認証情報を窃取していました。UAT-11823では2件の脆弱性の悪用が確認され、管理対象機器の設定情報収集や、Cyclops Blinkの亜種の展開などが観測されています。Qilinランサムウェアの展開が確認されたのは、これらとは別のUAT-11988です。この群はCVE-2026-20316に関係する静的認証情報でFMCに入り、正規の組み込みツールを悪用して内部環境を調査しました。認証情報の窃取や接続経路の確保を経て、端末へQilinを展開しています。

修正プログラムの適用と侵害調査を進める

今回の対応では、FMCを修正版へアップグレードすることと、すでに侵害されていないかを確認することを分けて考える必要があります。まず、実際に運用しているFMCのバージョンを把握し、Ciscoが公開しているCVE-2026-20079とCVE-2026-20316のセキュリティアドバイザリに記載された「Fixed Software（修正版）」と照合してください。Ciscoは、これらの脆弱性への修正を含むハードニングリリースを公開しており、影響を受ける環境について、該当する修正版へのアップグレードを推奨しています。利用しているバージョンによって適切な更新先が異なるため、最新の公式アドバイザリを確認したうえで対応を進めることが重要です。さらに、すでに侵害されていないかを調べます。Ciscoは、対象ログにあるpackage_info関連の実行記録に、/var/tmp/license.tmpが含まれる場合を、悪用の可能性を示す確認ポイントとして挙げています。単に同名のファイルを探すだけではなく、公式に示されたログの文脈で確認し、侵害が疑われる場合はCisco TACへ速やかに連絡するよう求めています。

修正版へのアップグレードは今後の悪用を防ぐために重要ですが、すでに侵害されていないことを証明するものではありません。Ciscoも、侵害が疑われる場合はCisco TACへ連絡し、復旧に関する案内に従うよう求めています。「更新済み」の記録を付ける担当と、侵害の可能性を判断する担当が異なる場合は、両者の確認結果を一つの対応記録で共有すると、調査の抜けを防ぎやすくなります。

図2：修正版へのアップグレードと侵害調査 それぞれの目的

出典：Cisco「Cisco Secure Firewall Management Center Software Authentication Bypass Vulnerability」（https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-onprem-fmc-authbypass-5JPp45V2）「Cisco Secure Firewall Management Center Software Static Credential Vulnerability」（https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fmc-static-cred-BET3Cjh）を基に弊社作成

管理装置の復旧だけで対応を終えないために

侵害の疑いがあるときは、FMCだけを調べて完了とする判断は慎重に行う必要があります。今回の事例を踏まえた実務上の確認事項は、FMCで何が実行されたか、そこからどのシステムに接続できたか、認証情報の悪用がほかの環境に及んでいないか、という範囲です。これはすべての利用組織に同じ被害があるという意味ではなく、自社の接続関係と調査結果に沿って影響範囲を確かめるための考え方です。復旧を急ぐ場面でも、調査に必要なデータをどう確保するか、どこまでの通信を止めるか、どの状態をもって安全に再開できると判断するかを、保守担当者や専門家と共有する必要があります。連絡先だけでなく、判断する責任者と、判断に必要な情報を平時に定めておけば、発生後の対応に取り掛かりやすくなります。

BBSecの緊急対応支援で、調査から復旧方針の整理へ

不審なログが見つかったものの影響範囲を判断できない場合や、証拠を保全しながら復旧を進める必要がある場合には、専門的な調査や対応が必要になることがあります。BBSecでは「緊急対応支援」を通じて、初動対応やデジタルフォレンジック、原因・影響範囲の調査、復旧に向けた対応などを支援しています。緊急コンタクト窓口は24時間365日受け付けています。

また、インシデント発生に備えて平時から対応体制を整えておきたい企業向けに、「インシデントレスポンス／フォレンジック」を提供しています。契約などの確認を事前に進め、有事の初動を円滑にするための仕組みです。基本契約の締結は無償ですが、フォレンジック調査費用は含まれません。必要な支援範囲を平時から相談し、自社の対応体制につなげておくことができます。

侵害が疑われる場合は、製品固有の対応についてCiscoの案内を確認するとともに、影響範囲の調査やインシデント対応にお困りの場合は、BBSecの「緊急対応支援」へご相談ください。

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

【参考情報】

編集責任：木下

セキュリティ対策についてお困りの方へ

自社のセキュリティ対策についてお悩みの場合は、ブロードバンドセキュリティ（BBSec）までお気軽にご相談ください。

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

最新情報はこちら

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