Обычная функция для отправки задач по почте оказалась гораздо ближе к полноценной учётной записи, чем кажется по интерфейсу. Джо Леон из Aikido Security показал, что закрытый адрес GitLab содержит постоянный токен, с которым можно отправлять код в репозитории и запускать автоматические задания сборки и развёртывания CI/CD от имени владельца.
GitLab выдаёт пользователю персональный адрес для создания задач по электронной почте. Внутри адреса находится строка с префиксом glimt-, которую платформа использует как incoming email token. Документация GitLab указывает, что такой токен не имеет срока действия и должен храниться в секрете, поскольку получивший его человек может создавать задачи и запросы на слияние от имени владельца.
Леон обнаружил, что адрес выглядит привязанным к отдельному проекту, но встроенный токен работает шире. При открытии почтовой функции в разных проектах аккаунта меняются части адреса, связанные с проектом, тогда как сам glimt-токен остаётся тем же. Его полномочия распространяются на проекты, к которым уже имеет доступ учётная запись пользователя.
Для перехода от создания задачи к изменению кода достаточно заменить в адресе суффикс issue на merge-request. GitLab умеет принимать в таком письме файлы .patch и применять изменения к исходной ветке. Название ветки передаётся в теме письма. Если ветка существует и владелец токена вправе отправлять туда изменения, GitLab добавляет коммит от его имени.
В контролируемом тесте Aikido указала в теме main и приложила подготовленный файл .patch. Коммит попал в основную ветку частного проекта. Если изменения затрагивают .gitlab-ci.yml и права пользователя разрешают запуск задания, тем же способом можно выполнить CI/CD-код, а затем попытаться прочитать доступные переменные, секреты или использовать CI_JOB_TOKEN.
Почтовый путь также обходит сетевой барьер, на который могут рассчитывать администраторы. В тестовом проекте разрешили доступ только с одного чужого IP-адреса: веб-интерфейс и git clone с машины Леона перестали работать, однако письмо GitLab принял. В документации платформы прямо указано, что входящая почта не подпадает под IP-ограничения.
Сценарий не повышает привилегии сам по себе. Возможности зависят от роли владельца утёкшего адреса: токен пользователя Guest почти бесполезен для изменения кода, тогда как адрес Maintainer способен дать доступ к защищённым веткам и чувствительным данным CI/CD. Для атаки на другой закрытый проект также нужно знать его путь и идентификатор.
Aikido нашла в открытой документации и README около дюжины действующих входящих адресов, часть которых разработчики публиковали специально как контакты для сообщений об ошибках. Перед публикацией материала команда предупредила владельцев. Данных о реальных атаках через такой механизм нет, а демонстрацию проводили только на проектах под контролем Aikido.
О проблеме сообщили через HackerOne в мае 2026 года, но обращение закрыли как предусмотренное поведение. После отдельного обращения в июне GitLab скорректировала интерфейс и документацию: убрала утверждение о невозможности доступа к другим данным, добавила упоминание запросов на слияние и описала исключение для IP-фильтра. Сам механизм отправки кода по почте остался прежним.
У находки нет CVE, отдельного исправления или бюллетеня безопасности. По оценке Aikido, сценарий относится ко всем аккаунтам GitLab.com и самостоятельно развёрнутым инсталляциям с включённой входящей почтой; GitLab Dedicated команда не проверяла. Если адрес мог попасть наружу, Aikido советует сбросить incoming email token и искать такие адреса в репозиториях как обычные секреты.
Риск особенно заметен на фоне других проблем вокруг GitLab: в сентябре злоумышленники уже атаковали серверы через отдельную критическую уязвимость CVE-2026-85706. Работа Aikido описывает другой класс угрозы, где для опасных действий не требуется программная ошибка, если наружу попала сама почтовая учётная информация.