Ing. Calogero Bono
2026年10月12日、GitLabはCommunity EditionとEnterprise Edition向けにバージョン19.4.2、19.3.5、19.2.8を公開しました。このリリースには、CVSS 10.0の脆弱性CVE-2026-97229の修正が含まれています。この脆弱性を悪用されると、サーバー上で任意のコードを実行される可能性があります。木曜日、米国のCISAは攻撃が実際に行われていることを確認し、この脆弱性をKEVカタログに追加しました。自社でGitLabインスタンスを運用している場合は、直ちに更新することが重要です。
本題に入る前に、いくつかの用語を確認します。CVEは公開された脆弱性を識別するためのコードです。CVSSは0から10までの重大度スコアです。CI/CDは、コードのビルド、テスト、公開を自動で行うパイプラインを指します。KEVは、実際の攻撃で既に悪用されている脆弱性をまとめたCISAのカタログです。RCEは、リモートからのコード実行、つまり他者のサーバー上でコマンドを動かすことを意味します。
CVE-2026-97229とは何か？
GitLabの公式ページによると、CI/CDの設定で使われる正規表現コンパイラにおける整数オーバーフローの問題です。特定の条件下では、認証されていないユーザーが、細工された正規表現を使ってサーバー上で任意のコードを実行できた可能性があります。原因は入力検証が不十分だったことです。
CVSSのベクトルは、ネットワーク経由、複雑性は低、権限不要、ユーザー操作不要です。そのためスコアは10.0となりました。この脆弱性はHackerOneのバグバウンティプログラムを通じて、joaxcar氏から報告されました。
誰がこの脆弱性を悪用しているのか？
BleepingComputerが伝えたところによると、CISAはこの脆弱性をKEVに追加し、連邦機関に対して日曜日までにサーバーを保護するよう求めました。The Hacker Newsによると、民間機関の期限は2026年11月1日です。
今回のKEV追加は、Alpine Linuxが公表したインシデントと関係しています。不明な攻撃者が、20日と21日にAlpineのインスタンスで脆弱性の悪用を試みましたが、失敗しました。攻撃者は特別に作成したCI設定を送り込み、ワーカープロセスを8回クラッシュさせました。そのうち4回は、悪用が次の段階で失敗しています。攻撃者はAlpineのGitLabコンテナイメージもダウンロードしていました。25日と26日の再試行はブロックされました。
Alpineのメンテナーは「The attack came close to working」と述べています。侵入の成功を示す証拠は見つからなかったものの、完全には否定できないため、インスタンスをゼロから再構築したとのことです。同チームによれば、aportsリポジトリ、パッケージ、21日のリリースは改ざんされていません。
どのバージョンが影響を受けるのか？
CVE-2026-97229について、GitLabは19.2.8より前の19.2、19.3.5より前の19.3、19.4.2より前の19.4の全バージョンを対象としています。GitLab.comは既に修正版を使用しています。GitLab Dedicatedのテナントは、公開前に内部リリースで更新されました。
GitLabは、19.3.4でInona連携が有効な場合にマージリクエストのページに不具合があったことも報告しています。これは19.3.5で修正されています。また、セルフマネージド環境の管理者が攻撃の試みを見つけやすいように、6件の脅威検出ルールも公開しました。
同じパッチに含まれる他の脆弱性
このリリースには最も深刻な問題だけが含まれているわけではありません。GitLabが公表しているスコアに従い、他の修正は以下のとおりです。
- CVE-2026-92883、構文ハイライトにおけるクロスサイトスクリプティング、CVSS 8.7。
- CVE-2026-16301、Developerユーザーが保護されたブランチでパイプラインを開始できた問題、CVSS 8.5。
- CVE-2026-14814、rawファイルキャッシュのポイズニング。保護された変数が露出する可能性あり、CVSS 8.2。
- CVE-2026-81839、プロジェクト移管後に新しいグループの権限でパイプラインが実行された問題（EEのみ）、CVSS 7.7。
- CVE-2026-96893、GitLab Duoの AIエージェントの指示へのインジェクション（EEのみ）、CVSS 7.3。
このほか、GraphQL経由で非公開のメモを読める問題や、GitLab Pagesのログにトークンが露出する問題など、中程度の脆弱性が5件あります。全体像は公式ページで確認できます。
把握しておくべき制約
何台のインスタンスが侵害されたのかは分かっていません。BleepingComputerが引用したShadowserverは、インターネットに公開されたCommunity Editionのインスタンスを約2,800台追跡していますが、そのうち何台が更新済みかは示していません。この数字を脆弱なシステムの台数と読み替えるべきではありません。
情報源からは、攻撃者が誰なのか、またAlpine以外にも事例があるのかは分かりません。攻撃の技術的な詳細も公開されていません。GitLabはパッチのリリースから90日後に脆弱性の詳細を公開するため、今後さらなる情報が出てくる可能性があります。
デジタル業務に携わる人への影響
事務所や会社でGitLabをセルフマネージドで使っている場合、最優先すべきはバージョンの更新です。コード、シークレット、パイプラインを保持するサーバーに認証不要の脆弱性があるのは、顧客にとっても現実的なリスクです。リポジトリをGitLab.comでホストしている場合は、プラットフォーム側で既に保護されています。
Alpineの教訓は実務的です。侵害の可能性を否定できない場合は、インスタンスを再構築し、シークレットをローテーションしてください。インストールを自動化すると役立ちます。詳しくはAnsibleによる設定とデプロイのガイドで解説しています。サーバーの運用には、アップデートを規律正しく適用することも欠かせません。これについては、FragnesiaとPHP2Shellの事例で扱いました。パッチ後のスキャンに関する最近の例としては、Oracle E-Business Suiteがあります。すべてを自分で追いかける時間がない場合は、セキュリティ更新を含めて管理されたホスティングやサーバーサービスという選択肢もあります。
編集部の見解
今回の件は、パッチ公開から攻撃までの時間が非常に短いことを示しています。修正は10月12日に公開され、Alpineへの試みは20日に始まりました。つまりわずか8日です。次の月次サイクルまで更新を待つ人は、すでに手遅れになっています。
一方で、批判的な視点も必要です。GitLabはFortune 100の半数以上で使われていると紹介されており、BleepingComputerは同じ時期に最大深刻度の脆弱性が相次いだことを伝え、そのうち2件はさらに最大深刻度でした。企業のコードとシークレットを預かるサービスにとって、この頻度は重く受け止めるべきものです。GitLabが迅速に修正していることは確かですが、それだけでは不十分です。自社で運用を続ける場合は継続的な監視体制が必要であり、専門家に任せるという選択肢も検討すべきでしょう。
よくある質問
GitLabは今すぐ更新する必要がありますか？
はい、セルフマネージド環境で該当するバージョンを使っている場合は必要です。GitLabは19.4.2、19.3.5、19.2.8への即時更新を推奨しています。攻撃が実際に行われていることは、CISAが確認しています。
GitLab.comは危険ですか？
GitLabによると、危険ではありません。GitLab.comは既に修正版を使用しており、Dedicatedのテナントも一般公開前に更新されています。
この脆弱性を悪用するにはアカウントが必要ですか？
いいえ。CVSSのベクトルでは、権限もユーザー操作も不要とされています。攻撃は、細工されたCI/CD設定を通じて行われます。
攻撃を受けたかどうかはどう確認できますか？
情報源には確実な方法は示されていません。GitLabはセルフマネージド環境向けに6件の検出ルールを公開しています。Alpineでは、異常なCI設定の後にワーカーが繰り返しクラッシュする現象が確認されました。
更新するだけで十分ですか？
状況によります。インスタンスが公開されたままで、数日前まで未修正だった場合は、侵害の可能性を否定できません。Alpineはゼロからの再構築を選びました。
今後数週間の注目点，パッチと確認作業
今後数日間は、Alpine以外の事例が見つかるかどうか、また技術的な詳細が公開されるかどうかが重要です。以下の3点をおすすめします。
- 使用している系統の最新版に更新し、インストール後にバージョン番号を確認してください。
- ワーカーのログで繰り返されるクラッシュや、通常と異なるCI設定がないかを、GitLabの検出ルールを使って確認してください。
- インスタンスが公開されており未更新だった場合は、トークンと保護された変数をローテーションし、再構築を検討してください。
