GitLab email-адреса, которые платформа автоматически выдает пользователям для создания задач через почту, могут работать как скрытые токены с широкими правами. Проблема опасна не красотой атаки, а ее бытовой простотой: если такой адрес утек в README, тикет или инструкцию поддержки, его можно использовать для атак на цепочку поставок без взлома аккаунта.
О риске 23 сентября 2026 года сообщает Dark Reading со ссылкой на исследование Aikido Security. Речь идет о функции GitLab Incoming Email: пользователь получает специальный адрес, отправляет на него письмо, а GitLab создает issue или другой рабочий объект от имени этого пользователя. Похожая механика есть у Trello, Todoist, Monday.com и других сервисов, но в случае GitLab, по выводам исследователей, адрес оказался не просто адресом.
Внутри такого адреса находится неистекающий токен с префиксом glimt-, расшифровываемым как GitLab Incoming Mail Token. Исследователь Aikido Джо Леон утверждает, что один и тот же токен применяется для публичных и приватных проектов, к которым у пользователя есть доступ. Если адрес для публичного проекта опубликован, атакующий может попробовать изменить путь проекта и его ID в адресе, чтобы дотянуться до других репозиториев. ID, по словам исследователей, можно угадывать, хотя для атаки все равно нужен утекший или известный project name.
Главная неприятность не в том, что кто-то создаст лишний issue с мемом про продакшен. По словам Леона, функциональность входящей почты в GitLab со временем стала шире: через нее можно отправлять merge request и patch-файлы. В худшем сценарии это превращается в возможность протолкнуть код в приватный проект, попасть в основную ветку или запустить CI/CD-задачу. Для компаний, которые строят пайплайны поставки вокруг GitLab, это уже не мелкая UX-недосказанность, а вход в сценарий supply chain attack.
Особенно неловко выглядит контраст между интерфейсом и реальным поведением. В UI GitLab адрес описывался как инструмент для добавления рабочих элементов в конкретный проект, а также содержал формулировку о том, что через него нельзя получить доступ к другим данным. Aikido считает это неверным: credential, встроенный в адрес, можно переиспользовать на всех проектах, где у владельца токена есть права. После обращения исследователей GitLab изменила текст интерфейса и документацию, уточнив, что адрес может применяться для merge request, а ограничения по IP на него не распространяются.
С IP-ограничениями история отдельная. Леон проверил частный проект, доступ к которому был ограничен одним случайным IP-адресом, не принадлежащим исследователю. Веб-доступ и клонирование репозитория были заблокированы, но письмо с merge request прошло через GitLab. Для security-команд это неприятный сигнал: привычная граница доступа работает для браузера и Git-клиента, но не обязательно для вспомогательных каналов, которые годами считались удобной автоматизацией.
Aikido сообщила о находке GitLab через HackerOne в мае 2026 года. GitLab закрыла отчет как intended behavior, то есть ожидаемое поведение продукта. В июне исследователи завели конфиденциальный issue в репозитории GitLab. На момент публикации материала Dark Reading компания не дала комментарий изданию, но уже обновила интерфейс и документацию. Это важная деталь: вендор не признал классическую уязвимость в духе CVE-парада, однако практический риск для пользователей все равно пришлось описывать яснее.
Масштаб утечек пока не измерен. Леон говорит, что за пару часов поверхностного поиска нашел около дюжины намеренно опубликованных входящих адресов в README и support-файлах. Несколько, по его словам, относились к популярным open source-проектам. Это не статистика по всей экосистеме, но хороший тест на здравый смысл: если секрет выглядит как email, люди будут обращаться с ним как с email. А потом удивляться, почему секреты снова оказались в репозитории.
Для разработчиков и DevSecOps-команд вывод короткий: GitLab email-адреса нужно считать секретами, а не контактной информацией. Их стоит искать в репозиториях, документации, wiki, issue tracker, CI-конфигах и внутренних базах знаний теми же инструментами, которыми команды ищут токены, ключи API и пароли. Aikido советует превентивно ротировать токены во входящих адресах и уменьшать поверхность атаки, удаляя опубликованные значения. Если компания использует GitLab в критичных пайплайнах, проверку лучше не откладывать до следующего квартального аудита.
Самое разумное изменение, которое предлагает Леон, — требовать совпадения адреса отправителя с email пользователя в GitLab. Тогда атакующему пришлось бы компрометировать почтовый ящик владельца, а не просто найти токенизированный адрес в интернете. По словам исследователя, GitLab рассматривает такой вариант. И это хороший пример того, как старая удобная фича внезапно становится частью модели угроз: чем больше автоматизации вокруг разработки, тем меньше права на невинные каналы, которые никто не проверял как полноценный API.