GitLab: уязвимость 10 из 10, которая жила 12 лет. Как защитить свой сервер

Если у вас на сервере стоит свой GitLab, обновите его сегодня. 21 октября GitLab исправил уязвимость CVE-2026-110264 с максимальной оценкой опасности 10 из 10. Через неё можно запустить код на сервере без логина и пароля.

Ошибка есть во всех версиях начиная с 7.0. Это 12 лет выпусков. И даже если вы обновлялись в начале октября, этого недостаточно.

Обходного пути нет. Единственная защита это обновление. Ниже простая инструкция.

Что такое GitLab

GitLab это рабочее место для команды программистов. Там хранится код, задачи, обсуждения, автоматические сборки и выкладка сайта на сервер.

Представьте сейф, в котором лежат чертежи всего вашего бизнеса. Кто получил доступ к GitLab, тот видит весь код, пароли от серверов в настройках сборки и может подменить код сайта.

GitLab бывает двух видов:

• GitLab.com. Облачный сервис. Его GitLab уже обновил сам, делать ничего не нужно.
• Свой GitLab на сервере (self-managed). Его ставят на VPS или выделенный сервер, чтобы код хранился у себя. Обновлять его нужно вам.

Что случилось

Внутри GitLab есть механизм поиска по шаблону. Он нужен, например, чтобы красиво показывать файлы и проверять правила в настройках сборки.

Ошибка в этом механизме похожа на старый счётчик пробега в машине. Он показывает максимум 99 999 километров. Проезжаете ещё один, и счётчик снова показывает ноль. Машина прошла огромный путь, а прибор уверен, что она новая.

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

Самое неприятное: для атаки не нужен ни логин, ни пароль. Исследователи пишут, что атаку можно провести через специально подготовленный файл, который GitLab показывает в браузере.

Почему обновление 12 октября не спасает

В октябре GitLab выпустил два срочных обновления подряд:

Обе ошибки живут в одном и том же механизме поиска по шаблону. Но это разные дыры. Обновление от 12 октября закрыло первую, а вторая осталась.

Это как поменять замок на входной двери и не заметить, что окно рядом тоже открыто. Если вы обновили GitLab 12 октября и успокоились, ваш сервер всё ещё уязвим.

Всего обновление 21 октября закрывает 11 уязвимостей. Одна критическая, остальные высокого, среднего и низкого уровня.

Кого это касается

Обычно GitLab выпускает исправления только для трёх последних версий. В этот раз он сделал исключение и выпустил исправление ещё для четырёх старых. Это редкость и говорит о том, насколько серьёзна ошибка.

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

Узнайте версию

Через браузер. Войдите в GitLab и нажмите на значок «?» (Справка) в меню. Там указана версия. Или откройте адрес https://ваш-gitlab/help.

Через SSH:

sudo gitlab-rake gitlab:env:info | grep -A2 "GitLab information"

Или короче:

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

Если GitLab в Docker:

docker exec -it gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

Вместо gitlab укажите имя своего контейнера. Сравните версию с таблицей выше.

Сделайте резервную копию

В GitLab хранится код всей команды. Перед обновлением обязательно сохраните копию. Это как сфотографировать документы перед тем, как нести их на подпись. Если что-то потеряется, у вас останется оригинал.

sudo gitlab-backup create

Отдельно скопируйте два файла с настройками и ключами. Без них резервная копия не восстановится:

sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json ~/

Храните копии не на том же сервере. Например, скачайте их к себе или перенесите в другое хранилище.

Обновите GitLab

Самый безопасный путь: обновиться до исправленной версии своей же ветки. Например, с 19.4.1 на 19.4.3, а не сразу на 19.5.1. Это как заменить колесо той же модели, а не ставить незнакомую резину перед дальней дорогой.

Предупредите команду: во время обновления GitLab будет недоступен от нескольких минут до получаса.

В примерах ниже стоит версия 19.4.3. Подставьте свою из таблицы. Если у вас платная версия, замените ce на ee.

Ubuntu и Debian:

sudo apt update
sudo apt install gitlab-ce=19.4.3-ce.0

AlmaLinux и Rocky Linux:

sudo dnf install gitlab-ce-19.4.3

Docker. Поменяйте версию образа в docker-compose.yml:

image: gitlab/gitlab-ce:19.4.3-ce.0

И перезапустите контейнер:

docker compose pull
docker compose up -d

После обновления проверьте версию, как в шаге 1, и запустите самопроверку GitLab:

sudo gitlab-rake gitlab:check SANITIZE=true

Затем откройте GitLab в браузере и убедитесь, что проекты, задачи и сборки работают.

Если у вас очень старая версия

Для версий 18.10 и более ранних отдельного исправления нет. Нужно подняться хотя бы до 18.11.13.

Но прыгнуть сразу через несколько версий нельзя. GitLab обновляется по лестнице: у него есть обязательные «ступеньки», через которые нужно пройти по очереди. Это как подниматься на 10-й этаж без лифта. Перепрыгнуть с 3-го сразу на 10-й не получится.

Что делать:

1. Откройте официальный инструмент GitLab Upgrade Path (ссылка внизу статьи).
2. Укажите свою версию и целевую, например 18.11.13 или новее.
3. Инструмент покажет все обязательные ступеньки.
4. Пройдите их по очереди. Перед каждой ступенькой делайте резервную копию.

На очень старых версиях такое обновление может занять несколько часов. Лучше проверить его сначала на копии сервера.

Чек-лист

• Узнал версию GitLab
• Сравнил её с таблицей
• Сделал резервную копию командой gitlab-backup create
• Скопировал gitlab.rb и gitlab-secrets.json на другой сервер
• Предупредил команду о коротком простое
• Обновил GitLab до исправленной версии своей ветки
• Проверил версию и запустил gitlab:check
• Убедился, что проекты и сборки работают

Не хотите разбираться сами?

Обновление GitLab пугает многих не зря. Если что-то пойдёт не так, команда останется без кода и сборок. А на старых версиях нужно пройти несколько обязательных ступенек и ни одну не пропустить.

Для таких случаев у Zomro есть два варианта.

SOD: обновим GitLab за вас

Наш системный администратор:

• сделает резервную копию и сохранит её в безопасном месте;
• построит план обновления с нужными ступеньками;
• обновит GitLab в удобное для вас время, например ночью;
• проверит, что проекты, задачи и сборки работают.

Стоимость: €12.50 за каждые 15 минут работы.

Заказать обновление

Premium: быстрая помощь, когда она нужна

Если GitLab не поднялся после обновления, вся команда стоит. По обычному техническому запросу ответ может занять до 10 часов. С Premium мы отвечаем за время от 5 до 30 минут.

Новые уязвимости появляются каждую неделю. С Premium вам не придётся разбираться с ними в одиночку.

Подключить Premium