КИБЕРБЕЗОПАСНОСТЬ

depthfirst опубликовала PoC для RCE-цепочки в GitLab

Опубликован код уязвимости RCE в GitLab, позволяющий автозаконнченным пользователям выполнять команды.

✍️ Редакция iTech News | 02.10.2025 | ⏱ 3 мин | Источник: The Hacker News
Уязвимость RCE в GitLab угрожает безопасности

Исследователи depthfirst опубликовали рабочий PoC для цепочки RCE в локально развернутом GitLab. Атака позволяет аутентифицированному пользователю выполнить команды от имени пользователя git, если сервер не обновили до патчей от 10 июня 2026 года.

Для администраторов это не академическая история: под ударом могут оказаться исходный код, секреты CI/CD и доступы к внутренним сервисам. И да, PoC уже публичный, так что откладывать обновление до «первого спокойного окна» теперь особенно рискованно.

Какие версии затронуты

Проблема касается GitLab CE/EE версий 15.2.0–18.10.7, 18.11.0–18.11.4 и 19.0.0–19.0.1. Исправления вошли в релизы 18.10.8, 18.11.5 и 19.0.2. GitLab.com уже работает на исправленной версии, а клиентам с собственными инсталляциями нужно проверить именно версию самого GitLab, а не только Helm chart или Operator.

Отдельного CVE для этой цепочки на момент публикации нет. Это неприятная деталь: июньский патч GitLab вышел вовремя, но полноценное исследование с разбором эксплуатации и публичным PoC появилось только в конце июля.

Как устроена цепочка эксплуатации

Атака завязана на отображении diff для Jupyter Notebook. Пользователю с правом отправки изменений достаточно закоммитить два специально подготовленных файла .ipynb и открыть diff коммита. После этого встроенный пакет ipynbdiff передает содержимое файлов в JSON-парсер Oj, написанный на C, и уже там срабатывают две ошибки безопасности памяти.

По данным depthfirst, одна уязвимость дает запись за пределы буфера, вторая раскрывает указатель из кучи. Вместе они позволяют обойти ASLR и перехватить выполнение кода в процессе Puma. Команды выполняются от имени пользователя git без прав администратора, без доступа к средствам CI/CD и без участия другой жертвы.

Почему это важно для компаний

Для рынка России и СНГ это история прежде всего про локально развернутые DevOps-платформы. Во многих компаниях GitLab стоит внутри периметра, хранит не только репозитории, но и переменные CI/CD, токены развертывания и служебные ключи. Если такой сервер доступен разработчикам, подрядчикам или внешним командам и давно не обновлялся, публичный PoC резко повышает практический риск.

Есть и второй вывод: проблема сидит не в редком модуле, а в функции просмотра diff для notebook-файлов. Если Jupyter Notebook в компании не используют, временное отключение notebook diff может снизить риск. Но полноценное решение все равно одно: обновление до поддерживаемой версии и проверка журналов на подозрительную обработку .ipynb.

Что делать администраторам

Базовый список действий короткий: обновиться до 18.10.8, 18.11.5 или 19.0.2; закрыть свободную регистрацию пользователей; пересмотреть права на отправку изменений и просмотр diff; проверить журналы на необычные запросы, связанные с notebook-файлами. Для старых веток 15.2–18.9 бэкпортов уже не будет, так что без перехода на поддерживаемый релиз не обойтись.

Источники: исследование depthfirst, GitLab Patch Release от 10 июня 2026 года и независимое уведомление Tencent Cloud.

Оригинал исследования depthfirst
Патч-релиз GitLab 19.0.2 / 18.11.5 / 18.10.8

Дальше рынку остается ждать двух вещей: появится ли у этой цепочки отдельный CVE и подтвердится ли ее использование в реальных атаках.

Поделиться: Telegram X LinkedIn