issueをメールで作成するための、一見ありふれた機能が、実際には完全な権限を持つアカウントに等しい存在だったことが分かりました。Aikido SecurityのJoe Leon氏は、GitLabの非公開メールアドレスに永続的なトークンが含まれていることを実証しました。このトークンを入手した人物は、所有者になりすまして、リポジトリへ直接コードをコミットしたり、自動化されたCI/CDのビルド・デプロイパイプラインを起動したりできます。
GitLabは各ユーザーに、メールでissueを作成するための専用メールアドレスを発行しています。このアドレスには「glimt-」で始まる文字列が埋め込まれており、GitLabはこれを受信メール用のトークンとして利用しています。GitLabの公式ドキュメントによると、このトークンに有効期限はなく、厳重に秘匿する必要があります。トークンを入手した人物なら誰でも、正規の所有者になりすましてissueやマージリクエストを偽造できるためです。
「glimt-」トークンが持つ広範な権限
Leon氏は、メールアドレスが1つのプロジェクトだけに紐づいているように見えても、その基盤となるトークンははるかに広い権限を持つことを突き止めました。同じアカウント内の別のプロジェクトでこのメール機能を生成すると、アドレスのうちプロジェクト固有の部分は変わります。しかし、中核となる「glimt-」トークンはまったく変わりません。そのため、トークンの権限は、ユーザーのアカウントが現在アクセスできるすべてのプロジェクトに及びます。権限の仕組みについては、GitLabによるアクセスと権限の定義が参考になります。
攻撃者は、issueの作成にとどまらずコードの改ざんまで踏み込むには、メールアドレス内の「issue」という接尾辞を「merge-request」に置き換えるだけで済みます。GitLabはもともと、こうしたメールに添付された「.patch」ファイルを受け付け、その変更をソースブランチに適用する仕組みになっています。対象ブランチ名は、メールの件名で指定できます。指定したブランチが存在し、かつトークンの所有者にそこへコミットする権限があれば、GitLabは所有者の名義でそのままコミットを取り込みます。この仕組みの詳細は、GitLabのメールでmainにプッシュできる手口を解説した完全版レポートで確認できます。
ネットワークセキュリティとIP制限を回避
Aikidoのチームは、厳密に管理した検証で、件名に「main」を指定し、細工した「.patch」ファイルを添付しました。すると、コミットは非公開リポジトリのメインブランチに問題なくマージされました。この不正な変更が「.gitlab-ci.yml」ファイルを書き換え、しかも侵害されたユーザーにパイプラインのジョブを起動する権限があれば、攻撃者は任意のCI/CDコードを容易に実行できます。その後、アクセス可能な環境変数や厳重に保護されたシークレットの窃取を試みたり、「CI_JOB_TOKEN」を悪用したりする恐れもあります。
さらに、このメール経由の攻撃手法は、システム管理者が頼りにしがちなネットワーク上の防御を難なくすり抜けます。検証では、特定の外部IPアドレス1つからのアクセスだけを許可するようプロジェクトを制限しました。Leon氏のマシンからのWebインターフェースへのアクセスや通常の「git clone」コマンドは直ちに失敗しました。ところが、GitLabはメールによる送信内容をあっさり受け付けました。GitLab自身のドキュメントにも、受信メールが通常のIPフィルタリングの制約を完全に受けないことが明記されています。
ロールごとの制約と緩和策
重要なのは、このシナリオ単体で権限が自然に昇格するわけではない点です。被害の大きさは、漏えいしたアドレスの所有者が持つロールに左右されます。「Guest」ユーザーのトークンでは、コードを改ざんすることはほぼできません。一方、「Maintainer」のアドレスが漏れると、厳重に保護されたブランチや、機密性の高いCI/CDインフラにまで侵入を許しかねません。別の非公開プロジェクトを攻撃するには、攻撃者がその正確な内部パスと一意の識別子も把握している必要があります。
Aikidoは、公開ドキュメントやプロジェクトのREADMEファイルに散在する、有効な受信メールアドレスを約12件発見しました。なかには、開発者がバグ報告の連絡先として意図的に公開していたケースもありました。同社のセキュリティチームは、調査結果の公開前に、影響を受けるすべての所有者へ責任を持って通知しています。現時点で、この仕組みが実際に悪用された確かな証拠はありません。実証はすべて、Aikidoが直接管理するリポジトリ内に限って実施されました。
この深刻な脆弱性は、2026年5月にHackerOne経由で最初に報告されました。しかし、報告は意図された仕様として分類され、素っ気なく終了されました。6月に、より切迫した内容で再度問い合わせたところ、GitLabは静かにインターフェースとドキュメントを修正しました。他のデータにアクセスできないという誤った記述を削除し、マージリクエストの可能性に明示的に言及したほか、IPフィルタの適用除外も明記しました。ただし、メール経由でコードをコミットできる仕組みそのものは、まったく変わっていません。
この発見には正式なCVE番号がなく、専用のソフトウェアパッチも、公式のセキュリティ情報も出ていません。Aikidoの評価によると、受信メール機能が有効なGitLab.comのすべてのアカウントと、セルフホスト版のインストール環境が危険にさらされています。GitLab Dedicated環境については、まだ評価していません。このアドレスが漏れた可能性が少しでもある場合、Aikidoは、受信メールトークンを直ちにリセットするよう強く勧めています。あわせて、リポジトリ内にこうしたアドレスが含まれていないかスキャンし、漏えいした暗号鍵と同じ最大限の深刻さで扱うことも推奨しています。
GitLabをめぐっては最近も混乱が続いており、このリスクはとりわけ大きく見えます。今年9月には、攻撃者が別の重大な脆弱性「CVE-2026-85706」を突き、サーバーを積極的に攻撃しました。Aikidoの先駆的な調査が明らかにしたのは、まったく異なる種類の危険です。メールの認証情報そのものが不用意に公開されてしまえば、複雑なソフトウェアの欠陥がなくても、壊滅的な被害を招けることを示しました。
翻訳元: https://meterpreter.org/gitlab-email-token-vulnerability/
