GitLabの非公開メールアドレス露出でコード改変の恐れ-Incoming email tokenが権限を継承、IP制限も対象外

GitLabの「Email work item to this project」機能で発行される非公開メールアドレスが公開情報へ掲載された場合、第三者がそのアドレスに含まれるIncoming email tokenを利用し、登録ユーザー本人としてIssueやMerge Requestを作成できることが分かりました。

アプリケーションセキュリティ企業Aikido Securityは2026年9月23日、この仕組みを悪用すると、漏えいしたトークンの所有者が持つ権限の範囲でコード変更やCI/CDジョブ実行につながる可能性があると公表しました。同社は公開READMEやコントリビューションガイド、サポートページから有効なGitLabの受信用メールアドレスを複数確認しています。

GitLab自身も現在の公式ドキュメントで、Incoming email tokenには有効期限がなく、このトークンを含む非公開メールアドレスを知る者は本人になりすましてIssueやMerge Requestを作成できるため、秘密として扱うよう案内しています。また、メール経由のIssue／Merge Request作成はIPアクセス制限の対象外です。

一方、これは2026年9月時点でCVEが割り当てられた製品脆弱性ではありません。Aikidoによると、GitLabは5月のHackerOne報告を「intended behavior」としてクローズし、その後の追加報告を受けてUIとドキュメントの説明を変更しました。管理者・利用者側では、公開されているIncoming email addressの有無を確認し、漏えいが疑われる場合はトークンをリセットする必要があります。

GitLab Incoming email token問題のサマリー

確認できている内容：

• GitLabには、メール送信によってIssueやMerge Requestを作成する機能があります。
• 各ユーザーにはIncoming email tokenが割り当てられ、有効期限はありません。
• トークンはプロジェクトごとに表示される非公開メールアドレス内に含まれます。
• GitLab公式ドキュメントは、このメールアドレスを知る第三者が本人としてIssueやMerge Requestを作成できると明記しています。
• GitLab公式ドキュメントは、Incoming emailによるIssue／Merge Request作成がIPアクセス制限の対象外であることも明記しています。
• Aikidoは、同一ユーザーの複数プロジェクト向けメールアドレスに同じIncoming email tokenが含まれることを確認しました。
• Aikidoは、Merge Requestへのパッチ添付を利用し、被害ユーザーが書き込み権限を持つブランチへコード変更を反映できることを検証したとしています。
• CI/CD設定を変更できる権限がある場合、CI/CDジョブ実行やCI/CD変数への影響につながる可能性があります。
• 攻撃者が得られる権限は、漏えいしたトークンの所有者が本来持っているGitLab権限を超えません。
• Aikidoは公開README、CONTRIBUTING文書、サポートページなどから十数件の有効な受信用メールアドレスを確認したとしています。
• GitLabは報告後、UIとドキュメントを変更し、Incoming email tokenでMerge Requestも作成できることや、IP制限の対象外であることを明記しました。
• GitLabはIncoming email tokenのリセット機能を提供しています。
• 2026年9月25日時点で、本件にCVE番号は確認できません。
• GitLabが本件を対象にセキュリティパッチを公開した事実も確認できません。

GitLabはメールでIssueやMerge Requestを作成できる

GitLabには、Web画面を開かずにメールからIssueやMerge Requestを作成する機能があります。

プロジェクトの「Email work item to this project」から、ユーザー専用の受信用メールアドレスを取得できます。

GitLab公式ドキュメントは、このアドレスについて「private email address」であり、ユーザーごとに生成されると説明しています。

メールを送信すると、送信内容を基に新しいIssueが作成され、作成者はそのメールアドレスを発行したGitLabユーザーとして記録されます。

GitLabは現在、このメールアドレスを第三者へ共有しないよう明確に警告しています。理由は、アドレスを知る者が本人になりすましてIssueやMerge Requestを作成できるためです。

メールアドレス内のIncoming email tokenは有効期限なし

GitLabのToken overviewによると、各ユーザーにはIncoming email tokenが割り当てられています。

このトークンに有効期限はありません。

また、Incoming email tokenは、ユーザーごとに生成されるプロジェクト固有の受信用メールアドレスに含まれています。

通常のメールアドレスは第三者へ知らせることを前提とした識別子ですが、GitLabの受信用アドレスは認証情報を内包しています。

そのため、README、公開ドキュメント、Issue、サポートページなどへこのアドレスを掲載すると、メールアドレスそのものではなく「認証トークンを公開した」状態になる可能性があります。

GitLabは漏えいが疑われる場合、Incoming email tokenを直ちにリセットするよう案内しています。

