GitLabのプロジェクト管理機能に組み込まれた「メールによる作業アイテム作成」用のプライベートメールアドレスが、公開ドキュメント上に意図的に掲載されているケースが相次いで確認された。セキュリティ企業Aikidoの調査により、このアドレスを悪用することで、脆弱性のないリポジトリに対してもコード改ざん攻撃が可能であることが明らかになっている。GitLabはこの問題を「仕様上の動作」として一旦クローズしたが、二次報告を受けてUIやドキュメントの改善に動いた。
「Email work item to this project」が抱える根本的なリスク
GitLabが標準機能として提供する「Email work item to this project」は、開発者がプロジェクトに対してメールでIssueやタスクを作成できる仕組みだ。この機能を有効にすると、プロジェクトごとに一意のプライベートメールアドレスが自動生成される。このアドレスには「glimt-」で始まる長期的に有効なトークンが埋め込まれており、これが認証情報として機能する。
問題は、このメールアドレスが単なる受信用ではない点にある。Aikidoの研究者らが指摘するのは、アドレス末尾の「-issue」を「-merge-request」に変更するだけで、GitLabがそのリクエストを受け入れ、マージリクエストが作成されてしまうという仕様だ。
「メールアドレスの送信元がトークン所有者のメールアドレスと一致するかどうかを確認すれば防御層になるが、GitLabはこのチェックを行っていない」とAikidoは報告している。つまり、インターネット上の任意のメールボックスから送信されたメッセージを、GitLabはトークン所有者の意図として処理してしまう。
IP制限を迂回、保護されたブランチへの攻撃も可能に
この攻撃手法の危険性は、IPアドレスによるアクセス制限制限さえも迂回できる点にある。Aikidoの実証テストでは、IP制限が設定された環境においても、メール経由でのマージリクエスト作成が成功した。
攻撃者が取得可能なアクセスレベルは、トークン所有者のアカウント権限に依存する。権限が高い場合、以下のような被害が想定される。
- 保護されたブランチへのコードプッシュ
- ソースコードの窃取
- CI/CD変数に保存されたシークレット情報の取得
- 機密性の高いIssueへのアクセス
ただし、攻撃を成功させるにはターゲットプロジェクトのパスとIDが必要となる。公開プロジェクトであればこれらの情報は誰でも入手可能だが、プライベートプロジェクトの場合、IDは総当たりで特定できるものの、パスの漏洩が別途必要になる。
公開ドキュメントに意図的に記載された12件のアドレス
Aikidoの研究者らは、わずか半日の調査で、公開されたREADMEやコントリビューションガイド、バグ報告受け付け用のサポートページなどで、稼働中のGitLabプライベートメールアドレスを12件発見した。これらのアドレスは、メンテナーがバグ報告をメールで受け取るために意図的に掲載したものだという。
特に深刻なのは、影響を受けたプロジェクトの一部が非常に人気の高いオープンソースプロジェクトだったことだ。大規模なユーザーベースを持つプロジェクトの場合、サプライチェーンリスクへと発展する可能性がある。
「これらのアドレスはあなただけのために生成されたものです。他人に知られると、あなたの代わりにIssueやマージリクエストを作成できてしまいます」——GitLab自身もドキュメント内でこう警告している。実際の運用においては、この警告が十分に認識されていない実態が浮き彫りとなった。
GitLabの対応—HackerOne報告からUI改善まで
Aikidoは2025年5月、HackerOneを通じてこの問題をGitLabに報告した。しかしGitLabはこれを「意図された動作（intended behavior）」としてクローズ。Aikidoは6月に再度通知を行い、これを受けてGitLabは対応を変更した。
具体的な改善点は以下の3点である。
- UI上にマージリクエスト作成に関する記述を追加
- トークンデータへのアクセスに関する誤った記述の削除
- メール経由の受信がIP制限をバイパスすることをドキュメントに明記
GitLabは現在、送信元メールアドレスとトークン所有者の一致を確認する機能の実装を検討している。
プロジェクトメンテナーが直ちに取るべき対策
この問題の根本的な対策は、プライベートメールアドレスを公開ドキュメントに記載しないことだ。すでに公開してしまったプロジェクトについては、該当するトークンを直ちにリセットする必要がある。
また、組織としての対応としては、メールによる作業アイテム作成機能そのものを無効化するか、利用する場合でも権限の最小化を徹底すべきだろう。トークンの流出が疑われる場合は、利用者自身でリセットを行えることをGitLabは明示しており、速やかな対処が求められる。
今回の事例は、利便性を追求した機能が、想定外の使われ方をした場合にどのようなセキュリティリスクを生むかを如実に示している。GitLabの対応が「仕様通りの動作」から「UI改善・ドキュメント修正」へと変わった経緯は、プラットフォーム側のセキュリティ設計における前提の見直しが急務であることを業界全体に示唆している。
