GitLabのCVE-2026-97229：Alpineが悪用の試みを報告

Alpine Linuxによると、2026年10月20日と21日に、攻撃者が同プロジェクトのGitLabサーバーでCVE-2026-97229の悪用を試みました。これは、GitLabが修正を公開してから約1週間後のことです。より大きな教訓は、10月28日に公開されたAlpineのインシデント報告にあります。Alpineの環境では、GitLab自体をアップグレードしても穴はふさがりませんでした。本当の修正がRubyへのパッチだったためです。

Alpineは小さなLinuxディストリビューションで、Dockerコンテナのベースとして非常に人気があります。開発者たちは、パッケージのコードを管理するために、セルフホストのGitLabサーバーを使っています。

Alpineのサーバーで起きたこと

Alpineによると、一連の試みでGitLabのワーカープロセスが8回クラッシュしました。そのうち4回では、攻撃者がエクスプロイトの途中まで進んでいました。

Alpineは、攻撃が成功した証拠は見つかっていないとしています。投稿には「成功したという証拠は見つかっていませんが、その可能性を否定することはできません」とあります。

そのため、チームはサーバーが侵害されたものとして扱いました。GitLabを一から再構築し、アクセスを開発者とビルドサーバーに限定しました。また、すべてのパスワードとシークレットキーをリセットしました。

プロジェクトは、ユーザーにとって最も重要な部分も確認しました。Alpineによると、aportsリポジトリ、パッケージ、そして10月21日の安定版リリースを外部の記録と照合しました。改ざんの兆候は見られませんでした。対象のリリースは、Alpine 3.21.9、3.22.7、3.23.7、3.24.3です。Alpineのパッケージに署名する鍵はGitLabサーバーに保存されたことがなく、45台のビルドマシンも確認されました。

Alpineは、その過程でもう1つの問題を見つけました。サーバーへの自動ログインに、他のウェブサイトから流出したパスワードが使われていたのです。Alpine GitLabと同じパスワードを他の場所でも使っている人は、その場所のパスワードを変更すべきです。

GitLabのアップグレードが役に立たなかった理由

ここは、ほかのセルフホスト運用者が2度読むべき部分です。Alpineは「10月22日にGitLab 19.3.6へアップグレードしても、脆弱性は修正されませんでした」と書いています。

理由は、GitLabが修正を配布する方法にあります。GitLabの公式パッケージは、GitLabを記述しているプログラミング言語であるRubyを、独自のコピーとして同梱しています。Alpineによると、CVE-2026-97229の修正は、この同梱されたRubyに対する一連のパッチです。Alpineは標準のRubyでGitLabを動かしているため、GitLabの新しいバージョンだけでは何も変わりませんでした。

Alpineはまた、10月13日に19.3.5へのアップデートを誤って飛ばしていたと説明しています。攻撃の時点では、まだ19.3.4を使っていました。現在はAlpine自身のrubyパッケージに修正が含まれており、Alpineのユーザーはapk upgradeを実行する必要があります。

CVE-2026-97229とは

GitLabは2026年10月12日にこの脆弱性を公表し、すべてのセルフマネージド環境にアップグレードを促しました。BleepingComputerによると、これはCI/CDパイプラインファイル内の正規表現を読み取るGitLabの部分にある、整数オーバーフローです。正規表現はテキストのパターンで、CI/CDパイプラインはコードを自動でビルド・テストするスクリプトです。GitLabのアドバイザリーは、このバグが「認証されていないユーザーがGitLabサーバー上で任意のコードを実行できた可能性がある」と説明しています。

「joaxcar」というハンドル名を使う研究者が、GitLabのHackerOneバグバウンティプログラムを通じてこの脆弱性を報告しました。GitLab.comはすでにパッチ適用済みで、GitLab Dedicatedの顧客は対応不要でした。

項目	内容
深刻度	CVSS 10.0（最高値）
バグの種類	CI/CDの正規表現コンパイラにおける整数オーバーフロー
修正済みビルド	19.2.8、19.3.4または19.3.5、19.4.2（19.3は情報源により異なる）
公開エクスプロイト	10月13日にRapid7が公開
露出しているホスト	脆弱なバージョンで25,766台（Censys調べ）

19.3の修正版については、情報源によって食い違いがあります。BleepingComputerは19.3.4としています。Daily Security ReviewとAlpineは、どちらも19.3.5を挙げています。ご自身のブランチについては、GitLab自身のアドバイザリーを確認してください。

Daily Security Reviewは10月14日、このエクスプロイトが、公開プロジェクトのブランチにコミットされた細工ファイルを利用するものだと報じました。その時点では、実環境での攻撃は確認されていませんでした。米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）も、悪用された脆弱性のリストにこのバグを追加していませんでした。Censysはまた、検出したGitLabホストの約31%がまだパッチ未適用だったことを確認しました。

GitLabで最高深刻度の正規表現の脆弱性が見つかるのは、今月2件目です。10月21日には、GitLab 19.5.1がCVE-2026-110264を修正しています。これはCVSS 10.0の別のバグです。

開発者にとっての意味

Alpineの報告は、既知のパッチを実用的なチェックリストに変えてくれます。また、「アップグレードした」と「安全だ」は同じではないことも示しています。

• GitLabがRubyをどこから得ているかを確認する。 GitLabをソースから、またはシステムのRubyを使うディストリビューションのパッケージから動かしている場合、GitLabのアップグレードだけでは修正が含まれないことがあります。Alpineがそうしなければならなかったように、使っているRubyにパッチが含まれていることを確認してください。
• ポイントリリースを飛ばさない。 Alpineは誤って19.3.5を見逃しました。アップグレードの手順は、定期的なスケジュールではなく、GitLabのセキュリティアドバイザリーに合わせてください。
• 公開サーバーは探られたものと考える。 10月13日から公開エクスプロイトが存在しています。それ以降に脆弱なビルドをインターネット上で動かしていた場合は、その後数週間のワーカーのクラッシュログを確認してください。
• 公開プロジェクトを制限する。 このエクスプロイトには、公開プロジェクト内の細工ファイルが必要です。パッチを当てるまでは、サーバーに到達できる相手を制限し、信頼できないユーザーによる公開プロジェクトの作成を無効にしてください。
• 署名鍵はコードホスティングサーバーに置かない。 Alpineがパッケージは安全だと言えたのは、署名鍵が一度もGitLab上に置かれていなかったからです。この設計判断は見習う価値があります。
• 使い回されたパスワードをリセットする。 Alpineでも、クレデンシャルスタッフィングによるログインが見られました。一意のパスワードと二要素認証がどこでも使われるようになるまで、ユーザーにその利用を促してください。