CISAがGitLab未認証RCE（CVE-2026-97229）の実害悪用を確認—DevOpsの土台を直撃する“即応優先”案件です

今日の深掘りポイント

• 既知の悪用脆弱性（KEV）入りは「攻撃者が回している実弾がある」サインです。露出している自社GitLabは“特急”で棚卸しと対処が必要です。
• 未認証RCE＋CVSS 10は、侵入コストが極端に低く、奪取後の横展開・機密流出・供給網汚染まで一直線につながる型です。検知・封じ込めはホストだけでなく“アプリとCI/CDの状態”に踏み込むべきです。
• 影響はパッチ適用で終わりません。既に盗まれている可能性のあるトークン・鍵・Runner登録情報の棚卸しと強制ローテーションを、更新作業と同列の第一優先に据えるべきです。
• 本件の「正規表現起点」というヒントは、WAFの一般的パターンでは取りこぼす余地を示唆します。入力長や実行時間異常、バックトラッキングの失敗痕など“ふるまい系”の検知を戦術に加えるとよいです。
• 迅速に動ける案件です。露出資産の特定、バージョン分岐ごとのパス、ロールバック・フリーズ条件、機密情報ローテーションの順序立て——運用台本を先に引き直すと混乱が減ります。

はじめに

ソースコード管理は多くの組織にとって「最後に残すべき信頼の源泉」ですが、今日はその源泉を揺さぶる話です。CISAがGitLabの重大欠陥CVE-2026-97229に対する実害悪用を確認し、KEVに追加したと報じられています。未認証RCEは、攻撃者の初期侵入から供給網汚染までを一本で繋げる、いわば“幹線道路”のような欠陥です。パッチ適用はもちろん、供給網の「信頼」を守り直すという視点で、インシデント対応と運用の両輪を回す必要がある局面です。

深掘り詳細

事実関係（いま公開情報から読み取れること）

• CISAはGitLab CE/EEに影響するCVE-2026-97229の実害悪用を確認し、既知の悪用脆弱性カタログ（KEV）に追加したと報じられています。
  • 本欠陥は「特別に作成された正規表現」に起因し、未認証の攻撃者による任意コード実行を許すと説明されています。
  • GitLab側の分類は整数オーバーフロー／ラップアラウンド（CWE-190）で、CVSS v3.1は10.0（クリティカル）です。
  • 影響バージョンは19.2.8未満、19.3.5未満、19.4.2未満とされ、ネットワーク経由での悪用が可能、攻撃の複雑性は低く、特権やユーザー操作は不要という性質です。
• 成功した悪用は機密性・完全性・可用性の全方位に深刻な影響を与えうるため、CISAは迅速な対処を促しています。
  出典: GBHackersの報道

（注）本稿は上記の報道に基づく整理です。読者各位は自組織の意思決定に先立ち、公式アドバイザリやパッチノートの一次情報を必ず確認してください。

編集部のインサイト（運用の現場目線での読み解き）

• 未認証RCEが「KEV入り」した意味
  攻撃者の運用に実装済みで自動スキャンに乗りやすい、という強いシグナルです。攻撃コストが低く、露出面の広いソフトウェアであるほど「踏み台→秘密情報収集→横展開→供給網侵害」の連鎖が速く進みます。GitLabはCI/CDの“要”ゆえ、踏み台化した瞬間の被害半径が大きくなりやすいです。
• 「正規表現×整数オーバーフロー」の示唆
  入力検証やパターン展開の内部処理が絡むと、一般的なシグネチャ型WAFのヒットだけに頼るのは危ういです。実運用では、リクエスト単体の文字列パターンよりも「処理時間の異常延伸」「バックエンド子プロセスの不自然な生成」「エラーログの局所的スパイク」など、ふるまい的な兆候を見る設計が効きます。
• パッチ適用“だけ”では終わらない理由
  GitLabはアプリケーション内にPAT・Deploy Key・Runner登録トークン・Webhookシークレット・クラウド用クレデンシャルなど、機密の“集積地”を抱えます。もし侵害されていれば、更新後も外部環境が継続的に危険に晒されます。したがって、アップグレードと並走で「資格情報の強制ローテーション」「Runnerの再登録」「不要トークンの失効」「新規管理者やHookの不審追加の洗浄」が必要です。
• メトリクスからの総合判断
  即時性・実行容易性・信頼性のバランスが“今すぐ動けば減災できる”タイプであることを示しています。優先順位付けでは、同時期の他の脆弱性よりも先に、外向きに露出したGitLabから手を付ける合理性が高い局面です。

脅威シナリオと影響

以下は編集部の仮説に基づくシナリオです。具体的なTTPは組織環境により変動しますが、初動の想定と猟犬の鼻（ハンティング観点）を合わせる狙いで提示します。

