← Заметки

Реагирование на GitLab2Shell: версии CVE-2026-110264 и пути обновления

На этой странице

Устранение GitLab2Shell означает обновление GitLab CE/EE до выпуска с исправлением CVE-2026-110264 и проверку его использования в развёртывании. Уведомление GitLab от 21 октября описывает удалённое выполнение кода без аутентификации при определённых условиях через целочисленное переполнение при компиляции регулярных выражений. Обновление только GitLab Shell или Runner не завершает устранение проблемы сервера CE/EE.

Сначала сопоставьте CVE с версией продукта

Эта статья касается CVE-2026-110264 из официального уведомления GitLab с оценкой 10.0 по CVSS v3.1. Отличайте её от других CVE GitLab, опубликованных примерно в то же время, и компонентов Shell с похожими названиями. Запись CVE, подготовленная GitLab, содержит те же затронутые диапазоны и пороги исправления.

Ветка GitLab CE/EE Первый выпуск с исправлением этой CVE
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

Уведомление считает затронутыми версии от 7.0 до 18.11.13, не включая последнюю, и каждую указанную ветку до её первого исправленного выпуска. Эта таблица, проверенная 30 октября 2026 года, даёт пороги первого исправления, а не зафиксированный список последних версий для установки. Для GitLab.com и GitLab Dedicated в уведомлении приведены отдельные сведения о внедрении; не применяйте инструкции обновления Self-Managed к этим сервисам без разбора.

Автономное сравнение заявленной строки версии

Разбор стабильной версии выпуска и числовое сравнение с порогом ветки без проверки развёртывания

Схема соответствует коду сравнения ниже. Он проверяет ввод перед сравнением зарегистрированных веток. Старые затронутые ветки требуют пути обновления; ветки вне таблицы остаются неизвестными. Ни один результат не удостоверяет состояние сервера или происхождение исправления.

При использовании Python 3.11 или новее сохраните этот файл в новом каталоге. Он помогает численно сравнивать версии официальных выпусков upstream CE/EE без сетевых запросов, поиска сервисов или эксплуатации. Принимаются формы вроде 19.5.1, 19.5.1-ee и 19.5.1-ee.0; форматы предварительных, ночных или изменённых поставщиком версий не угадываются.

release-threshold.py

import re
import sys

FIRST_FIX = {
    (18, 11): 13,
    (19, 0): 10,
    (19, 1): 9,
    (19, 2): 9,
    (19, 3): 6,
    (19, 4): 3,
    (19, 5): 1,
}
NUMBER = r"(0|[1-9][0-9]{0,2})"
VERSION = rf"{NUMBER}\.{NUMBER}\.{NUMBER}(?:-(?:ce|ee)(?:\.[0-9]{{1,3}})?)?"


def main(argv):
    match = re.fullmatch(VERSION, argv[1]) if len(argv) == 2 else None
    if match is None:
        print("usage: release-threshold.py VERSION (stable CE/EE release format)", file=sys.stderr)
        return 2
    major, minor, patch = map(int, match.groups())
    branch = (major, minor)
    if branch in FIRST_FIX:
        baseline = f"{major}.{minor}.{FIRST_FIX[branch]}"
        state = "met" if patch >= FIRST_FIX[branch] else "below"
        status = 0 if state == "met" else 1
    elif (7, 0) <= branch < (18, 11):
        baseline, state, status = "upgrade-path-required", "below", 1
    else:
        baseline, state, status = "not-covered", "outside-table", 2
    print(f"release-threshold={state}")
    print(f"baseline={baseline}")
    print("deployment-and-release-provenance=not-verified")
    return status


if __name__ == "__main__":
    raise SystemExit(main(sys.argv))
python3 release-threshold.py 19.5.1-ee.0

Локальный запуск вернул следующий вывод и код завершения 0.

release-threshold=met
baseline=19.5.1
deployment-and-release-provenance=not-verified

Статус 0 означает лишь, что переданные числа достигают опубликованного порога исправления этой CVE. Статус 1 означает значение ниже опубликованного порога; статус 2 — неподдерживаемый формат или ветку вне таблицы. Он не проверяет существование выпуска, официальность пакета или его работу на каком-либо узле. Обратные переносы и собственные сборки требуют отдельных свидетельств исправления от поставщика.

Свяжите сведения об установке с работающим развёртыванием

Официальная документация по обслуживанию описывает сбор сведений о GitLab, Ruby и компонентах командой sudo gitlab-rake gitlab:env:info для Linux-пакетов или bundle exec rake gitlab:env:info RAILS_ENV=production для установки из исходного кода. В многоузловых развёртываниях запускайте её на узлах, где работает Rails. Вывод может содержать внутренние пути и адреса, поэтому храните его в эксплуатационных записях с ограниченным доступом.

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

Выберите актуальное исправление и завершите миграции

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

Отличайте первые исправления от актуальных патчей. Уведомление об исправлениях от 29 октября перечисляет более поздние выпуски, включая 19.5.3 и 19.4.5, а также некоторые миграции базы данных, и прямо указывает, что 19.5.2 и 19.4.4 были пропущены. Скрипт не запрашивает каталог выпусков, поэтому выполняет числовое сравнение даже для этих строк. Всегда выбирайте фактическую версию для установки из официальных сведений о распространении.

После обновления отдельно проверьте работающие версии, завершение миграций, обычный вход, доступ к репозиториям и обработку заданий. Указанные в уведомлении обнаружения сбоев воркера Onigmo и всплесков ошибок рендеринга Org-mode — отправные точки расследования; ни одно из них само по себе не доказывает и не исключает компрометацию. Сохраните журналы и сведения о процессах и развёртывании; при подозрении на компрометацию проведите отдельное расследование.

Устранение проблемы сертификатов Java того же периода — отдельная задача. Для сервисов сборки и интеграции, использующих JDK, также прочитайте проверку eMudhra и хранилища доверия JVM.

Обсуждение

Посмотреть на GitHub ↗