21 октября GitLab выпустил исправления для уязвимости CVE-2026-110264, которая позволяет выполнить произвольный код на сервере с самостоятельной установкой (self-managed) без входа в систему. Оценка по CVSS — 10.0, максимум. Затронуты все версии GitLab начиная с 7.0, вышедшей в 2014 году, то есть двенадцать лет релизов.
Что именно сломано: компилятор Onigmo
Причина в движке регулярных выражений. GitLab использует встроенный в Ruby движок Onigmo, который поставляется внутри собственных пакетов GitLab и патчится в собственных сборках. Слабость в этом движке присутствует везде, куда GitLab его поставлял, — а поставлял он его во всех выпусках с 7.0. По описанию GitLab, при определённых условиях уязвимость позволяет неаутентифицированному пользователю выполнить произвольный код из-за целочисленного переполнения при компиляции специально сформированного регулярного выражения.
Какие именно условия нужны атакующему, компания не раскрыла. Поэтому администратор не может исключить себя из группы риска по конфигурации: единственная надёжная защита — установка исправления. Временного обходного решения в рекомендациях GitLab нет.
Кого патч касается в первую очередь
Действовать нужно только владельцам self-managed инсталляций. GitLab.com уже работает на исправленной версии, а арендаторы GitLab Dedicated на внутренних релизах 19.3.5-internal0 и 19.4.2-internal0 и новее защищены.
Отдельно стоит подчеркнуть: даже те, кто обновился девятью днями раньше, снова в зоне риска. Обновление от 12 октября закрывало только версии 19.2 и новее, и новые исправленные версии стоят на один патч выше — инстанс, обновлённый тогда, опять попадает в диапазон уязвимости.
GitLab закрыл дыру сразу в семи ветках:
| Ветка | Исправленная версия |
|---|---|
| 19.5 до 19.5.1 | 19.5.1 |
| 19.4 до 19.4.3 | 19.4.3 |
| 19.3 до 19.3.6 | 19.3.6 |
| 19.2 до 19.2.9 | 19.2.9 |
| 19.1 до 19.1.9 | 19.1.9 |
| 19.0 до 19.0.10 | 19.0.10 |
| с 7.0 по 18.11, до 18.11.13 | 18.11.13 |
Четыре из этих версий старше тех, что GitLab обычно патчит. Политика компании покрывает текущий релиз и два предыдущих месячных выпуска — на сегодня это 19.5, 19.4 и 19.3. Исправления для 18.11.13, 19.0.10, 19.1.9 и 19.2.9 компания выпустила сверх стандартных релизов — так она поступает только при серьёзных проблемах.
Как искать следы эксплуатации
GitLab опубликовал два правила обнаружения, чтобы администраторы self-managed инсталляций могли искать попытки эксплуатации: «Onigmo native worker crash» и «Org mode render error burst». Оба входят в открытый фреймворк компании TLDR, где каждое правило описано в формате Sigma и опирается на собственные логи приложения GitLab.
Четвёртая дыра в том же движке за месяц
Это четвёртая уязвимость выполнения кода в движке регулярных выражений GitLab, о которой за месяц сообщил один и тот же исследователь под ником joaxcar, и первая, добравшаяся до версий старше 19.2.
- 12 октября GitLab закрыл CVE-2026-97229 — тоже неаутентифицированное переполнение с оценкой 10.0 в компиляторе регулярных выражений, в версиях 19.2.8, 19.3.5 и 19.4.2.
- 23 сентября закрыты ещё две, CVE-2026-93577 и CVE-2026-89078, обе с оценкой 9.9, но требующие учётной записи.
Все три предыдущие дыры останавливались на версии 19.2 — эта нет. Стоит помнить и о других недавних критических проблемах GitLab: path traversal с CVSS 10 и уязвимость GraphQL без аутентификации.
Остальные исправления и цена обновления
Релиз 21 октября закрывает 11 проблем безопасности: одну критическую и остальные высокого, среднего и низкого уровня. Две касаются аутентификации:
- CVE-2026-15723, высокий уровень 8.2, — вошедший в систему пользователь может захватить чужую учётную запись, но только если администратор включил одновременно SAML и LDAP auto-linking;
- CVE-2026-112212, высокий уровень 7.5, — отравление кеша в эндпоинтах OAuth и OpenID Connect GitLab позволяет перенаправить некоторые сценарии входа на сервер атакующего в конфигурациях с общим кешем.
Обновление требует планирования. Релизы 19.4.3 и 19.3.6 содержат изменения базы данных, которые выполняются во время апгрейда: на одноузловом сервере это означает простой, пока они не завершатся. Многоузловые инсталляции, по словам GitLab, могут применить патч без простоя по штатной процедуре zero-downtime.
GitLab в России и СНГ часто разворачивают именно как self-managed — на своём железе или в закрытом контуре, где облачный GitLab.com недоступен. Для таких инсталляций патч обязателен: версии старше 19.2, которых касается CVE-2026-110264, в корпоративных контурах живут годами. Перед обновлением заложите окно простоя под миграции базы и проверьте, не остались ли в парке узлы, обновлённые 12 октября — они снова уязвимы.
Частые вопросы
Кого касается CVE-2026-110264?
Только инсталляции GitLab с самостоятельным управлением. GitLab.com и арендаторы GitLab Dedicated на релизах 19.3.5-internal0 и 19.4.2-internal0 или новее уже защищены.
Уязвимы ли версии старше 19.2?
Да, и это главное отличие от трёх предыдущих дыр в том же движке. Затронуты все выпуски начиная с 7.0 2014 года; исправление для старых веток — 18.11.13.
Я обновился 12 октября, я в безопасности?
Нет. Обновление от 12 октября закрывало ветки 19.2 и новее, а новые исправленные версии стоят на один патч выше. Инстанс, обновлённый тогда, снова попадает в диапазон уязвимости.
Как проверить свою версию GitLab?
Сравните текущий номер с таблицей исправленных версий: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 и 18.11.13. Если ваша версия ниже соответствующей ветки, нужно обновляться.
Есть ли временное обходное решение?
Нет. GitLab не раскрыл условия, при которых дыра эксплуатируется, поэтому отсечь атаку настройками нельзя. В рекомендациях компании промежуточного решения нет — только установка патча.
Уже были атаки с использованием этой уязвимости?
GitLab сообщает, что признаков эксплуатации нет. На 22 октября CVE-2026-110264 не числится в каталоге известных эксплуатируемых уязвимостей CISA.
Как искать попытки эксплуатации в логах?
Используйте два правила из фреймворка TLDR: «Onigmo native worker crash» и «Org mode render error burst». Они написаны в формате Sigma и работают по логам самого приложения GitLab.
Будет ли простой при обновлении?
На одноузловом сервере — да, если ставите 19.4.3 или 19.3.6: в них есть изменения базы данных, выполняемые во время апгрейда. Многоузловые инсталляции могут применить патч без простоя по процедуре zero-downtime.
Источник: thehackernews.com