Aikidoは公開ドキュメントから有効なアドレスを十数件確認

Aikidoは、GitLabの受信用メールアドレスが実際に公開情報へ掲載されていないか調査しました。

同社によると、1日の調査でREADME、CONTRIBUTINGガイド、サポートページなどから十数件の有効なIncoming email addressを発見しました。

一部は利用者から不具合報告を受け付けるため、プロジェクト管理者が意図的に公開していたとされています。

Aikidoは、受信用アドレスが一般的な問い合わせ先メールアドレスのように見えることが、公開につながる一因だと分析しています。

GitLabの現在のUIとドキュメントは「private email address」として秘密にするよう警告していますが、過去に公開したアドレスがREADMEやWebページ、パッケージ情報などへ残っている場合は別途確認が必要です。

Aikidoはメール経由でコード変更まで可能と検証

GitLab公式ドキュメントが明示している機能は、Incoming email tokenを使ったIssueとMerge Requestの作成です。

Aikidoはさらに検証を行い、Merge Request作成メールへGitパッチを添付すると、そのパッチがソースブランチへ適用される動作を確認したとしています。

漏えいしたトークンの所有者が対象ブランチへ書き込み可能な場合、第三者がそのユーザーの権限を使ってコード変更を反映できる可能性があります。

また、変更対象にCI/CD設定が含まれ、かつユーザーの権限でパイプラインを実行できる場合、CI/CDジョブの起動につながる可能性があります。

ここで「メールアドレスが漏れるだけで誰でもGitLabのmainブランチを改ざんできる」と表現するのは正確ではありません。

影響は、漏えいしたIncoming email tokenの所有者が持つ権限に依存します。

Guestなど書き込み権限の弱いユーザーと、Maintainerなど強い権限を持つユーザーでは、漏えい時の影響が大きく異なります。

トークンはユーザー権限を継承、権限そのものは昇格しない

Aikidoは、Incoming email tokenを使っても、本来のユーザー権限を超える権限昇格は起きないと説明しています。

つまり、攻撃者はトークンを取得しただけでOwnerやMaintainerになれるわけではありません。

一方、トークンが強い権限を持つアカウントに紐付いている場合、影響は大きくなります。

例えばMaintainer権限を持つユーザーのトークンが公開されていた場合、同ユーザーが書き込めるブランチ、作成できるMerge Request、実行できるCI/CD処理などが攻撃経路になり得ます。

CI/CD環境では、ソースコードだけでなく、クラウド認証情報、デプロイトークン、APIキーなどが変数として管理される場合があります。

したがって、Incoming email tokenの漏えいは単なるIssueスパムとしてではなく、所有者のGitLab権限を代行できる認証情報の漏えいとして扱う必要があります。

同じIncoming email tokenが複数プロジェクトで使われる

Aikidoは、1人のユーザーが複数プロジェクトで「Email work item to this project」を開いた場合、表示されるメールアドレスはプロジェクトごとに異なる一方、内部に含まれるIncoming email tokenは同一だったと報告しています。

GitLab公式ドキュメントも、Incoming email tokenを「各ユーザーが持つトークン」と説明しています。

このため、1つのプロジェクト向け受信用メールアドレスが漏えいした場合、そのトークン自体をユーザー単位の秘密情報として扱う必要があります。

Aikidoによると、別プロジェクトへ作用させるには対象プロジェクトを識別する情報も必要です。

公開プロジェクトではプロジェクトパスなどの情報を取得しやすい一方、非公開プロジェクトでは追加情報が必要になるため、漏えいしたトークンだけで任意の非公開プロジェクトを自動的に特定できるわけではありません。

IPアドレス制限を設定していてもメール経由は対象外

今回の調査で企業利用者に影響が大きい点の一つが、IPアクセス制限との関係です。

GitLab公式の「Group access and permissions」は現在、Incoming email tokenを使ったメール経由のIssue／Merge Request作成について、IPアクセス制限の対象外であることを明記しています。

Aikidoも、許可IPを限定した非公開プロジェクトで検証し、ブラウザアクセスやGit cloneは拒否された一方、Incoming email経由の処理は受け付けられたと報告しています。

そのため、企業VPNや固定IPだけからGitLabへアクセスできるよう設定していても、Incoming emailの経路まで同じ境界で保護されるとは限りません。

GitLab自身もIP制限について「complete firewall」ではないと説明しています。

2FAを強制してもIncoming emailでは追加認証されない

GitLab Self-Managed向けのIncoming email設定ドキュメントには、もう一つ管理上の注意点があります。

