GitLabのクリティカル脆弱性 CVE-2026-97229 が狙われた経緯
2026年10月20日と21日、オープンソースプロジェクトのAlpine Linuxが運用するGitLabインスタンスに対し、緊急度の高い脆弱性 CVE-2026-97229 を悪用しようとするサイバー攻撃が発生しました。
この脆弱性は、GitLabがCI設定内の正規表現を評価する方法に存在し、CVSSスコアは最高の10.0とされています。
このバグの根本原因は、Rubyに組み込まれている正規表現エンジン Onigmo にあることが判明しています。GitLabは10月12日に修正版をリリースしましたが、Alpine Linuxのインスタンスは当時のバージョン19.3.4で稼働しており、この修正が適用されていませんでした。
攻撃者は新規登録したアカウントを使い、巧妙に作成されたCI設定を送りつけることで、GitLabのワーカープロセスを8回もクラッシュさせました。そのうち4回のクラッシュでは、攻撃が次のステップに進む寸前まで至っていたと報告されています（Lobsters）。
修正が適用されなかったアップグレードとその影響
Alpine Linuxは10月22日にGitLabをバージョン19.3.6にアップグレードしましたが、それでも脆弱性は修正されませんでした。これは、今回の修正がGitLab自身のコードではなく、Rubyに適用されるパッチであったためです。
Alpine Linuxのインスタンスでは標準のRubyイメージを使用していたため、GitLabの公式パッケージに含まれるRubyの修正が適用されませんでした。結果として、10月27日に新しいコンテナイメージが公開されるまで、システムは脆弱な状態にありました。
もし開発者の方がGitLabの公式パッケージではなく、独自のRuby（ソースからビルドしたものや、独自のコンテナイメージ内のRuby）でGitLabを運用している場合、GitLabのアップグレードだけでは不十分です。Ruby自体を3.3.13、3.4.12、4.0.9、またはそれ以降のバージョンに更新する必要があります（Lobsters）。
以下に、今回のインシデントの時系列を示します。
| 日付 | イベント |
|---|---|
| 10月28日 | GitLabの再構築が完了。すべてのパスワードとGitLabのシークレットキーをリセット |
| 10月27日 | 開発者およびビルドサーバーを除く全員のGitLabを停止。再構築を開始 |
| 10月26日 | アップグレード後もインスタンスが脆弱なままであることを発見 |
| 10月25日〜26日 | 攻撃者が再び侵入を試みるが失敗 |
| 10月24日 | aports、パッケージ、10月21日リリース版を外部記録と照合して検証 |
| 10月23日 | 攻撃者のアカウントをブロック。Rubyが修正版をリリース |
| 10月22日 | GitLabを19.3.6にアップグレード |
| 10月21日 | 本格的な攻撃。GitLabがクラッシュし、502エラーやCIジョブの失敗が発生 |
| 10月20日 | 攻撃者がアカウントを登録し、プロービングを開始 |
| 10月13日 | CVE-2026-97229が公開。誤って19.3.5（修正版を含む）ではなく19.3.4にアップグレード |
| 10月12日 | GitLabが修正版をリリース |
広がるサイバー攻撃の脅威と今後の対策
今回のインシデントは、サプライチェーン攻撃やゼロデイ脆弱性の悪用といったサイバー攻撃の脅威が現実のものであることを改めて示しています。ベルギーの税務当局がサイバー攻撃を受け、複数のデジタルサービスを停止した事例も報告されており、企業や政府機関を問わず、情報セキュリティ対策の強化は喫緊の課題です（The Register）。
Alpine Linuxのケースでは、幸いにもパッケージやリリースされたファイルへの改ざんの証拠は見つかりませんでしたが、パスワードのリセットやシステムゼロからの再構築といった大規模な対応が必要となりました。開発者としては、サードパーティの依存関係の脆弱性情報を常にキャッチアップし、公式のセキュリティアナウンスメントを注視することが不可欠です。
また、多層防御の考え方に基づき、侵入検知システムや異常検知の仕組みを導入し、万が一の事態に備えることが重要だと感じます。定期的なセキュリティパッチの適用はもちろん、依存関係の定期的なスキャンやSBOM（Software Bill of Materials）の活用も、今後のセキュリティ対策においてますます重要になってくるのではないでしょうか。
エンジニア目線で見ると：サプライチェーンの複雑性と確実な検証の重要性
今回のGitLabのインシデントは、ソフトウェアサプライチェーンの複雑さがセキュリティ運用に与える影響を浮き彫りにしています。CVSSスコア10.0というクリティカルな脆弱性が、直接GitLabのコードではなく、その内部で利用されているRubyの正規表現エンジンOnigmoのバグに起因している点は非常に重要です。GCPでCloud RunやCloud Functionsを使ってコンテナベースでサービスを運用している開発者の方も多いと思いますが、このような環境で公式のベースイメージを使わずにカスタムランタイムや独自の依存関係を構築している場合、今回のAlpine Linuxと同様の問題に直面する可能性があります。
特に注意すべきは、単に上位バージョンにアップグレードすれば全て解決すると安易に考えがちな点です。今回のケースでは、GitLabのアップグレードだけではRubyのパッチが適用されず、脆弱な状態が継続しました。これは、CI/CDパイプラインを組んで自動でアップグレードを行っているチームでも見落としかねないポイントだと感じます。
脆弱性情報の詳細を読み込み、何が修正の対象なのか、依存関係のどのレイヤーで修正が必要なのかを確実に理解した上で、更新後の挙動を十分に検証する必要があるでしょう。私は個人プロダクトでもPythonとTypeScriptをメインに使っていますが、npmやPyPIのライブラリに起因する脆弱性が発覚した場合も、対象ライブラリのバージョンアップだけでなく、その影響範囲や副作用を必ず確認するようにしています。Claude Codeに新しいバージョンを適用したCI/CDスクリプトを生成してもらい、その差分をしっかりレビューする、といった工程も必要ではないでしょうか。
