GitLabの認証済みユーザーによるRCE脆弱性のPoCが公開、通常のバグ修正扱いで対策遅れの懸念

要点

• セキュリティ企業「depthfirst」の研究者が、GitLabの自己管理型サーバーで任意のコマンドを実行できるリモートコード実行（RCE）の概念実証（PoC）コードを公開しました。

• この脆弱性は、プロジェクトへのプッシュ権限を持つ認証済みユーザーであれば、管理者権限やCI/CDの実行権限がなくとも悪用が可能です。

• 脆弱性の原因は、GitLabが内部で使用しているRuby用のJSON解析ライブラリ「Oj」に存在する2つのメモリ破壊バグにあります。

• GitLabは今年6月にこの問題を修正していましたが、セキュリティ情報としてではなく通常のバグ修正として案内していたため、管理者が対策を急がなかった可能性があります。

• 影響を受けるのはGitLabのバージョン15.2.0から18.11.4、および19.0.0から19.0.1で、対策にはセキュリティパッチの適用が必要です。

• セキュリティ企業depthfirstの研究者は2026年7月24日、GitLabの自己管理（セルフマネージド）型サーバーにおいて、認証されたユーザーが任意のコマンドを実行できるリモートコード実行（RCE：ネットワーク経由で任意のコマンドを実行される脆弱性）の概念実証（PoC：脆弱性の実証コード）を公開しました。この脆弱性は、GitLabが約6週間前の6月10日に修正パッチをリリースしていたものですが、セキュリティアドバイザリのテーブルには掲載されていませんでした。そのため、多くのサーバー管理者がアップデートの緊急性を認識せず、現在も脆弱な状態のまま放置されている懸念が生じています。

脆弱性の概要と悪用条件

プロジェクトへプッシュ可能な認証済みユーザーであれば、管理者権限や他のユーザーとのやり取りを介さずに任意のコマンドを実行できます。

攻撃手順としては、まず細工したJupyterノートブック（プログラムコードと実行結果を記録できるドキュメント）をコミットし、その差分（diff）を表示させます。これにより、システムのヒープ領域（動的に確保されるメモリ領域）のポインタが漏洩し、これを複数回繰り返すことでメモリ上のライブラリ配置を特定します。

実行されたコマンドは「git」ユーザーのアカウント権限で動作するため、サーバー内のソースコードやRailsのシークレット、サービスの認証情報、CI/CD（開発からデプロイまでの工程を自動化する仕組み）データ、さらに内部サービスへのアクセス権が掌握されるリスクが生じます。

技術的詳細とメモリ破壊

この脆弱性チェーンは、Rubyで記述されたGitLab of ノートブック描画用ジェム（gem：Rubyのライブラリパッケージ）である「ipynbdiff」が、リポジトリに保存された .ipynb 形式のJSON（テキスト形式のデータ表現規格）データを、WebサーバーのプロセスであるPumaの内部でJSONパーサー「Oj」に渡す処理に端を発します。Ojは、主にC言語で書かれた高速なJSON解析用ライブラリです。

depthfirstの自律型セキュリティ検出システムがOjライブラリ内で発見した2つのメモリ破壊バグが、今回の悪用に連鎖して使用されました。
1つ目のバグは、固定の1,024バイトのネスト制限を超えてデータを書き込むことで、パーサーの開始コールバック関数（特定のイベント発生時に呼び出される関数）の制御を奪うものです。
2つ目のバグは、65,565バイトのオブジェクトキーを16ビットの符号付き整数フィールドにおいて29バイトに切り詰め、現在使用中のヒープポインタを戻り値として返してしまうものです。GitLabはこのポインタ値をそのままコミット差分に描画して出力するため、攻撃者にメモリ情報が漏洩します。この情報漏洩によって、システムの標準Cライブラリである「libc」のメモリ上の配置場所が特定され、書き込み処理と組み合わせることでコールバック先を system() 関数に変更し、任意のコマンド実行を実現します。

GitLabにおける修正分類の問題

GitLabは6月10日のパッチリリース（バージョン19.0.2など）において、この問題を修正する「Oj 3.17.3」へのアップデートを含めていました。しかし、この修正はパッチリリースのドキュメント内でセキュリティ修正の表には記載されず、通常のバグ修正の項目に分類されていました。

このため、当該脆弱性にはCVE（共通脆弱性識別子：プログラムのセキュリティ欠陥に付与される固有の識別番号）やCVSS（共通脆弱性評価システム：脆弱性の深刻度を評価する基準）スコアが割り当てられておらず、ノートブックの差分描画処理に起因する脆弱性の連鎖についての言及もありませんでした。結果として、セキュリティ情報の表を基準にパッチ適用の優先順位を判断しているサーバー管理者に対し、本アップデートを緊急に適用すべき理由が伝わっていなかったことになります。

影響を受けるバージョンと対策

影響を受けるバージョンと、修正が適用された最初のバージョンは以下の通りです。

• GitLab CE（Community Edition）および EE（Enterprise Edition）バージョン 15.2.0 〜 18.10.7（バージョン 18.10.8 で修正）
• 同バージョン 18.11.0 〜 18.11.4（バージョン 18.11.5 で修正）
• 同バージョン 19.0.0 〜 19.0.1（バージョン 19.0.2 で修正）

これらはFreeからUltimateまでのすべてのライセンスティアに影響しますが、Ruby自体には影響しません。GitLabおよびdepthfirstのいずれからも、パッチの適用以外の回避策は提示されていません。

なお、コンテナ環境の展開を自動化するHelmやOperatorといったツールを使用している場合は、それらの管理ツールのバージョンではなく、実際にPumaウェブサーバーが動作している「Webservice」コンテナ内のGitLabのバージョンを確認する必要があります。また、バージョン15.2から18.9までの古いバージョンについては、GitLabのセキュリティメンテナンスの対象外となっているため、バックポート（古いバージョンへの修正適用）は提供されません。これらの古いバージョンを使用している場合は、サポートされている最新バージョンへ移行する必要があります。

PoCの制限とタイムライン

公開されたPoCは、x86-64アーキテクチャの環境で動作するGitLabのバージョン18.11.3をターゲットに構築されています。メモリ上のレジスタ状態やアドレスのオフセット値は対象のイメージに最適化されており、さらにPumaのマスタープロセスが再起動するとメモリ配置が変わるため、任意の環境に対してそのまま動作するものではありません。

Ojライブラリのバグ自体は汎用的なものですが、攻撃コードを別の環境に移植するには一定の解析作業が必要です。depthfirstの測定によると、新規にインストールした2ワーカー構成の環境におけるメモリ配置の探索には5〜10分、長時間稼働している環境では1〜2時間の時間を要するとされています。

タイムラインとしては、depthfirstが5月21日にOj의バグを報告し、5月27日に修正がマージされました。その後、6月4日に「Oj 3.17.3」がリリースされ、翌5日にGitLabへ脆弱性チェーンが報告されています。GitLabは6月8日にこれを確認し、6月10日にパッチをリリースしました。現時点で、本脆弱性を悪用した実際の被害事例は報告されていません。また、GitLab側でも独立してRCEの再現に成功しています。The Hacker NewsはGitLabに対し、今回の修正がセキュリティ問題として分類されずCVEが割り当てられなかった理由について問い合わせを行っていますが、回答は保留中となっています。

補足

GitLabは、ソフトウェア開発におけるソースコード管理や共同開発を支えるプラットフォームであり、多くの企業や開発チームがオンプレミス環境（自己管理型）で運用しています。