Частният имейл адрес, който GitLab ви предоставя за създаване на задачи (issues) чрез имейл, представлява идентификационни данни за достъп. Всеки, който се сдобие с него, може да изпрати корекция по имейл, която GitLab да потвърди от ваше име във всеки клон, в който имате права да качвате, включително main, както и да стартира CI/CD задачи, изпълняващи се с вашите права.
GitLab показва този адрес на всеки потребител зад бутон с надпис „Email work item to this project“. Изпратеното на него писмо отваря задача в съответния проект, с автор вие.
Низът в средата на адреса е токен, свързан с вашия акаунт, и според документацията на GitLab той не изтича.
Адресът изглежда така, сякаш принадлежи само на един проект. Но това не е така. От Aikido Security, които докладваха това поведение, установиха, че адресите, които GitLab създава за различните проекти на даден потребител, споделят един и същ токен, и че този токен се прилага за всеки проект, до който акаунтът има достъп – публичен или частен.
GitLab не проверява кой е изпратил имейла. Всяка пощенска кутия може да пише до адреса и GitLab обработва съобщението така, сякаш е дошло от вас. Който разполага с адреса, може както да се представи за вас, така и да действа с вашите разрешения, без изобщо да има достъп до личната ви пощенска кутия.
Адресът прави нещо повече от създаване на съобщения за грешки. От Aikido показаха как държателят му може да го превърне в начин за добавяне на код, използвайки функцията на GitLab за заявка за сливане (merge request) по имейл:
- Променете наставка на адреса от -issue на -merge-request. Тогава GitLab отваря заявка за сливане вместо задача.
- Напишете корекция (patch) и поставете името на целевия клон в темата на имейла.
- Прикачете корекцията и я изпратете. GitLab прилага корекцията към този клон и го създава, ако той все още не съществува.
- Промяната се записва като commit в този клон, с автор вие. Ако това е клон, към който имате права за push, това включва и main.
- Ако корекцията редактира файла .gitlab-ci.yml на проекта и ролята ви го позволява, GitLab стартира задачата на атакуващия от ваше име.
Самата заявка за сливане не може да бъде насочена към копие на проекта, контролирано от атакуващия, поради което прикаченият файл с корекции, а не заявката за сливане, носи кода.
Две неща предотвратяват това да бъде още по-лошо. Токенът носи само вашите собствени разрешения, така че доколко ще стигне атакуващият зависи от вашата роля. Изтекъл адрес за акаунт с права Guest е почти useless, докато такъв за Maintainer може да получи достъп до защитени клонове и CI/CD тайни.
Достигането до даден проект също изисква повече от просто адреса. GitLab определя целта въз основа на пътя на проекта и неговия цифров ID, така че атакуващ, който иска конкретен проект, се нуждае както от токена, така и от пътя и ID на този проект. Публичните проекти публикуват и двете. За частен проект е изтичане на информация, което го споменава, въпреки че идентификаторите на проекти в GitLab са лесни за отгатване.
Тъй като входящите имейли са освободени от IP ограничения, атаката може да произлезе извън разрешения списък с IP адреси (allowlist). Документацията на GitLab посочва, че входящите имейли не подлежат на IP ограничения.
Aikido ограничи частен проект до един IP адрес, който не беше техен собствен. GitLab блокира техния браузър и отказа git clone, но прие имейла със заявката за сливане и промяната бе качена в main.
Същият път заобикаля и двуфакторната автентификация. Документацията на GitLab отбелязва, че функциите за входящ имейл работят без 2FA, дори при инстанции, които я изискват задължително.
Всеки акаунт в GitLab.com разполага с един от тези токени, както и всяка самостоятелно управлявана (self-managed) инстанция на GitLab с включен входящ имейл, което е настройката по подразбиране в GitLab.com.
Изглежда, че GitLab Dedicated не е засегнат, тъй като GitLab ограничава функцията до self-managed и GitLab.com, но от Aikido заявиха, че не са успели да тестват Dedicated директно.
Какво да направите
Не можете да спрете останалите хора да използват функцията, но можете да прекратите валидността на изтекъл адрес.
- Нулирайте вашия токен за входящ имейл от страницата за лични токени за достъп (personal access tokens) във вашия профил. Нулирането заменя адресите на всички проекти наведнъж, така че адрес, който използвате активно, ще престане да работи, докато не предоставите новия.
- Прегледайте собствените си файлове README, ръководства за сътрудничество и страници за поддръжка за публикуван адрес. От Aikido заявиха, че са открили около дузина активни адреса по този начин, повечето от които публикувани нарочно като място за изпращане на доклади за грешки, а няколко в широко използвани проекти с отворен код.
- При самостоятелно управлявана инстанция администраторът може да изключи входящия имейл за цялата инстанция. Липсва настройка, която да позволява на отделен потребител да изключи създаването на задачи или заявки за сливане чрез имейл.
GitLab промени текста около токена след доклада на Aikido. Описанието вече гласи, че адресът може да създава задачи и заявки за сливане, докато преди изброяваше само работни елементи (work items), и GitLab премахна реда, гласящ, че токенът не може да се използва за достъп до други данни.
Поведението не се е променило. Токенът все още не изтича, GitLab все още не проверява кой е изпратил имейла и все още няма превключвател за отделен потребител да изключи функцията.
GitLab отвори задача за разглеждане на възможността за приемане на тези имейли само от адрес, потвърден в акаунта на собственика, но това е в процес на обсъждане, а не е внедрено.
От Aikido съобщиха, че първоначално са докладвали поведението чрез HackerOne през май 2026 г., където то е било затворено като очаквано поведение (intended behavior), а след това са подали поверителна задача в GitLab през юни. Позицията на GitLab, както я описват от Aikido, е че това е токен като всеки друг и че всеки изтекъл идентификационен данни води до лоши последици.
The Hacker News се свърза с GitLab и Aikido за коментар.