В GitLab закрыли CVE-2026-110264: критическую уязвимость с оценкой CVSS 10.0, которая при определённых условиях позволяет выполнить код на сервере без авторизации. Исправление вышло 21 октября 2026 года. Если у вас собственный GitLab, проверьте полный номер версии: обновление от 12 октября эту проблему не закрывает.
Разбираем, что известно о механизме атаки, какую версию устанавливать и как провести обновление без потери репозиториев и секретов. Ниже есть отдельные инструкции для Linux-пакетов, Docker и Kubernetes, а также порядок проверки логов и действий при подозрении на взлом.
Какие версии GitLab нужно обновить
Проблема затрагивает Community Edition и Enterprise Edition начиная с GitLab 7.0. Минимальные исправленные выпуски по веткам:
| Установленная ветка | Исправленный выпуск |
|---|---|
| 18.11 | 18.11.13 |
| 19.0 | 19.0.10 |
| 19.1 | 19.1.9 |
| 19.2 | 19.2.9 |
| 19.3 | 19.3.6 |
| 19.4 | 19.4.3 |
| 19.5 | 19.5.1 |
На GitLab.com исправление уже установлено. Для GitLab Dedicated поставщик указывает исправленные внутренние сборки в бюллетене. Самостоятельно управляемые установки требуют действий администратора. Официальный релиз GitLab.
Если ваша версия старше перечисленных веток, нельзя просто выбрать последнюю строку таблицы и перепрыгнуть через годы обновлений. Сначала ограничьте доступ к уязвимому сервису и составьте маршрут миграции. Он разобран ниже.
В чём ошибка Onigmo и почему это опаснее обычного сбоя
Onigmo является движком регулярных выражений в используемом GitLab Ruby-стеке. Регулярное выражение описывает шаблон поиска в тексте. В безопасном сценарии приложение получает текст, обрабатывает его и возвращает результат. Ошибка низкоуровневого движка способна нарушить работу с памятью самого процесса.
Бюллетень описывает переполнение целого числа при обработке специально сформированного выражения. В опубликованных материалах команды безопасности дополнительно описан путь через рендеринг Org-mode документов с расширением .org. Это серверная обработка содержимого, а не исполнение JavaScript в браузере пользователя.
Материалы GitLab по обнаружению связывают этот путь с org-ruby и Onigmo и указывают на возможность выполнения кода от пользователя git. Это даёт основания проверять не только доступность сервиса, но и сохранность исходного кода и служебных доступов. Техническое описание в официальном репозитории GitLab Security.
Права git не равны root. Однако этот пользователь обслуживает чувствительные данные GitLab. Компрометация сервера разработки может затронуть репозитории, CI/CD и дальнейшие развёртывания. При расследовании нужно устанавливать реальный объём доступа, а не останавливаться на вопросе «получили ли root».
Что означает оценка CVSS 10.0
CVSS характеризует техническую тяжесть уязвимости, а не вероятность того, что конкретный сервер уже взломан. В опубликованном векторе указаны сетевой доступ, отсутствие необходимых привилегий и взаимодействия пользователя, а также серьёзное воздействие на конфиденциальность, целостность и доступность.
Практический вывод для администратора: переносить обновление на обычное плановое обслуживание рискованно. Приоритет зависит и от экспозиции. Доступный из интернета сервер нужно исправлять раньше, чем изолированный стенд, но изоляцию следует подтвердить, а не предположить по названию «внутренний GitLab».
Почему обновления от 12 октября недостаточно
12 октября GitLab исправлял другую уязвимость, CVE-2026-97229, связанную с регулярными выражениями в CI/CD. Тогда исправления получили номера 19.2.8, 19.3.5 и 19.4.2. У CVE-2026-110264 другой охват версий и новый исправленный набор. Поэтому сервер с 19.4.2 всё ещё требует обновления до 19.4.3 или более нового подходящего выпуска. Бюллетень от 12 октября.
Проверять нужно установленный номер, а не дату последнего обслуживания. Запись «GitLab обновлён на прошлой неделе» не заменяет сравнение с исправленной версией.
Как узнать версию и способ установки
В веб-интерфейсе после входа откройте Help → Help. Версия отображается сверху страницы. Это штатный способ из документации GitLab.
Для Linux-пакета полезно собрать следующие сведения:
sudo gitlab-rake gitlab:env:info
sudo gitlab-ctl status
dpkg-query -W gitlab-ce gitlab-eeПоследняя команда относится к Debian/Ubuntu. Если одна редакция не установлена, сообщение об отсутствии её пакета ожидаемо. На RPM-системах используйте:
rpm -q gitlab-ce gitlab-eeДля Compose проверьте сервис и фактический образ:
docker compose ps
docker compose images
docker compose exec gitlab gitlab-rake gitlab:env:infogitlab здесь является примером имени сервиса. Замените его своим. Не публикуйте вывод диагностики целиком: в нём могут быть внутренние адреса и другие сведения об инфраструктуре.
Составьте список всех инстансов: основной, резервный, тестовый, старый сервер после миграции, узлы за балансировщиком. Для каждого зафиксируйте версию, редакцию, метод установки, ответственного и доступность извне. Один забытый публичный стенд способен сохранить риск после обновления основного сервера.
Что сохранить перед обновлением
Для типовой пакетной установки резервная копия создаётся так:
sudo gitlab-backup createОтдельно сохраните конфигурацию /etc/gitlab, включая gitlab.rb и gitlab-secrets.json, нужные сертификаты и ключи. Для внешнего object storage предусмотрите собственную копию: стандартный backup не забирает все такие хранилища автоматически. Проверьте свободное место и возможность восстановления. Что входит и не входит в GitLab backup.
Храните резервную копию в защищённом месте вне обновляемого узла. Секреты из неё не должны попадать в тикет поддержки, общий чат или публичный репозиторий. Для крупной распределённой установки нужен согласованный план резервирования базы, репозиториев и хранилищ; одиночная команда на случайном узле его не заменяет.
Если GitLab давно не обновлялся
GitLab требует промежуточных остановок на определённых версиях и завершения фоновых миграций между ними. Для старого инстанса используйте официальный upgrade path и калькулятор маршрута обновления.
- Введите текущую и целевую версии и изучите примечания к каждому переходу.
- На каждой обязательной остановке выбирайте подходящий последний patch-release.
- Дождитесь завершения требуемых фоновых миграций перед следующим шагом.
- Заранее проверьте совместимость ОС, PostgreSQL, расширений и интеграций.
Не пытайтесь ускорить путь пропуском миграций. Если обновление займёт долго, временно закройте внешний доступ к приложению, сохранив отдельный административный канал. Быстрый переход на неподдерживаемую комбинацию компонентов создаст уже другую аварию.
Обновление GitLab через пакеты Linux
Следующий пример предназначен для одиночного CE-инстанса, уже работающего на ветке 19.4, с официальным APT-репозиторием. Он не является инструкцией для прямого перехода с GitLab 16 или 17.
sudo apt update
apt-cache policy gitlab-ce
apt-cache madison gitlab-ce
sudo apt-get -s install gitlab-ce=19.4.3-ce.0Сверьте версию с доступными пакетами и просмотрите симуляцию. После резервного копирования и подготовки окна обслуживания:
sudo apt-get install gitlab-ce=19.4.3-ce.0Для EE используйте gitlab-ee=19.4.3-ee.0. Не меняйте редакцию случайной заменой имени пакета. На AlmaLinux/RHEL команда зависит также от версии ОС; пример для EE на EL9:
sudo dnf install gitlab-ee-19.4.3-ee.0.el9Это примеры установки конкретного patch-release. Другую ветку обновляйте на соответствующий исправленный выпуск. Порядок выполнения и многосерверные сценарии описаны в инструкции по Linux-пакетам.
Перед работой согласуйте паузу для CI/CD-заданий и пользовательских изменений. Подготовьте консоль провайдера на случай потери веб-доступа. Успешное завершение пакетного менеджера ещё нужно подтвердить проверкой работающего приложения и миграций.
Обновление GitLab в Docker
Сохраните данные, конфигурацию и секреты. В существующем Compose-файле измените тег образа на исправленный выпуск той же редакции. Для инстанса EE на 19.4 это может быть:
image: gitlab/gitlab-ee:19.4.3-ee.0Затем выполните из каталога проекта:
docker compose pull gitlab
docker compose up -d --no-deps gitlab
docker compose logs --tail=100 gitlabКоманды предполагают, что сервис называется gitlab, а остальные параметры и постоянные тома уже настроены. Вновь созданный контейнер выполняет предусмотренное обновление. Официальная инструкция для Docker.
Простой docker restart продолжит запускать старый образ. Обновление Ruby на хосте также не исправляет библиотеку внутри контейнера. Не используйте docker compose down -v: удаление томов не требуется для патча и может уничтожить данные. Если образ закреплён по digest, замените и его на проверенный исправленный digest.
Kubernetes, Helm, Geo и несколько серверов
У Helm chart и приложения GitLab разные номера версий. Выбирайте chart, который соответствует исправленной версии приложения, сохраняйте собственные values и Kubernetes Secrets и проверяйте миграционные jobs. Замена одного контейнера webservice вручную не гарантирует согласованного обновления всей установки. Порядок обновления Helm chart.
Для Geo и распределённых установок необходим план по ролям узлов и базам данных. Не переносите на них инструкцию для одиночного сервера. GitLab отдельно требует учитывать Geo, совместимость компонентов, маршрут обновления и план отката. Подготовка обновления сложной установки.
Что делать, если установить патч прямо сейчас невозможно
До обновления ограничьте сетевую доступность: VPN, allowlist на прокси или firewall, временная остановка внешнего веб-доступа. Проверьте, что нет второго домена, IPv6-адреса или прямого origin, который обходит ограничение. Изменения должны сохранять аварийный административный канал.
Это уменьшает доступную атакующему поверхность, но не исправляет Onigmo. Не объявляйте отключение регистрации, 2FA или закрытие одного URL полноценной защитой от уязвимости без авторизации. Не заменяйте встроенную библиотеку вручную в пакетной установке без согласованного патча поставщика: такая правка может рассогласовать сборку.
Для managed-сервиса запросите у оператора полный номер исправленной сборки и подтверждение её развёртывания на всех узлах. Ответ «обновляемся регулярно» недостаточен.
Какие логи проверить на попытки эксплуатации
GitLab выпустил официальные правила для двух групп сигналов. Первое ищет нативный сбой Ruby с маркером [BUG] и кадрами org-ruby или Onigmo. Для Linux-пакета основной файл: /var/log/gitlab/puma/puma_stderr.log. Одного общего сообщения о перезапуске worker недостаточно. Правило Onigmo native worker crash.
Второе анализирует серии Timeout::Error при рендеринге .org через OtherMarkup в exceptions_json.log. Базовый порог опубликованного правила: пять событий от одного клиента за 30 минут. Для Omnibus файл находится в /var/log/gitlab/gitlab-rails/exceptions_json.log. Правило Org mode render error burst.
Проверьте сбор этих журналов, ротацию и сохранение времени событий. Сопоставляйте их с запросами, 502-ответами Workhorse, действиями пользователей и изменениями проектов. Правила являются сигналами для расследования, а не автоматическим заключением о взломе. Отсутствие crash-событий не доказывает отсутствие успешной эксплуатации.
Если появились признаки взлома
- Ограничьте доступ к инстансу и остановите подозрительную активность, не уничтожая журналы.
- Зафиксируйте время событий, сохраните snapshot и логи для расследования.
- Проверьте изменения репозиториев, CI-конфигураций, учётных записей, токенов и исходящих соединений.
- Установите патч в доверенной среде. При подтверждённой компрометации восстанавливайте сервис из проверенных компонентов и данных.
- С чистого устройства отзовите затронутые токены и ключи. Оцените секреты CI/CD, runner-токены, deploy keys и доступы к облакам и реестрам.
- Проверьте сборки и релизы, выполненные после предполагаемого начала атаки: целевой системой мог стать не только GitLab, но и его pipeline.
Замена gitlab-secrets.json на случайный новый файл не является универсальным способом ротации: это может нарушить доступ к зашифрованным данным. Ротацию внутренних секретов проводите по процедурам GitLab, с резервной копией и пониманием последствий. Обновление закрывает уязвимость, но не отзывает уже украденный внешний API-ключ.
Как проверить результат обновления
Для типовой пакетной установки:
sudo gitlab-ctl status
sudo gitlab-rake gitlab:env:info
sudo gitlab-rake gitlab:check SANITIZE=trueПроверьте номер версии в интерфейсе и на каждом узле. Выполните тестовое чтение репозитория, безопасный push в тестовый проект, открытие merge request и небольшой pipeline без production-секретов. Убедитесь, что миграции завершились, а ошибки и очередь задач не растут.
Не проверяйте рабочий сервер публичным эксплойтом. Для подтверждения патча достаточно версии, происхождения пакета или образа, завершённого обновления и исправно работающих компонентов. Проверку подозрительной активности проводите отдельно от проверки доступности.
Частые вопросы
Нужно ли обновлять GitLab.com самостоятельно?
Нет. Пользователь GitLab.com не устанавливает серверные патчи. Самостоятельно управляемые инстансы обновляет их администратор.
Достаточно ли обновить GitLab Runner?
Нет. Runner и сервер GitLab являются разными компонентами. Исправление серверной уязвимости нужно установить в сервер. Совместимость и обновление Runner планируют вместе с обслуживанием.
Нужно ли обновлять PHP, как в истории с PHP2Shell?
Нет, это другой компонент и другая уязвимость. Обновление PHP не устанавливает исправление GitLab. Разбор PHP2Shell и способов защиты сайта.
Сервер доступен только сотрудникам. Можно подождать?
Сначала подтвердите сетевые ограничения и исправность всех маршрутов доступа. Внутренняя сеть снижает экспозицию, но не отменяет обновление и риск от скомпрометированного устройства сотрудника.
Что зафиксировать в отчёте администратора?
Прежнюю и новую версии, пакет или digest образа, время обновления, состояние миграций, результат функциональных проверок и проверенный период журналов. Такая запись полезнее формулировки «обновления установлены».
