Alpine Linux、Rubyの正規表現エンジンの重大な脆弱性を悪用する攻撃を受けGitLabを再構築

10月20日と21日、攻撃者はRubyの正規表現エンジンにある重大な脆弱性を利用し、Alpine LinuxのGitLabインスタンスを標的にしました。コード実行が成功した証拠はありませんでしたが、チームはその可能性を排除できず、完全性を確保するためにサービス全体を一から再構築することを決定しました。

何が起きたか

このインシデントは、CVSSスコア10.0という重大な欠陥であるCVE-2026-97229を中心に展開しています。この脆弱性は、CI設定ファイル内の正規表現の評価方法に影響を与えます。根本原因は、Rubyに組み込まれている正規表現エンジン「Onigmo」にあります。GitLabは10月12日に修正版をリリースしましたが、これらの修正にはGitLab自身のアプリケーションコードの変更ではなく、バンドルされたRubyランタイムへの特定のパッチが必要でした。Alpine Linuxは10月13日に、修正済みのバージョン19.3.5ではなく、誤ってGitLab 19.3.4へアップグレードしてしまい、インスタンスが無防備な状態となりました。

10月20日から21日の間に、新規登録アカウントが脆弱性をトリガーするように細工されたCI設定を送信しました。これらのペイロードにより、GitLabワーカープロセスが8回クラッシュしました。そのうち4回のケースでは、攻撃者はエクスプロイトチェーンの一部を進めましたが、次のステップで失敗しました。攻撃者はまた、GitLabコンテナイメージをダウンロードしており、特定のビルド環境に合わせてエクスプロイトを調整しようとした可能性があります。予期しないファイルやプロセス遅延など、コード実行が成功した兆候は観察されませんでしたが、チームは、成功したエクスプロイトは標準的なWebログには痕跡を残さないことを認めました。

対応を複雑にしたのは、10月22日のGitLab 19.3.6へのアップグレードでも脆弱性が解決しなかったことです。AlpineのコンテナイメージはGitLabのパッチ適用済みバンドルではなく標準的なRubyを使用していたため、Ruby自体が10月23日にバージョン3.3.13、3.4.12、および4.0.9で修正をリリースするまで、根本的な欠陥は残りました。チームは10月26日にインスタンスが依然として脆弱であることを認識した後、開発者以外のすべてのアクセスを閉鎖し、完全な再構築を開始しました。

仕組み

この脆弱性は、Ruby内のOnigmoエンジンによる正規表現の処理方法を悪用します。GitLabがCI設定ファイルを解析する際、これらの正規表現をコンパイルします。攻撃者が悪意のある細工を施したパターンを提供すると、エンジンが予測不可能な動作を引き起こし、リモートコード実行が可能になる場合があります。これはGitLabのビジネスロジックの欠陥ではなく、それが依存する基盤となる言語ランタイムの欠陥です。

セルフホスト型インスタンスの場合、これは複雑な依存関係チェーンを生み出します。ホスト環境がパッチ未適用のシステム全体のRubyインストールを使用している場合、GitLabアプリケーションを更新するだけでは不十分です。GitLabの公式パッケージにはパッチ適用済みのRubyが含まれていますが、上流のRubyに依存するカスタムデプロイメントやコンテナイメージは、言語メンテナーによる修正リリースを待たなければなりません。今回のケースでは、修正は10月23日のRubyリリースで提供されましたが、これはGitLabの初期パッチから1週間以上後のことでした。

主要な詳細

• 脆弱性: RubyのOnigmo正規表現エンジンにおけるCVE-2026-97229（CVSS 10.0）。
• 攻撃期間: 10月20日～21日、さらに10月25日～26日に試行が続いた。
• 影響: ワーカーの8回のクラッシュ。データ漏洩は確認されていませんが、侵害されたものとして扱われました。
• 緩和策の失敗: GitLabを19.3.6にアップグレードしても問題は解決しませんでした。基盤となるRubyがパッチ未適用だったためです。
• 検証: 10月20日～24日のAlpineリリースおよびパッケージは外部記録と照合され、改ざんがないことが確認されました。
• 対応: インスタンスの完全な再構築、パスワードリセット、およびアウトバウンド接続ログの実装。

なぜ重要なのか

このインシデントは、セルフホスト型インフラストラクチャの管理における重要な盲点、すなわちアプリケーションレベルのパッチとランタイムレベルの修正の区別を浮き彫りにしています。開発者は通常、主要なソフトウェアパッケージをアップグレードすれば関連するすべてのセキュリティリスクが解消されると想定しがちです。しかし、Ruby、Python、Node.jsなどの共有依存関係に脆弱性が存在する場合、修復パスは断片化されます。チームは、言語ランタイム、OSパッケージ、そしてアプリケーション自体を含む複数の層にわたるパッチを追跡する必要があります。

エンジニアリングリーダーにとって、これはコンテナイメージおよびデプロイメントアーティファクトの構成を検証することの重要性を強調します。デフォルトのシステムパッケージに依存すると、ベンダーの修正と環境のセキュリティ態勢との間に遅延が生じる可能性があります。さらに、アウトバウンドネットワークログの欠如が調査を妨げ、検知のためにegressトラフィックへの可視性がingress監視と同じくらい重要であることを示しています。

あなたができること

• Rubyのバージョンを直ちに確認してください。GitLabを使用している場合は、3.3.13、3.4.12、4.0.9以降を実行していることを確認してください。
• GitLabコンテナイメージを確認してください。10月27日以前にalpinelinux/gitlab:19.3.6を取得した場合は、パッチ適用済みのRubyを取得するために再度取得してください。
• CI/CDパイプラインを監査し、最近の変更や、プロービング試行を示唆する可能性がある失敗したジョブがないか確認してください。
• CIサーバーおよびデータベースホストからのアウトバウンドネットワーク接続のログを有効にし、インシデント対応能力を向上させてください。
• 露出が疑われる場合は、すべてのパスワードをリセットし、CI/CD変数やランナートークンなどのシークレットをローテーションしてください。
• ビルドの完全性を独立して検証できるように、内部アーティファクトに対して署名付きリリースタグを実装してください。