GitLabのイシュー作成用メールアドレスは、実質的なアカウント全体アクセストークンだった

【なぜ重要か】 GitLabの「メールでワークアイテムを作成する」機能に使われるメールアドレスには、UIの説明をはるかに超えた権限を持つトークンが埋め込まれている。このアドレスが一つ漏洩するだけで、攻撃者はコードのプッシュ・CI/CDパイプラインの実行・シークレットの窃取などが可能になる。さらに、GitLabのIPアクセス制限すら迂回できることが確認されており、「IPallowlistで守られているから安全」という前提が崩れる。

【ポイント】

• トークンはプロジェクト単位ではなくアカウント全体に有効：UIは「このプロジェクト向けのアドレス」と説明するが、アドレス中の glimt- トークンはアカウントが持つ全プロジェクト（公開・非公開を問わず）に対して有効であり、本質的にはアカウント全体スコープの個人アクセストークン（PAT）に相当する。
• 送信者の検証が行われない：GitLabはメールの送信元アドレスがトークン所有者のアドレスと一致するかを検証しない。そのため、そのアドレスを知っている者なら誰でも、本人として認証・認可されてしまう。
• メールでコードプッシュとCI/CD実行が可能：アドレスのサフィックスを -issue から -merge-request に変えると、.patch ファイルを添付することでブランチへのコミット（main を含む）とCI/CDジョブ実行が可能。.gitlab-ci.yml を改ざんしたパッチを送るだけで攻撃者のコードが被害者の権限で実行される。
• IPアクセス制限を完全に迂回する：ブラウザアクセスもgit cloneも拒否するIPallowlist設定下のプロジェクトに対して、メール経由でのコミットは受け付けられ、main ブランチへの反映が確認された。
• 意図せず公開されているアドレスが実在する：READMEやコントリビューションガイドにバグ報告先として掲載されている「メールアドレス」が実際にはこのトークン入りアドレスであるケースが多数確認された。メールアドレスとして見えるため、秘匿すべきクレデンシャルとは認識されにくい。

【まとめ】 GitLabのイシュー作成用メールアドレスは、単なる通知用の連絡先ではなく、アカウント全体に及ぶ強力なクレデンシャルである。GitLab.comの全アカウントおよびIncoming Emailを有効にした自己管理インスタンスが対象となる。直ちにIncoming Emailトークンをローテーションし、リポジトリ内にこの形式のアドレスが含まれていないかシークレットスキャンを実施すること。また、GitLabのIPallowlistはメール経由のコードプッシュをブロックしないことを前提にセキュリティ設計を見直すべきである。