GitLab email-токены, которые должны оставаться приватными, нашли в публичных README, contributing guides и support-страницах open source-проектов. Через такие адреса злоумышленник может не просто завести issue, а открыть merge request от имени владельца токена, сообщает BleepingComputer. Для разработчиков и компаний это неприятный класс риска: баг-репорт превращается в потенциальный вход в цепочку поставки кода.
Речь о встроенной функции GitLab Email work item to this project. Она генерирует специальный email-адрес для проекта: разработчик или внешний пользователь отправляет письмо, а GitLab превращает его в рабочий элемент — например, issue или task. Внутри адреса есть длинная строка с префиксом glimt-; по сути, это credential, привязанный к аккаунту разработчика и его правам в проекте.
Проблема начинается там, где приватный адрес становится частью публичной документации. Команды добавляли его в README, инструкции для контрибьюторов и страницы поддержки, чтобы принимать баг-репорты по почте. Удобно: пользователь не заводит аккаунт, не разбирается в issue tracker, просто пишет письмо. Но если адрес видит весь интернет, его видит и атакующий. Исследователи Aikido за один день нашли около дюжины живых GitLab incoming email-адресов в открытых документах, включая адреса популярных open source-проектов.
Самый важный нюанс: этот адрес не ограничен только созданием issue. По данным Aikido, если заменить в адресе суффикс -issue на -merge-request, GitLab примет письмо и создаст merge request. При этом платформа обрабатывает письмо так, будто действие выполнил владелец токена. Проверки, что письмо пришло именно с email-адреса владельца, нет. Исследователи пишут, что GitLab теперь рассматривает такой защитный слой, но на момент проверки любой внешний почтовый ящик мог отправить сообщение на приватный адрес.
Дальше всё зависит от прав пользователя, чей токен оказался в публичном доступе. Если у аккаунта есть доступ к приватному репозиторию, protected branches, CI/CD или конфиденциальным задачам, последствия становятся заметно серьёзнее обычного спама в issue tracker. Атакующий может попытаться протолкнуть изменение кода, запустить pipeline, добраться до секретов в CI/CD variables, прочитать исходники или закрытые обсуждения. Это не «магический root-доступ к GitLab», но и не безобидный адрес для обратной связи.
Есть и ограничения. Aikido подчёркивает, что права пользователя обойти нельзя: токен не даст больше, чем уже разрешено аккаунту. Кроме самого адреса атакующему нужны path и ID целевого проекта. Для публичных проектов эти данные обычно доступны без трюков. Для приватных ID можно подобрать перебором, но path всё равно должен где-то утечь. То есть атака требует контекста, зато в реальном мире контекст часто лежит рядом: в документации, CI-логах, старых тикетах, wiki или support-шаблонах.
GitLab в документации прямо предупреждает, что такие адреса приватны и созданы персонально для пользователя. Если адрес утёк, токен нужно сбросить. Но история показывает типичную проблему security UX: предупреждение есть, функция удобная, а команды всё равно публикуют секрет в публичном месте, потому что так быстрее собирать баг-репорты. Для open source это особенно болезненно: один неудачный README может открыть путь к проекту, от которого зависят сотни или тысячи downstream-пользователей.
Aikido отправила отчёт в GitLab через HackerOne в мае 2026 года. GitLab закрыл его как intended behavior — ожидаемое поведение функции. После повторного обращения в июне компания обновила интерфейс: добавила упоминание merge request, убрала некорректные формулировки о доступе к данным токена и задокументировала, что входящая почта обходит IP-ограничения. Это важная деталь для корпоративных команд: если вы рассчитывали, что allowlist по IP прикроет GitLab-проект, email-вектор может пройти мимо этой логики.
Практический вывод простой и не очень приятный. GitLab email-токены нужно считать секретами наравне с API-токенами, deploy keys и webhook secrets. Стоит проверить публичные README, CONTRIBUTING.md, docs, wiki, support-страницы и старые шаблоны писем на строки вроде glimt- и адреса incoming email. Если такие адреса уже публиковались, безопаснее сбросить токены, а для баг-репортов использовать публичные формы, обычные issue templates или отдельные почтовые ящики без прав разработчика в репозитории.
Эта история хорошо ложится в общий тренд supply chain-атак: злоумышленники всё чаще ищут не уязвимость в компиляторе или фреймворке, а маленькую щель между удобством команды и моделью доверия платформы. Чем больше автоматизации вокруг репозиториев, CI/CD и трекеров задач, тем важнее регулярно спрашивать: какие «просто служебные» адреса, токены и ссылки на самом деле умеют действовать от имени человека?