GitLab Vulnerabilities Allow Attackers to Execute Remote Code on Default GitLab Installations
2026/07/25 CyberSecurityNews — GitLab が新たに公表したエクスプロイト・チェーンは、Ruby の JSON 解析ライブラリ Oj に長期間にわたり埋もれていた 2 件のメモリ安全性の欠陥を組み合わせるものである。それにより、デフォルトの GitLab インストール環境においてリモート・コード実行 (RCE) が引き起こされ、ソースコード／Rails のシークレット／内部サービスなどが露出する可能性が示された。Open Defense Initiative の一環として、Depthfirst の研究者である Yuhang Wu は自動分析システムを使用して、Ruby アプリケーション全体で広く利用されている、高性能なネイティブ C ベースの JSON パーサ Oj をスキャンした。
このスキャンにより、優先順位付けが可能な 18 件の脆弱性が発見された。そのうち 7 件はメモリ安全性のバグであり、さらに、そのうち 2 件は、エクスプロイト・チェーンとして悪用されるまで、約 5 年間にわたり Oj 内に気付かれず存在していたものだ。この 2 件の脆弱性は、Oj::Parser.usual.parse における未チェックのネスト・スタック書き込みと、安全ではない 16 ビットのキー長の切り詰めによるヒープ・ポインタ漏洩の問題である。
個別に見れば、それぞれの影響は限定的である。一方は、繰り返し実行できる 1 バイトの書き込みプリミティブのみを提供し、もう一方は、固定長 29 バイトのメモリ領域を漏洩するだけのものだ。しかし、慎重なヒープ・アロケータ操作と組み合わせることで、攻撃者はコールバック・ポインタを任意に制御し、ASLR を突破する手段を獲得し、最終的に “git” システム・ユーザーとして任意のコード実行を実現できた。
GitLab 脆弱性がコード実行を可能に
GitLab は、ipynbdiff と呼ばれる in-tree gem を使用して、Jupyter Notebook (.ipynb) ファイルの差分から可読性の高い diff を生成する。その過程で、Oj のネイティブ・パーサを用いて各ノートブック・リビジョンを解析し、JSON に “cells” フィールドが含まれていることを検証する。Notebook ファイルは、本質的に JSON ドキュメントであるため、コミットを push してdiff を閲覧できる認証済みユーザーであれば、この処理に対して悪意の JSON 構造を送り込むことが可能であった。
このエクスプロイトは、単一のコミット diff リクエスト内で、特別に細工した 2 つの Notebook ファイルを処理させることで成立する。
1 つ目のファイルでは、過剰なネスト深度を用いて未チェックのスタック書き込みを悪用し、内部バッファ・ポインタをリダイレクトした後に、ヒープ操作により Ruby の Array のメモリをパーサのコールバック・ポインタと重ね合わせる。それにより攻撃者は、任意のアドレスを p->start に書き込めるようになる。
2 つ目のファイルでは、過大な JSON オブジェクト・キーに埋め込まれたヒープ・ポインタ漏洩が、diff の HTML 出力にレンダリングされることで、libc や libruby などのコア・ライブラリのアドレスが取得され、ASLR 保護が突破される。
Puma (GitLab の Ruby アプリケーション・サーバ) は、ワーカーごとのネイティブ・パーサー・インスタンスを複数のスレッドで共有するため、細工された 2 つのファイルは単一リクエスト内で同一の脆弱なパーサにより処理される。その結果として、2 つ目のファイルが破損したコールバックをトリガーし、system() を介したシェル・コマンドの実行が可能になった。
内部 Redis インスタンスに対するサーバサイド・リクエスト・フォージェリ (SSRF) に依存していた従来の GitLab の RCE とは異なり、この攻撃チェーンは、メモリ・セーフであるはずの Ruby コード内に組み込まれた、ネイティブ C ライブラリを標的とすることで、GitLab における最新の SSRF 防御を完全に回避した。
通常の push と diff 閲覧権限を持つプロジェクト・メンバーであれば、管理者権限／CI/CD アクセス／被害者による操作を必要とせずに、この攻撃チェーンを悪用できる。したがって、共有型またはマルチテナント型の self-managed GitLab インスタンスにおいて極めて危険な状況が生じる。
この脆弱性の悪用に成功した攻撃者は、GitLab の Puma ワーカーを実行する “git” アカウントとしてコマンドを実行できるため、リポジトリのソースコード／Rails のシークレット／サービス認証情報／GitLab ホストからアクセス可能な内部サービスなどが露出する可能性がある。その結果、Depthfirst が CybersecurityNews への声明で述べたように、データ窃取／コード改竄／ラテラル・ムーブメントのリスクが生じる。
影響を受けるバージョンと修正
| Component | Affected Versions | First Fixed Release |
|---|---|---|
| GitLab CE/EE | 15.2.0–18.10.7 | 18.10.8 |
| GitLab CE/EE | 18.11.0–18.11.4 | 18.11.5 |
| GitLab CE/EE | 19.0.0–19.0.1 | 19.0.2 |
| Oj gem | 3.13.0–3.17.1 | 3.17.3 |
すでに GitLab.com は、この情報が開示された時点でパッチ適用済みであるため、Dedicated を利用する顧客は対応不要である。その一方で、影響を受けるバージョンを利用している self-managed 環境の運用者は、直ちにアップグレードする必要がある。
脆弱な Oj パーサのコードは、2021年8月にマージされたものだ。GitLab は、2022年7月にリリースしたバージョン 15.2.0 以降に対して解析処理を開始した。研究者は 2026年5月21日に Oj の中核バグを報告した。この Oj の欠陥は 1,753日間にわたり存在した後に、5月27日に修正がマージされ、6月4日に Oj 3.17.3 が公開された。その後に、GitLab 固有の攻撃チェーンが 6月5日に報告され、6月8日に確認された後、2026年6月10日に 19.0.2／18.11.5／18.10.8 で修正された。
この研究活動では、今回の攻撃チェーンで利用された 2 件に加え、Oj に関する 9 件の CVE が公開された。その対象として含まれるのは、スタックバッファ・オーバーフロー／ヒープバッファ・オーバーフロー／SAJ コールバックおよびドキュメント・イテレータにおける複数の解放済みメモリの使用／負のサイズによる memcpy／大容量ファイル処理時の整数オーバーフローなどである。それが示すのは、安全と考えられている Ruby アプリケーションに組み込まれたネイティブ C エクステンションの内部にも、深刻なメモリ破損リスクが潜んでいることである。
self-managed GitLab を運用するセキュリティ・チームは、修正版へのアップグレードを最優先で実施した上で、Ruby の依存関係ツリーに含まれるネイティブ C エクステンションを監査すべきである。信頼された gem 内に存在するメモリ・セーフではないコードが、Ruby アプリケーション・スタック全体のメモリ安全性を損なう可能性がある。
訳者後書：今回の問題は、Ruby アプリケーションで広く使われている C 言語ベースの JSON 解析ライブラリ Oj に存在していた、メモリ安全性に関する欠陥が原因です。具体的には、解析処理における未チェックのネスト・スタック書き込みと、安全ではない 16 ビットのキー長の切り詰めによるヒープ・ポインタの漏洩という 2 件のバグが関係しています。単体での影響は限定的でしたが、これらを細工したファイルで組み合わせることで、コールバック・ポインタの制御や ASLR 保護の突破が可能となり、結果として GitLab 上でのリモート・コード実行につながりました。それぞれの CVE の詳細については、GitLab のアドバイザリを参照してください。
IoT OT Security News 
You must be logged in to post a comment.