Скрытый за пунктом «Отправить рабочий элемент в этот проект по электронной почте» адрес GitLab фактически служит бессрочным ключом учётной записи. Получивший его человек может создавать от имени владельца задачи и запросы на слияние, отправлять изменения в доступные ветки и запускать задания CI/CD. Доступ к почтовому ящику жертвы ему не нужен; ограничения по IP и двухфакторная аутентификация, или 2FA, такую отправку не останавливают.
В адрес встроен токен, привязанный к пользователю. Один и тот же секрет используется во всех проектных адресах этого пользователя и действует для каждого публичного либо закрытого проекта, к которому у него есть доступ. Документация GitLab прямо указывает, что токен не истекает. Адрес отправителя при этом не проверяется: письмо разрешено послать с любого почтового ящика, а созданная запись будет подписана именем владельца токена.
Aikido Security описала практический способ превратить создание задачи в загрузку кода. В адресе достаточно заменить суффикс -issue на -merge-request, подготовить патч, указать целевую ветку в теме письма и приложить файл. Функция «запрос на слияние по электронной почте» применит патч к названной ветке, а при её отсутствии создаст новую. Коммит получит авторство владельца токена. Направить запрос в подконтрольную злоумышленнику копию проекта нельзя, поэтому вредоносный код переносится именно вложенным патчем.
Доступны все ветки, куда владелец вправе отправлять изменения, иногда включая main. Особенно опасна правка файла .gitlab-ci.yml: после неё GitLab способен запустить заданные отправителем задания CI/CD с полномочиями и идентичностью владельца адреса. У токена пользователя с ролью Guest возможностей немного. Токен Maintainer может дать путь к защищённым веткам и секретам CI/CD, если действующие настройки проекта разрешают владельцу соответствующие операции.
Для атаки нужны сам токен, путь проекта и его числовой идентификатор. У публичных проектов путь и ID открыты. Закрытый проект сначала требуется обнаружить через отдельную утечку, хотя, по данным исследователей, числовые ID проектов сравнительно легко угадываются. Сам токен не расширяет права учётной записи: он позволяет удалённо использовать уже выданные разрешения, что при высоких ролях вполне достаточно для серьёзного ущерба.
Проверка Aikido Security показала обход IP allowlist на закрытом проекте, разрешавшем соединения лишь с одного постороннего для исследователей IP-адреса. Вход через браузер блокировался, команда git clone получала отказ, но письмо с запросом на слияние GitLab принял, после чего коммит оказался прямо в main. Почтовые функции работают и без 2FA, в том числе на инсталляциях, где двухфакторная аутентификация обязательна.
Такой токен есть у каждой учётной записи , где входящая почта включена по умолчанию. Самостоятельно развёрнутые экземпляры GitLab уязвимы при активированной обработке входящих писем. GitLab Dedicated, судя по доступным сведениям, не затронут: функция ограничена и self-managed-инсталляциями. Напрямую проверить Dedicated специалисты Aikido не смогли.
Скомпрометированный секрет сбрасывается на странице персональных токенов доступа, personal access tokens page. Сброс одновременно аннулирует все проектные почтовые адреса пользователя, поэтому легитимные адреса придётся заменить новыми. Стоит проверить README, руководства для участников и страницы поддержки: Aikido обнаружила около дюжины действующих адресов, большинство из которых намеренно публиковали для приёма сообщений об ошибках. Некоторые находились в популярных проектах с открытым исходным кодом.
Администратор self-managed-инсталляции может глобально отключить входящую почту. Отдельный пользователь запретить создание задач и запросов на слияние через письма не может. После сообщения Aikido GitLab уточнила описание токена: теперь там сказано о создании задач и merge request, тогда как раньше упоминались лишь рабочие элементы. Компания также убрала утверждение, будто токен не позволяет обращаться к другим данным. Поведение механизма не изменилось: срок действия отсутствует, отправитель не проверяется, индивидуального выключателя нет. GitLab открыла задачу о приёме писем только с подтверждённого адреса учётной записи, но эта защита пока не реализована.
В мае 2026 года Aikido сообщила о проблеме через HackerOne, однако отчёт закрыли как описание предусмотренного поведения. В июне 2026 года исследователи создали конфиденциальную задачу непосредственно в GitLab. По изложению Aikido, позиция GitLab сводится к тому, что адрес содержит обычный секретный токен, а утечка любого такого реквизита закономерно ведёт к опасным последствиям. The Hacker News запросила комментарии у GitLab и Aikido.
Изображение носит иллюстративный характер
В адрес встроен токен, привязанный к пользователю. Один и тот же секрет используется во всех проектных адресах этого пользователя и действует для каждого публичного либо закрытого проекта, к которому у него есть доступ. Документация GitLab прямо указывает, что токен не истекает. Адрес отправителя при этом не проверяется: письмо разрешено послать с любого почтового ящика, а созданная запись будет подписана именем владельца токена.
Aikido Security описала практический способ превратить создание задачи в загрузку кода. В адресе достаточно заменить суффикс -issue на -merge-request, подготовить патч, указать целевую ветку в теме письма и приложить файл. Функция «запрос на слияние по электронной почте» применит патч к названной ветке, а при её отсутствии создаст новую. Коммит получит авторство владельца токена. Направить запрос в подконтрольную злоумышленнику копию проекта нельзя, поэтому вредоносный код переносится именно вложенным патчем.
Доступны все ветки, куда владелец вправе отправлять изменения, иногда включая main. Особенно опасна правка файла .gitlab-ci.yml: после неё GitLab способен запустить заданные отправителем задания CI/CD с полномочиями и идентичностью владельца адреса. У токена пользователя с ролью Guest возможностей немного. Токен Maintainer может дать путь к защищённым веткам и секретам CI/CD, если действующие настройки проекта разрешают владельцу соответствующие операции.
Для атаки нужны сам токен, путь проекта и его числовой идентификатор. У публичных проектов путь и ID открыты. Закрытый проект сначала требуется обнаружить через отдельную утечку, хотя, по данным исследователей, числовые ID проектов сравнительно легко угадываются. Сам токен не расширяет права учётной записи: он позволяет удалённо использовать уже выданные разрешения, что при высоких ролях вполне достаточно для серьёзного ущерба.
Проверка Aikido Security показала обход IP allowlist на закрытом проекте, разрешавшем соединения лишь с одного постороннего для исследователей IP-адреса. Вход через браузер блокировался, команда git clone получала отказ, но письмо с запросом на слияние GitLab принял, после чего коммит оказался прямо в main. Почтовые функции работают и без 2FA, в том числе на инсталляциях, где двухфакторная аутентификация обязательна.
Такой токен есть у каждой учётной записи , где входящая почта включена по умолчанию. Самостоятельно развёрнутые экземпляры GitLab уязвимы при активированной обработке входящих писем. GitLab Dedicated, судя по доступным сведениям, не затронут: функция ограничена и self-managed-инсталляциями. Напрямую проверить Dedicated специалисты Aikido не смогли.
Скомпрометированный секрет сбрасывается на странице персональных токенов доступа, personal access tokens page. Сброс одновременно аннулирует все проектные почтовые адреса пользователя, поэтому легитимные адреса придётся заменить новыми. Стоит проверить README, руководства для участников и страницы поддержки: Aikido обнаружила около дюжины действующих адресов, большинство из которых намеренно публиковали для приёма сообщений об ошибках. Некоторые находились в популярных проектах с открытым исходным кодом.
Администратор self-managed-инсталляции может глобально отключить входящую почту. Отдельный пользователь запретить создание задач и запросов на слияние через письма не может. После сообщения Aikido GitLab уточнила описание токена: теперь там сказано о создании задач и merge request, тогда как раньше упоминались лишь рабочие элементы. Компания также убрала утверждение, будто токен не позволяет обращаться к другим данным. Поведение механизма не изменилось: срок действия отсутствует, отправитель не проверяется, индивидуального выключателя нет. GitLab открыла задачу о приёме писем только с подтверждённого адреса учётной записи, но эта защита пока не реализована.
В мае 2026 года Aikido сообщила о проблеме через HackerOne, однако отчёт закрыли как описание предусмотренного поведения. В июне 2026 года исследователи создали конфиденциальную задачу непосредственно в GitLab. По изложению Aikido, позиция GitLab сводится к тому, что адрес содержит обычный секретный токен, а утечка любого такого реквизита закономерно ведёт к опасным последствиям. The Hacker News запросила комментарии у GitLab и Aikido.
