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では高い権限を持つ識別情報が利用されることがあり、実行基盤の保護、資産・バージョン管理、最小権限が重要だと説明しています*1。

したがって、管理対象は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に戻る

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

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

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

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

緊急パッチ必須:SharePoint「TOOLSHELL」攻撃を招くCVE-2025-53770/53771の実態

Share

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

Microsoft SharePointを運用する企業が見過ごせない脆弱性が今月、相次いで公開されました。7月14日に累積パッチで修正されたCVE-2025-53770とCVE-2025-53771は、ViewStateキー生成処理の競合状態を突いて、認証なしのリモートコード実行(RCE)をするクリティカルな脆弱性です。さらに、6月に報告済みのASPXテンプレート挿入系脆弱性CVE-2025-49704/49706を組み合わせた「TOOLSHELL」攻撃チェーンが現実化し、Unit 42とEye Securityは侵入後にPowerShell WebShellが配置される事例を確認しています。本稿では影響範囲と優先すべき対策を解説します。

お問い合わせ

お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。

なぜCVE-2025-53770が危険なのか

問題の本質は、SharePointが__VIEWSTATEを検証する際に用いるValidationKeyの競合状態にあります。攻撃者は未認証のまま細工したViewStateを送信し、LosFormatterのデシリアライズ処理を経由して任意コードを実行できます。Microsoftは「7月パッチ以前の修正は十分ではなく、今回の累積更新で初めて完全な防御が可能になる」と明言しました。

「TOOLSHELL」攻撃チェーンが示す実戦的リスク

Eye Securityが命名した「TOOLSHELL」攻撃では、まずCVE-2025-49706がRefererヘッダーを悪用してToolPane.aspxへ非認証アクセスを可能にし、続いてCVE-2025-49704がデシリアライズ経路を開きます。ここにCVE-2025-53770とCVE-2025-53771が結合すると、防御側が認証やCSRFトークンに依存していた場合でもRCEが成立します。侵入後はPowerShellでWebShell(spinstall0.aspxなど)が配置され、MachineKeyを窃取して永続化を図る点が確認されています。

CISAの緊急指令と企業が取るべきステップ

米国CISAは53770をKnown Exploited Vulnerabilitiesカタログに追加し、7月31日までのパッチ適用を連邦機関に義務付けました。官民問わず、以下のようなステップで対策を進めましょう。

  • SharePoint Server 2016/2019/Subscription Editionで最新の7月累積パッチを適用
  • 適用後にMachineKey(ValidationKey/DecryptionKey)を再生成し、漏えい済みの署名を無効化
  • Microsoft Defender AntivirusとのAMSI統合と「ViewState暗号キー管理」機能を有効化し、未署名ViewStateの読み込みを防ぐ
  • 管理ポートや/_layouts/配下を外部公開している場合は即時閉鎖し、Web Application FirewallやHIPSでUploadFilterを強制

残る課題―公開PoCと横展開

GitHub上には既に53770の概念実証コードが複数公開されており、Rapid7も実環境での悪用を観測したと報告しました。パッチを当ててもMachineKeyのローテーションを怠れば、攻撃者は署名済みの__VIEWSTATEを再利用して“再侵入”できます。特にTeamsやOneDriveと連携したハイブリッド環境では、SharePointから取得した認証トークンが横展開に利用されかねません。

まとめ

サイト運営者は最新パッチ情報を迅速に発信しつつ、自社環境の防御態勢を見直す必要があります。累積更新プログラムの適用とキー再生成を完了して初めて、SharePointは安全な状態に戻ります。多くの組織が抱えるオンプレミスSharePointは依然として攻撃者にとって魅力的な標的であり、今回の一連のゼロデイは“パッチ管理とキー運用の両立”という運用課題を改めて突きつけたといえるでしょう。

【参考情報】

  • https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53770
  • https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53771
  • https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-49706
  • https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-49704
  • https://msrc.microsoft.com/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770/
  • https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-sharepoint-server-2019-july-8-2025-kb5002741-d860f51b-fcdf-41e4-89de-9ce487c06548
  • https://research.eye.security/sharepoint-under-siege/
  • https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel/blob/main/2025-07-19-Microsoft-SharePoint-vulnerabilities-CVE-2025-49704-and-49706.txt
  • https://www.cisa.gov/news-events/alerts/2025/07/20/cisa-adds-one-known-exploited-vulnerability-cve-2025-53770-toolshell-catalog
  • Security NEWS TOPに戻る
    バックナンバー TOPに戻る

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

  • 2025年8月5日(火)14:00~15:00
    「企業サイトオーナー向け ユーザーからのレピュテーションを高めるWebサイトの在り方-Webサイトを取り巻くリスク・規制・要請とユーザビリティ向上-」
  • 2025年8月20日(水)13:00~13:30
    「EC加盟店・PSP必見!クレジットカード・セキュリティガイドライン6.0版対応ウェビナー」
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

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