• シナリオA（最短侵入→秘密情報収集→横展開）

  • 初期侵入: 公開GitLabに対して欠陥を突く（MITRE ATT&CK: T1190 Exploit Public-Facing Application）
  • 実行/常駐: OSコマンド/スクリプト実行、簡易リバースシェル（T1059 Command and Scripting Interpreter）
  • 資格情報の獲得: GitLabアプリ内のPAT/Deploy Key/Runnerトークン、CI/CD変数、Webhookシークレットの窃取（T1552 Unsecured Credentials, T1555 Credentials from Password Stores 相当）
  • 永続化: 新規管理者・グループアクセストークンや不審Webhookの作成（T1136 Create Account, T1098 Account Manipulation）
  • 横展開: 盗んだ鍵でGit/SSHやCI/CD Runner経由に別環境へ移動（T1021 Remote Services）
  • 防御回避/痕跡消去: ログ改ざん・一時ファイル削除（T1070 Indicator Removal）
  • 流出/影響: 機密コード・アーティファクト流出、レジストリ汚染、悪性コミット混入（T1041 Exfiltration Over C2 Channel, 供給網の改ざん）

• シナリオB（供給網の信頼破壊）

  • 初期侵入後、CI/CDパイプライン定義やRunnerの実行環境イメージを改変し、将来のビルドにバックドアを注入。目先のデータ窃取よりも「将来の配布物の信頼」を崩す持久戦を選ぶパターンです。影響は顧客・パートナーに波及し、検知と回復に長期戦を強いられます。

影響の広がりは、公開性（インターネット露出の有無）、権限設計（最小権限・分離の徹底度）、資格情報の保管方法（KMSやスコープ制限の有無）、Runnerの配置（自己ホスト/共有/ネット分離）で大きく変わります。自社のCI/CDガバナンス成熟度が、そのまま被害半径の上限を決めると考えると対処の見取り図が描きやすいです。

セキュリティ担当者のアクション

“止血→感染源の治療→再発予防”の三段で並走するのが要領です。以下は優先度順の叩き台です。

• 露出抑制（今すぐできる止血）

  • 公開インターフェースの棚卸し。インターネット直結のGitLabは暫定でIP許可リストやVPN/SSOで絞り込みます。
  • 新規サインアップや外部向けHook/Integrationsを一時的に制限します。
  • リバースプロキシやWAFで、極端に長い入力や異常な遅延を伴うリクエストを暫定ブロック（ふるまい基準）します。

• パッチ計画と適用（源治療）

  • ベンダが提示する修正済みバージョン（19.2.8/19.3.5/19.4.2以降）への更新経路を確定し、バックアップ・スナップショット・ロールバック基準を先に定義します。
  • バージョン分岐（LTS/短期）に応じた適用手順を明文化し、メンテナンスウィンドウを即時確保します。

• 侵害有無のトリアージ（並走必須）

  • OS側: 不審な子プロセス（gitlab-workhorse/ruby/sidekiq配下のsh/bash/python/node等）、新規リスンポート、SUID化、crontab/Timersの変化、急峻なCPU/メモリスパイクの相関を確認します。
  • アプリ側:
    • 新規管理者/Owner権限ユーザー、グループ/プロジェクトのアクセストークン、個人アクセストークン（長寿命・広スコープ）の不審発行。
    • Webhook/Integrationsの新規追加や宛先変更。
    • Protected Variables・Deploy Keys・Secretsの変更履歴。
    • Runner登録/解除イベント、登録トークンの不審使用、共有Runnerの設定改変。
  • ネットワーク: アップグレード前後での外向き通信先の差分、未知FQDN/IPへの継続通信の有無を追跡します。

• 資格情報の一括ローテーション（再発予防と後遺症対策）

  • GitLab内に保管/参照される全トークン・鍵（PAT、グループ/プロジェクトアクセストークン、Deploy Keys、CI/CD Variablesの秘密、Runner登録トークン、Webhookシークレット）を棚卸し、未使用の失効とスコープ/TTLの再設計を行います。
  • クラウド・SaaS連携（AWS/GCP/Azure、コンテナレジストリ、Issue連携等）のクレデンシャルも同時ローテーションします。

• 検知の底上げ（今後の監視強化）

  • アプリログ（production_json.log/api_json.log/sidekiq.log/workhorse.log等）の集中管理と、以下の検知ロジックを追加します。
    • 長大な入力や正規表現評価に伴うタイムアウト/500系エラーの急増。
    • workhorse/sidekiq配下のOSコマンド生成と外向き通信の相関。
    • アカウント/トークン/Hook/Runner設定の短時間集中変更。
  • ビルドアーティファクトの整合性チェック（署名/ハッシュ）、重要リポジトリへの強制コードレビュー・署名必須化を検討します。

• ガバナンスとフリーズ基準

  • 「GitLabが未認証RCEで疑いあり」の場合に、どの範囲のパイプラインを一時停止するか、どの承認者が再開可否を判断するか——運用フリーズのルールを先に決めておくと、被害の尾を短くできます。

• 公式情報の追跡

  • ベンダのセキュリティリリースとCISAのKEV更新を継続監視します。期限付きの是正要求や追加の緩和策が提示される可能性があります。

参考情報

• 報道: CISA Confirmed Actively Exploited GitLab Vulnerability CVE-2026-97229

最後に——今回の型は、技術的な修正だけでなく「信頼の回復」に本質があります。パッチ適用と並行して、鍵とトークンの棚卸し・ローテーション、そしてパイプラインの透明性を一段高める仕組み化までをワンセットで回し切ることが、次の攻撃波に対する最大の備えになります。読者の皆さんの現場に、明日すぐ使える“動き方の地図”を残すことが、私たち編集部の願いです。