Оформите заявку на сайте, мы свяжемся с вами в ближайшее время и ответим на все интересующие вопросы.
За последний месяц в GitLab обнаружили три уязвимости с максимальной оценкой критичности — 10 из 10. Одну уже используют в реальных атаках, другая оставалась в коде с 2014 года.
Для российских компаний ситуация особенно неприятная. С 2022 года облачный GitLab и лицензии на него недоступны в России, поэтому большинство используемых у нас инсталляций работают на собственных серверах. Часть из них давно не обновлялась. Менять версию страшно, а напомнить об обновлении некому.Что произошло и какие уязвимости обнаружили в GitLab
Первая уязвимость — CVE-2026-85706 — позволяет читать произвольные файлы на сервере без авторизации. Достаточно отправить специально сформированный запрос к API GitLab.
Проблема находится в механизме, который возвращает историю изменений файлов. Если подменить путь в запросе и выйти за пределы разрешенного каталога, сервер может отдать любой файл, доступный процессу GitLab. В их числе настройки приложения, пароли от базы данных и ключи доступа.
Уязвимы обе редакции GitLab в версиях с 18.7 по 19.3.1. Исправления вышли в версиях 19.3.2, 19.2.6 и 19.1.8.
Главное здесь в том, что уязвимость уже эксплуатируют. Массовое сканирование серверов фиксировали с 11 сентября, а готовый пример атаки давно опубликован в открытом доступе.
Еще две уязвимости — CVE-2026-97229 и CVE-2026-110264 — связаны с механизмом регулярных выражений. Он нужен для поиска и сопоставления текста по заданным шаблонам. Этот механизм встроен в Ruby, язык программирования, на котором написан GitLab, поэтому проблема затрагивает сами установки GitLab, использующие соответствующие версии Ruby.
При определенных условиях ошибки позволяют выполнить произвольный код на сервере без авторизации. Особенно примечательна CVE-2026-110264. Она затрагивает версии начиная с 7.0, выпущенной в 2014 году. Получается, уязвимость оставалась в коде двенадцать лет.
Есть еще один важный момент, который легко пропустить. 12 октября выпустили исправление, закрывавшее только часть проблемы. Полноценное исправление появилось 21 октября сразу для семи веток GitLab — 19.5.1, 19.4.3, 19.3.6, 19.2.9, а также 19.1.9, 19.0.10 и 18.11.13.
Если вы обновились 12 октября и решили, что проблема устранена, это еще не означает, что сервер защищен.
Почему взлом GitLab может поставить под угрозу всю инфраструктуру разработки
GitLab — не просто хранилище исходного кода. В нем сосредоточена значительная часть инфраструктуры разработки и поставки программного обеспечения. В конфигурациях сборки могут храниться пароли от рабочих сред, служебные токены для развертывания приложений и ключи доступа к серверам.
Поэтому взлом GitLab — это не только риск утечки исходников. Злоумышленник может получить доступ к секретам, необходимым для сборки, публикации и развертывания программного обеспечения. В зависимости от настроек и выданных прав это открывает путь к дальнейшему продвижению внутри инфраструктуры компании.
Особенно уязвимы установки, которые развернули несколько лет назад, обновляли время от времени, а потом перестали трогать из опасения что-нибудь сломать. Именно на таких серверах особенно опасны уязвимости, существующие годами.
Какие следы эксплуатации искать в журналах GitLab
Подозрительные запросы к API
Проверьте POST-запросы к адресам вида /api/v4/projects/…/repository/commits/, содержащие параметр file.path.
Если перед GitLab установлен nginx, начните с его журнала доступа. Если сервер доступен напрямую, проверьте production_json.log.
Для первичного поиска можно использовать команду
grep «repository/commits/« access.log | grep «file.path»
Даже один такой запрос — повод разобраться, кто его отправил и что происходило на сервере в это время.
Ошибки внутренних процессов и сбои при обработке шаблонов
Проверьте журналы на предмет падений внутренних процессов, ошибок при обработке регулярных выражений и необычных всплесков ошибок при открытии страниц.
Разработчики опубликовали готовые правила обнаружения в формате Sigma.
Это открытый формат правил, который поддерживают многие системы анализа журналов и мониторинга безопасности.
Необычные изменения конфигурации и учетных записей
Проверьте, не появились ли новые служебные токены и ключи для развертывания, неизвестные исполнители сборки, изменения в .gitlab-ci.yml и новые учетные записи с правами администратора.
Особое внимание стоит уделить изменениям, которые никто из ответственных сотрудников не может объяснить.
Необычная исходящая активность сервера
Изучите сетевые журналы и проверьте, куда обращался сервер. В обычной конфигурации GitLab не должен бесконтрольно устанавливать соединения с внешними ресурсами. Необычная исходящая активность может указывать на попытку связи с управляющим сервером злоумышленника или на другие действия после компрометации.
При этом отсутствие подозрительных событий в журналах еще не доказывает, что атаки не было. Сканирование серверов началось в сентябре, а одна из уязвимостей существовала с 2014 года.
Как защитить GitLab и проверить, не произошла ли компрометация
Первым делом определите установленную версию GitLab и проверьте, доступен ли сервер из интернета. Если он опубликован во внешнюю сеть, риск существенно выше, чем у установки, доступной только из внутренней инфраструктуры.
Затем обновитесь до исправленной версии. В качестве целевых версий указаны 19.5.1, 19.4.3, 19.3.6 и 19.2.9. Для более старых веток — 19.1.9, 19.0.10 или 18.11.13.
Перед обновлением проверьте официальные инструкции для вашей версии. В некоторых случаях обновление затрагивает базу данных и требует дополнительного времени. Если GitLab работает на одном сервере, возможен простой, поэтому заранее запланируйте окно обслуживания.
Если немедленное обновление невозможно, временно закройте доступ к GitLab из интернета и оставьте его доступным только из доверенной внутренней сети. Это не устраняет уязвимость, но уменьшает поверхность атаки.
Если есть признаки компрометации, одного обновления недостаточно. Смените все секреты, к которым мог получить доступ злоумышленник, включая пароли баз данных, служебные токены, ключи доступа и секреты в настройках сборки.
Также проверьте изменения в репозиториях, конфигурациях CI/CD, учётных записях и правах доступа. При необходимости изучите связанные серверы и системы, до которых можно было добраться через GitLab.
Почему старые установки GitLab остаются удобной мишенью
Уязвимость, которая оставалась незамеченной двенадцать лет, обнаружилась не случайно. Исследователь последовательно изучал один и тот же механизм, возвращаясь к нему несколько раз за осень. Это хороший повод пересмотреть отношение к давно установленному программному обеспечению. Возраст системы не делает ее безопасной, а привычность не снижает риск.
Даже если исправления установлены, версия актуальна и мониторинг не показывает тревожных событий, этого недостаточно, чтобы считать инцидент исключенным. После обновления нужно проверить журналы и оценить, не успели ли воспользоваться уязвимостями раньше.
Вопрос не только в том, закрыли ли вы уязвимость. Важно понять, не успел ли кто-то воспользоваться ею до того, как вы закрыли доступ.
Наши соцсети: ВК | МАХ | ТГ