GitLabのメール起票用アドレスからコードの不正プッシュやCI実行が可能に、セキュリティ企業が仕様上のリスクを報告
要点
- GitLabのメールによるIssue作成機能で発行されるアドレスのトークンが無期限であり、全プロジェクトで共通して適用される仕様が判明した。
- 第三者がこのメールアドレスを入手した場合、ユーザーになりすましてコードをコミットしたりCI/CDジョブを実行したりできる。
- 受信メール機能はIPアドレス制限や二要素認証（2FA）の対象外となっており、多層防御を迂回されるリスクがある。
- GitLab.comの全アカウントおよび受信メール機能が有効なセルフマネージド環境が対象となり、トークンのリセットが呼びかけられている。
セキュリティ企業のAikido Securityは2026年9月23日、GitLabが提供するメール経由のIssue（課題管理機能）作成用アドレスが悪用された場合、アカウント所有者になりすましてコードのコミットやCI/CD（継続的インテグレーション／継続的デリバリー）パイプラインの実行が行われる可能性があると報告した。
GitLab.comをはじめとする受信メール機能が有効な環境において、このメールアドレスが実質的な認証情報として機能しており、アドレスが外部に流出した際の影響について詳細を明らかにしている。
共通トークンと送信元検証の欠如がもたらす問題
GitLabには、専用のメールアドレス宛てにメールを送信することでプロジェクト内にIssueを自動起票できる機能が存在する。ユーザーにはプロジェクト画面の「Email work item to this project」ボタンを通じて固有のメールアドレスが提示される。
Aikido Securityの調査によると、このアドレスの中央に含まれる文字列はアカウントに紐づくトークンであり、GitLabの公式ドキュメント上でも有効期限が設定されていない。さらに、一見するとプロジェクトごとに個別のメールアドレスが割り当てられているように見えるものの、同一ユーザーの異なるプロジェクト用アドレスにはすべて同じトークンが使用されているという。このトークンは、そのアカウントがアクセス可能な公開・非公開を含むすべてのプロジェクトに対して有効に機能することが確認された。
また、GitLab側でメールの送信元アドレスを検証する仕組みが存在しない点も指摘されている。これにより、攻撃者は被害者のメールボックスへ侵入することなく、任意のメールアカウントから該当アドレスへ送信するだけで、被害者本人の権限としてGitLab上で処理を実行させることが可能になるとしている。
マージリクエスト機能の悪用による不正コミットの手口
Aikido Securityは、このメールアドレスが悪用された場合、単なるIssueの起票にとどまらず、GitLabの「メールによるマージリクエスト（変更提案）作成」機能を介してコードのコミットに転用できる手法を実証した。
具体的な手順として、アドレスの末尾を「-issue」から「-merge-request」に書き換えた上で、メールの件名に対象ブランチ名を記載し、パッチファイルを添付して送信する。これにより、GitLabは指定されたブランチへパッチを自動的に適用し、アカウント所有者名義のコミットとして登録する。指定ブランチが存在しない場合は自動で新規作成されるほか、ユーザーに書き込み権限があればmainブランチへの直接コミットも成立するという。
さらに、添付パッチによってCI/CD設定ファイルである「.gitlab-ci.yml」を書き換えた場合、ユーザーの権限が許可していれば、攻撃者が仕込んだジョブが被害者の実行権限のもとで動作することも判明した。なお、マージリクエスト自体を攻撃者が管理する複製プロジェクトに向けることはできないため、コードの注入は添付パッチを通じて行われる。
権限による影響度とセキュリティ機能の迂回
本挙動による被害の範囲は、漏洩したアドレスの持ち主が保持するロール（権限）に依存する。例えば閲覧権限のみを持つGuestアカウントのアドレスであれば影響は極めて軽微である一方、Maintainer（メンテナー）権限を持つアカウントのアドレスが悪用された場合は、保護ブランチへの書き込みやCI/CDのシークレット情報へのアクセスにまで及ぶ可能性があると説明している。
また、攻撃を実行するにはトークンに加えて対象プロジェクトのパスおよび数値IDが必要となる。公開プロジェクトではこれらは公表されているが、非公開プロジェクトの場合は別途プロジェクト情報の漏洩が必要となる。ただし、GitLabのプロジェクトIDは推測が容易であるとも言及されている。
加えて、GitLabの公式仕様として受信メール機能はIPアドレス制限の対象外と定められている。Aikido Securityが非公開プロジェクトに対して特定IPアドレスのみを許可する制限を設けて検証したところ、ブラウザからの接続やgit cloneコマンドは遮断されたものの、メール経由で送信されたマージリクエストは受け入れられ、mainブランチへのコミットが完了した。さらに、2FA（二要素認証）が義務付けられているインスタンスであっても、受信メール機能は2FAを介さずに動作する仕様となっている。
影響範囲と推奨される対策
この仕様は、GitLab.comの全アカウント、および受信メール機能が有効化されているセルフマネージド（自社運用）版のGitLabインスタンスに影響する。なおGitLab.comでは同機能が標準で有効となっている。GitLab Dedicatedについては機能の提供範囲が異なるため影響を受けない見込みとされているが、Aikido Securityは直接の検証は行えなかったとしている。
GitLabの仕様上、受信メール機能自体の提供を第三者側から止めることはできないが、流出したアドレスを無効化するための対処手順が案内されている。
ユーザーはプロフィールの個人アクセストークン設定ページにアクセスし、「受信メールトークン（incoming email token）」をリセットすることでアドレスを再生成できる。トークンをリセットすると管理下にある全プロジェクトのアドレスが一括で更新されるため、業務等で利用中のアドレスは新しいものに差し替える必要がある。あわせて、公開リポジトリのREADMEやコントリビューションガイド、サポートページなどに誤って自身の起票用アドレスを掲載していないか確認することが推奨されている。