Критическая уязвимость GitLab: как проверить и обновить сервер

Критическая уязвимость GitLab · Critical GitLab vulnerability

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

21 октября GitLab выпустил внеплановые исправления безопасности для Community и Enterprise Edition. Главная уязвимость, CVE-2026-110264, получила наивысшую оценку CVSS 10.0: при определённых условиях пользователь без входа в систему может выполнить произвольный код на сервере GitLab. Причина — ошибка в обработке регулярных выражений. Подробности — в бюллетене GitLab.

Всего выпуск закрывает 12 уязвимостей. Кроме главной, ещё две высокой важности:

CVE-2026-15723 (CVSS 8.2) — пользователь GitLab может захватить чужую учётную запись LDAP, если одновременно включены вход через SAML и автоматическая привязка к LDAP.
CVE-2026-112212 (CVSS 7.5) — при определённых условиях посторонний может отравить общий кэш настроек OAuth и OIDC и перенаправить часть входов на внешний сервер.

О реальных атаках GitLab на момент публикации не сообщает. Но он уже выпустил правила, по которым можно искать следы попыток, — о них ниже.

Серверы ForestsNet Cloud неуправляемые: GitLab на своём VPS обновляете вы. Ниже — как проверить и обновить. Если что-то не получается, напишите в поддержку, подскажем.

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

Всех, у кого на сервере свой GitLab Community или Enterprise Edition — из пакета, в Docker или из исходников. Затронуты все версии начиная с 7.0, то есть любая установка без обновления от 21 октября. GitLab.com уже обновлён, его пользователей это не касается.

Как проверить версию

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION — версия GitLab, установленного из пакета.
sudo gitlab-rake gitlab:env:info — подробная сводка, версия — в блоке GitLab information.
docker ps --format '{{.Names}} {{.Image}}' — контейнеры: ищите образы gitlab/gitlab-ce и gitlab/gitlab-ee. Версию внутри покажет docker exec <имя> cat /opt/gitlab/embedded/service/gitlab-rails/VERSION.

Если версия ниже исправленной для вашей ветки (список — в конце новости), нужно обновиться.

Как обновить

Сначала резервная копия: sudo gitlab-backup create. Файлы /etc/gitlab/gitlab.rb и /etc/gitlab/gitlab-secrets.json в неё не входят — скопируйте их отдельно.

Быстрее и надёжнее всего обновиться до исправленной версии своей ветки: с 19.4 — на 19.4.3, с 19.3 — на 19.3.6 и так далее. В командах ниже для примера 19.4.3, подставьте свою.

Debian и Ubuntu: sudo apt update && sudo apt install gitlab-ce=19.4.3-ce.0. Для Enterprise Edition — gitlab-ee=19.4.3-ee.0.
AlmaLinux и Rocky Linux: sudo dnf install gitlab-ce-19.4.3-ce.0.el9, на 8-й версии системы окончание .el8. Для Enterprise Edition — gitlab-ee-19.4.3-ee.0.el9.
Docker: укажите в compose-файле точный тег, например gitlab/gitlab-ce:19.4.3-ce.0, и выполните docker compose pull && docker compose up -d. С тегом latest старая установка может перескочить обязательную промежуточную версию.
Установку из исходников обновляйте по инструкции GitLab.

В 19.4.3 и 19.3.6 есть миграции базы данных: если GitLab стоит на одном сервере, он будет недоступен, пока они идут. Если ваша ветка старше 18.11, исправления для неё нет: доберитесь до 18.11.13 или новее через обязательные промежуточные версии, маршрут подскажет руководство GitLab.

Как поискать следы атаки

GitLab опубликовал два правила для поиска попыток: Onigmo native worker crash и Org mode render error burst. На сервере с GitLab из пакета быстро проверить можно так:

sudo grep -A200 '\[BUG\]' /var/log/gitlab/puma/puma_stderr.log | grep -E 'org-ruby|onig' — аварийные падения рабочих процессов при обработке регулярных выражений. Если команда что-то вывела, это признак попыток.
sudo grep 'Timeout::Error' /var/log/gitlab/gitlab-rails/exceptions_json.log | grep -c '\.org"' — тайм-ауты при отображении файлов .org. Пять и больше таких ошибок от одного адреса за несколько минут — признак попыток.

В Docker логи лежат по тем же путям внутри контейнера, команды выполняются через docker exec <имя>. Следы в логах говорят о попытках, а их отсутствие не гарантирует, что атаки не было: удачная атака может пройти тихо. Если следы есть, после обновления смените токены доступа, токены раннеров и секреты в переменных CI/CD.

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

Временных мер для CVE-2026-110264 GitLab не предлагает: защищает только обновление. Если его приходится отложить, закройте веб-интерфейс GitLab от интернета — оставьте порты 80 и 443 открытыми только для своих адресов.

Исправленные версии

Исправления вошли в GitLab CE и EE 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13. В ветки 19.2, 19.1, 19.0 и 18.11 GitLab сверх обычного графика перенёс только исправление CVE-2026-110264. Остальные уязвимости выпуска закрыты начиная с 19.3.6, так что со старых веток стоит перейти на актуальную.