Частный адрес электронной почты, который GitLab предоставляет для создания задач по электронной почте, является учетными данными. Любой, кто получит его, сможет отправить патч, который GitLab зафиксирует от вашего имени в любую ветку, в которую вы можете отправлять коммиты, включая main, а также запускать CI/CD задания, которые будут выполняться от вашего имени.
GitLab показывает каждому пользователю этот адрес за кнопкой с надписью «Отправить рабочий элемент на этот проект». Письма, отправленные на него, открывают задачу в этом проекте от вашего имени.
Строка в середине адреса — это токен, привязанный к вашей учетной записи, и, согласно документации GitLab, он не имеет срока действия.
Адрес выглядит так, будто принадлежит одному проекту. Это не так. Aikido Security, сообщившая об этом поведении, обнаружила, что адреса, которые GitLab создает для разных проектов пользователя, используют один и тот же токен, и этот токен применяется ко всем проектам, которые может открыть учетная запись, как публичным, так и частным.
GitLab не проверяет, кто отправил электронное письмо. Любой почтовый ящик может писать на этот адрес, и GitLab будет действовать в соответствии с сообщением, как если бы оно пришло от вас. Тот, кто владеет адресом, может войти в систему от вашего имени и действовать с вашими разрешениями, даже не касаясь вашего почтового ящика.
Адрес позволяет делать больше, чем просто создавать ошибки. Aikido продемонстрировала, как злоумышленник превращает его в способ коммитить код, используя собственную функцию GitLab «merge request by email».
Сам merge request не может быть направлен на копию проекта, контролируемую злоумышленником, поэтому именно прикрепленный патч, а не merge request, содержит код.
Два фактора смягчают эту проблему. Токен несет только ваши собственные разрешения, поэтому дальность проникновения злоумышленника зависит от вашей роли. Утекший адрес для учетной записи Guest почти бесполезен, тогда как адрес для Maintainer может получить доступ к защищенным веткам и секретам CI/CD.
Доступ к проекту также требует большего, чем просто адрес. GitLab определяет цель по пути проекта и его числовому идентификатору, поэтому злоумышленнику, которому нужен конкретный проект, потребуется путь и идентификатор этого проекта, а также токен. Публичные проекты публикуют оба. Частный проект требует отдельной утечки, называющей его, хотя идентификаторы проектов GitLab легко угадать.
Поскольку входящая электронная почта освобождена от ограничений IP-адресов, атака может исходить извне списка разрешенных IP-адресов. Документация GitLab гласит, что входящая электронная почта «не подлежит ограничениям IP-адресов».
Aikido заблокировала частный проект для одного IP-адреса, который не был их собственным. GitLab заблокировал их браузер и отказал в клонировании git, но принял электронное письмо с merge request, и коммит был зафиксирован в main.
Тот же путь обходит двухфакторную аутентификацию. Документация GitLab отмечает, что функции входящей электронной почты работают «без 2FA», даже в экземплярах, которые ее требуют.
Каждая учетная запись GitLab.com имеет один из этих токенов, как и каждый экземпляр GitLab, управляемый самостоятельно, с включенной функцией входящей электронной почты, которая включена по умолчанию на GitLab.com.
GitLab Dedicated, по-видимому, не затронут, поскольку GitLab ограничивает эту функцию управляемыми самостоятельно экземплярами и GitLab.com, но Aikido заявила, что не может напрямую протестировать Dedicated.
Вы не можете запретить другим людям использовать эту функцию, но вы можете отключить утекший адрес.
GitLab изменил текст вокруг токена после отчета Aikido. В описании теперь говорится, что адрес может создавать задачи и merge requests, тогда как раньше он перечислял только рабочие элементы, а GitLab удалил строку, указывающую, что токен не может использоваться для доступа к каким-либо другим данным.
Поведение не изменилось. Токен по-прежнему не имеет срока действия, GitLab по-прежнему не проверяет, кто отправил электронное письмо, и по-прежнему нет переключателя для отдельного пользователя, чтобы отключить эту функцию.
GitLab «открыл задачу» для рассмотрения приема этих писем только с адреса, подтвержденного владельцем учетной записи, но это находится на стадии рассмотрения, а не реализовано.
Aikido заявила, что впервые сообщила об этом поведении через HackerOne в мае 2026 года, где оно было закрыто как преднамеренное поведение, а затем подала конфиденциальную задачу в GitLab в июне. Позиция GitLab, как ее описала Aikido, заключается в том, что это токен, как и любой другой, и что любая утекшая учетная запись приводит к плохим последствиям.
The Hacker News обратилась к GitLab и Aikido за комментариями.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Swati Khandelwal
