Повторное освобождение памяти и целочисленное переполнение в GitLab позволяют удалённо выполнить произвольный код

Платформа для совместной работы над кодом GitLab содержит две уязвимости, каждая из которых позволяет удалённому нарушителю выполнить произвольный код на сервере. Сведения о них есть в Банке данных угроз безопасности информации (BDU): идентификаторам BDU:2026-15214 и BDU:2026-15215 соответствуют номера CVE-2026-89078 и CVE-2026-93577. Уязвимости затрагивают сборки с 19.2.0 по 19.2.7, с 19.3.0 по 19.3.3 и с 19.4.0 по 19.4.1. Производитель подтвердил обе, и для каждой уже существует эксплойт. В карточках указан критический уровень опасности, поэтому владельцам собственных установок обновление стоит поставить вне очереди.

Детали уязвимостей

Первая уязвимость относится к классу повторного освобождения памяти. Программа отдаёт участок памяти, а затем снова к нему обращается, хотя содержимое уже могло измениться. В результате нарушитель получает возможность подменить данные и повлиять на ход вычислений. Вторая связана с целочисленным переполнением. Значение выходит за отведённые под него границы, и расчёты дают непредсказуемый результат. Как правило, это приводит к выделению меньшего объёма памяти, чем требуется. Так открывается путь к изменению соседних структур данных. Оба случая описаны как ошибки кода, а способ эксплуатации один и тот же - манипулирование структурами данных.

Эксплуатация возможна удалённо, но требует учётной записи в системе. При этом привилегии нужны низкие: достаточно рядового пользователя с доступом к проектам. Это меняет расчёт риска для крупных организаций, где в GitLab заведены сотни сотрудников и подрядчиков. Кроме того, последствия не ограничиваются одним компонентом платформы. Нарушитель может добраться до исходного кода, сборочных переменных, ключей доступа и конвейеров непрерывной интеграции и доставки. Подмена кода на этом уровне способна затронуть продукты, которые компания уже выпускает.

Выполнение произвольного кода означает, что нарушитель действует с правами сервиса. Отсюда следует доступ к файлам, к базе данных и к сетевым ресурсам, которые видит платформа. Заметить такое присутствие непросто, потому что команды выполняют штатные процессы. Для закрепления в системе достаточно добавить свой ключ доступа или поправить настройки интеграций.

GitLab хранит не только репозитории. Через него проходят сборочные конвейеры, хранилища артефактов, средства планирования задач и секреты для подключения к внешним сервисам. Поэтому компрометация такого сервера часто становится первым шагом к более крупному нападению. Репозиторий описывает, как устроен продукт: какие библиотеки используются, где лежат ключи, как организована сборка. Для злоумышленника это готовая карта инфраструктуры. Между тем в обеих уязвимостях ему не нужен физический доступ и не требуется участие пользователя. Достаточно отправить специально подготовленные запросы.

Затронуты не только крупные компании. Небольшие команды часто разворачивают GitLab на одном сервере вместе со службой сборки, и там права обычного пользователя открывают почти всё. Для госструктур и подрядчиков добавляется требование согласовать обновление, а это время. Чем дольше сервер остаётся без исправления, тем выше вероятность, что им воспользуются.

Оба отчёта поступили через программу вознаграждения за найденные уязвимости HackerOne. Значит, часть деталей уже раскрыта, и стороннему исследователю не составит труда восстановить картину. Исправления вошли в очередной выпуск обновлений GitLab, анонс которого опубликован на сайте проекта. Владельцам собственных установок нужно обновиться самостоятельно. Пользователи облачной версии получают исправление от поставщика. Так как перезапуск сервиса прерывает работу конвейеров, обновление требует планирования. Однако откладывать его рискованно: эксплойт доступен.

Отдельный риск создают экземпляры, открытые в интернет. Их немало, ведь платформа удобна для внешних подрядчиков и распределённых команд. Если такой сервер не закрыт фильтрами и не ограничен по числу учётных записей, точек входа становится заметно больше. Поэтому проверка периметра здесь важна не меньше, чем установка исправления. Пока обновление не установлено, имеет смысл ограничить доступ к платформе. Проверьте, у кого есть учётные записи, и отзовите лишние. Включите двухфакторную аутентификацию для всех, кто работает с репозиториями. Просмотрите журналы на предмет обращений к необычным проектам и запросов, вызывающих сбои сервиса. Сборочные переменные требуют отдельной проверки, потому что в них часто лежат постоянные ключи к внешним системам. Если такие ключи хранились в открытом виде, их лучше сменить.

Ошибки работы с памятью плохо выявляются автоматическими анализаторами, поэтому подолгу остаются незамеченными. Для платформ, которые собирают и хранят код, цена такой уязвимости выше, чем для обычного веб-приложения. Репозиторий с правами на сборку почти равнозначен доступу к производственной среде. Обновление до исправленной сборки закрывает эту возможность, а ограничение числа учётных записей снижает шансы, что кто-то успеет этим воспользоваться до установки исправления.

Детали уязвимостей

Ссылки