GitLabは、インスタンスで2要素認証（2FA）を強制している場合でも、Incoming email機能を利用する際に2FA認証は要求されないと説明しています。

Incoming email token自体が認証手段として扱われるためです。

そのため、強制2FAを導入している組織でも、Incoming email tokenが公開されれば、メール経由の操作に対して2FAが追加防御にはなりません。

GitLabは「脆弱性修正」ではなくUIとドキュメントを変更

Aikidoは2026年5月、HackerOne経由でGitLabへこの問題を報告しました。

Aikidoによると、この報告は「intended behavior」としてクローズされました。

同社は6月にGitLabの非公開Issueとして追加報告を行い、GitLabはその後、Incoming email tokenの機能説明を修正しています。

GitLabのMerge Request「Align incoming email token capability across UI and docs」では、従来ばらつきがあったIncoming email tokenの説明を、UIとドキュメント全体で一致させる変更が行われました。

主な変更は次のとおりです。

• Incoming email tokenでIssueだけでなくMerge Requestも作成できることを明記
• トークンを秘密として保護する必要があることを明確化
• トークンのリセット方法を分かりやすく記載
• Incoming emailがIPアクセス制限の対象外であることをドキュメントへ追加

GitLabが新しいCVEを割り当てたり、特定バージョン向けのセキュリティパッチを公開した事実は確認できません。

つまり、今回の対応は「影響バージョンを修正版へ更新すれば解決する」タイプの脆弱性対応ではありません。

現時点でCVE・CVSS・CISA KEVは対象外

2026年9月25日時点で、今回のIncoming email token問題についてCVE番号は確認できません。

そのため、CVSSスコアもありません。

CISA Known Exploited Vulnerabilities（KEV）はCVE単位のカタログであり、本件についてKEV掲載を評価する段階でもありません。

また、AikidoとBleepingComputerの報告では、公開されていた受信用メールアドレスを第三者が実際のサプライチェーン攻撃やリポジトリ侵害に悪用した事例は示されていません。

確認されているのは、公開された有効なIncoming email addressが複数存在したことと、Aikidoが制御された環境でコード変更やCI/CD実行につながる経路を実証したことです。

GitLab管理者・開発部門が確認したいポイント

GitLabを利用している企業では、今回の問題を「メールアドレスの公開」ではなく「認証トークンの公開」として確認する必要があります。

• README、CONTRIBUTING、Wiki、Issue、Webサイト、サポートページにGitLabのIncoming email addressを掲載していないか検索する
• Gitリポジトリの過去コミットにも受信用メールアドレスが残っていないか確認する
• 公開されていた可能性があるユーザーはIncoming email tokenをリセットする
• リセット後、過去のプロジェクト向け受信用アドレスが無効になったことを確認する
• Maintainer、Ownerなど強い権限を持つユーザーを優先して調査する
• Incoming email tokenを通常のAPIキーやPersonal Access Tokenと同様の秘密情報として扱う
• Secret scanningの対象へIncoming email tokenのパターンを追加する
• IP allowlistやVPNだけをGitLabの唯一のアクセス境界とみなさない
• Incoming emailを利用していない組織では、Self-Managed環境のメール受信機能が本当に必要か確認する
• Merge Request、Push、Pipelineの監査ログから不審なメール経由操作がないか確認する
• CI/CD変数に長期利用のクラウド認証情報や高権限シークレットを置き過ぎていないか確認する

GitLab公式の現在の案内では、漏えいが疑われる場合の直接的な対応はIncoming email tokenのリセットです。

なお、GitLabは2026年9月に別件のCritical脆弱性も相次いで修正しています。今回のIncoming email token問題はそれらのCVEとは別であり、GitLab本体のバージョン更新だけでは公開済みトークンへの対応になりません。

関連記事：

• GitLabがCritical Patch Release公開、CVSS 9.9の脆弱性 2件を修正　Self-Managedは19.4.1などへ更新を
• GitLabのCVE-2026-85706、公開翌日にサイバー攻撃に悪用確認　CVSS 10.0、CISA KEVへ追加

出典

• Create an issue – GitLab Documentation
• GitLab token overview – GitLab Documentation
• Group access and permissions – GitLab Documentation
• Incoming email – GitLab Documentation
• Exposure of confidential secret or token GitLab incoming email token – GitLab Documentation
• Align incoming email token capability across UI and docs – GitLab
• Email verification for incoming email token actions – GitLab
• Send GitLab an email, push to main – Aikido Security
• Exposed GitLab project email addresses let attackers push code – Bleeping