PTIR — Daily Briefing — 2026-09-27
by
Executive Summary
GitLab’s project-specific incoming email addresses contain a user token that does not expire. Anyone who obtains one can create issues and merge requests as that user. Because these addresses are easily mistaken for ordinary contact information, they can leak through repositories, documentation, tickets, notes, chat logs, and email archives.
Action Queue
Treat GitLab incoming-email addresses as credentials
GitLab’s token documentation says each user has a non-expiring incoming-email token embedded in personal project-specific addresses. GitLab explicitly warns that anyone with the token can create issues and merge requests as the user. Its issue-creation documentation likewise describes the generated address as private and provides a reset control.
Recommended action: If GitLab is in use, search private repositories, documentation, password-manager notes, saved contacts, ticketing systems, and mail archives for GitLab addresses containing an incoming-email token. Do not paste any findings into a public scanner or chatbot. Reset the token immediately if an address was shared beyond its intended location, then replace legitimate saved addresses. Review recent issues and merge requests for unexpected email-originated activity.
- Urgency: This week; immediate if a tokenized address is found in a public or broadly shared location
- Importance: ★★★★☆
- Verified active: September 27, 2026
- Deadline: No fixed deadline
- Cost: Free
- Requirements: A GitLab account; access to relevant repositories and internal search systems
- Official instructions: Review and reset the incoming email token
PKb Candidates
Secret taxonomy: An email address can be an authentication credential. Store GitLab incoming-email addresses alongside tokens—not ordinary contacts—and include them in secret-scanning and incident-response procedures.
tags: cybersecurity - gitlab - software-supply-chain - secrets-management - devsecops