Функционалността на GitLab „Email work item to this project“ може да се превърне в механизъм за компрометиране на хранилища, когато нейният частен адрес бъде разкрит, според изследване, публикувано от изследователя Джо Лион от Aikido Security на 23 септември 2026 г.
Адресът съдържа дълготраен токен за входяща поща glimt-, за който GitLab заявява, че не изтича и трябва да остане тайна. Документацията на GitLab потвърждава, че всеки, който разполага с него, може да създава проблеми (issues) и заявки за сливане (merge requests) от името на собственика на токена.
Дефектът се простира далеч отвъд спама с проблеми. Въпреки че интерфейсът показва адрес, специфичен за конкретен проект, Aikido установи, че адресите, генерирани за различни проекти, съдържат един и същ токен на ниво акаунт.
Съобщава се, че атакуващ може да замени суфикса -issue с -merge-request, да прикачи Git корекция и да посочи изходен клон в темата на имейла. След това GitLab прилага корекцията към този клон или го създава, използвайки правата на жертвата.
Злонамерена корекция, модифицираща .gitlab-ci.yml, може впоследствие да задейства контролиран от атакуващия CI/CD код в проекта на жертвата. В зависимост от ролята на компрометирания потребител и конфигурацията на конвейера (pipeline), това би могло да разкрие изходен код, CI/CD променливи, токени за задачи или други тайни.
Изтекъл адрес на потребител с роля Maintainer може дори да позволи комитване в защитени клонове, включително main, докато действията изглеждат извършени от самоличността на жертвата. За разлика от това, токен на потребител с роля Guest остава ограничен от неговите права.
Според изследването на Aikido Security, маршрутът по имейл също така заобикаля предположенията за мрежови контроли. От Aikido съобщават, че техните изследователи са конфигурирали частен проект да приема само несвързан IP адрес; GitLab е блокирал достъпа през браузър и клонирането през Git, но е приел изпратената по имейл корекция, вкарвайки комит в main.
Сега GitLab изрично посочва в документацията си, че входящата поща не подлежи на IP ограничения, което означава, че списъците с разрешени адреси (allowlists) не са пълна граница за сигурност при тези работни процеси.
Експлоатацията изисква частния адрес плюс достатъчно информация за маршрутизиране, за да се идентифицира целевият проект, включително неговия път и ID на проекта. Публичните хранилища разкриват тези подробности, докато атаките срещу частни проекти обикновено изискват допълнително изтичане на информация.
Спуфингът на подателя не е необходим, тъй като понастоящем GitLab не изисква съобщенията да произхождат от имейл, потвърден в акаунта на собственика на токена. GitLab е отворил билет за проучване на подобна верификация.
GitLab третира съобщеното поведение като функция по дизайн, а не като конвенционална уязвимост, но въведе промени, изясняващи възможностите на токена.
Обновеният интерфейс и текстът в документацията вече споменават както проблеми, така и заявки за сливане, наблягат на конфиденциалността и процедурите за нулиране и обясняват изключението за IP ограниченията. Основният механизъм за имейл обаче остава достъпен.
Екипите по защита трябва незабавно да потърсят в хранилища, документация, тикети, логове и публични страници за glimt- адреси и по-стари или персонализирани формати на токени за входяща поща.
При съмнение за изтичане се изисква нулиране на токена за входящ имейл в настройките за лични токени за достъп, което анулира свързаните адреси на проекти.
Организациите трябва също така да прегледат разрешенията на засегнатите потребители, правилата за защитени клонове, конвейерите, променливите, комитите и събитията за одит, като същевременно третират всеки имейл адрес на проект като акаунт за достъп, а не като безобиден адрес за контакт.