GitLab выпустил внеплановый критический патч, закрывающий уязвимость CVE-2026-19478 в Community Edition (CE) и Enterprise Edition (EE). При определённых условиях она позволяет неаутентифицированному атакующему удалённо изменять или удалять публичные проекты и пользовательские данные через директиву GraphQL. Проблеме присвоен максимальный уровень Critical и оценка CVSS 9.4.
Обновления вышли 17 августа 2026 года — на пять дней раньше обычного графика релизов, которые GitLab публикует дважды в месяц, во вторую и четвёртую среду. Предыдущий плановый патч, выпущенный за пять дней до этого, не содержал критических исправлений.
Какие версии уязвимы и что делать
Действия требуются только владельцам self-managed инсталляций. Исправления доступны в версиях GitLab 19.2.4, 19.1.6, 19.0.8 и 18.11.11. Облачные сервисы GitLab.com и GitLab Dedicated уже работают на пропатченных версиях, их клиентам ничего делать не нужно.
В зоне поражения находятся все версии, выпущенные после 18.2:
- все версии от 18.2 до 18.11.11;
- 19.0 до 19.0.8;
- 19.1 до 19.1.6;
- 19.2 до 19.2.4.
Ветки 18.2–18.10, которые входят в уязвимый диапазон, исправлений не получили — обновляться нужно до одной из перечисленных выше версий.
Что известно об уязвимости
GitLab подтвердил, что проблема позволяет неаутентифицированному пользователю удалённо изменять или удалять публичные проекты и пользовательские данные через директиву GraphQL. Вектор CVSS указывает, что атака возможна по сети, без учётных данных и без какого-либо действия со стороны жертвы.
Компания не раскрыла, какая именно директива GraphQL затронута и каковы условия эксплуатации. На момент публикации уведомления — 18 августа 2026 года — признаков эксплуатации уязвимости не обнаружено, публичного эксплойта на GitHub также нет.
Вторая уязвимость: CSRF в GraphQL multiplex
В этом же релизе закрыта уязвимость CVE-2026-19650 с оценкой High и баллом CVSS 7.1 — межсайтовая подделка запроса (CSRF) в обработчике мультиплексных запросов GraphQL. Из-за некорректной проверки запросов неаутентифицированный пользователь при определённых условиях мог выполнять мутации через GET-запросы.
В отличие от критической проблемы, для эксплуатации этой уязвимости требуется взаимодействие с пользователем.
Сроки раскрытия деталей
Технические подробности обеих уязвимостей появятся в публичном трекере GitLab через 90 дней после выпуска патча — примерно в середине ноября 2026 года. Ранее компания сокращала этот срок до 30 дней, как было в релизе от 10 июня 2026 года.
Обновление не добавляет новых миграций и не потребует простоя на multi-node развёртываниях.
Частые вопросы
Кого касается эта уязвимость?
Всех, кто использует self-managed GitLab версий от 18.2 до 19.2.4. Пользователи GitLab.com и GitLab Dedicated уже защищены — патч применён на стороне облака.
Как проверить свою версию GitLab?
Зайдите в раздел «Help» в интерфейсе GitLab или выполните команду cat /opt/gitlab/version на сервере. Сравните номер с уязвимым диапазоном: 18.2–18.11.10, 19.0–19.0.7, 19.1–19.1.5, 19.2–19.2.3.
Что делать, если я не могу обновиться прямо сейчас?
Ограничьте доступ к интерфейсу GitLab по сети — например, через firewall или VPN. Это снизит риск удалённой атаки, но не устранит уязвимость полностью. Планируйте обновление в ближайшее окно обслуживания.
Опасна ли уязвимость для частных проектов?
Уязвимость затрагивает публичные проекты и данные. Если все ваши репозитории приватные, риск ниже, но не нулевой — точные условия эксплуатации не раскрыты, поэтому обновление всё равно обязательно.
Есть ли обходные пути без установки патча?
GitLab не предоставил обходных мер. Единственный надёжный способ защиты — обновление до исправленной версии.
Затронуты ли реестровые российские ОС?
GitLab — кроссплатформенное приложение, работающее поверх ОС. Уязвимость находится в самом приложении, поэтому она актуальна независимо от того, на какой системе развёрнут GitLab — Astra Linux, РЕД ОС или любой другой. Обновлять нужно сам GitLab.
Когда появятся подробности об уязвимости?
GitLab публикует детали в своём публичном трекере через 90 дней после релиза патча, то есть примерно в середине ноября 2026 года. До этого времени технические детали известны только разработчикам.
GitLab уже не впервые сталкивается с серьёзными проблемами безопасности: ранее в этом году исследователи публиковали рабочий эксплойт для другой уязвимости, затрагивающей self-managed серверы. Связанная с этим история — уязвимости в парсере Oj, приводившие к RCE, — показывает, что проблемы в Ruby-экосистеме GitLab могут оставаться незамеченными годами.
Для администраторов, которые следят за безопасностью своей инфраструктуры, актуальны и другие недавние критические находки — например, уязвимость в Ruby on Rails Active Storage, позволяющая читать файлы и выполнять код удалённо.
Источник: thehackernews.com