Уязвимость CVE-2026-19478 получила 9,4 балла по шкале CVSS и относится к критическим ошибкам внедрения кода. Для атаки не нужны учётная запись, пароль, действия пользователя или редкая конфигурация сервера. При определённых условиях достаточно найти общедоступный проект на GitLab и отправить подготовленный запрос с директивой GraphQL. Подробности механизма GitLab раскрыл в предупреждении, выпущенном ранее на той же неделе, когда появились сообщения об атаках; точная дата публикации в доступных данных не указана.
Компания watchTowr, занимающаяся проактивным управлением внешней поверхностью атак, воспроизвела ошибку в течение нескольких минут после её раскрытия. Затем специалисты обнаружили попытки эксплуатации на собственной сети ловушек. В комментарии для The Hacker News исследователи сообщили, что атаки начались в реальных условиях уже через несколько дней после публикации сведений о CVE-2026-19478. Обычного периода, когда администратор мог спокойно изучить бюллетень и запланировать работы, фактически не осталось.
Через уязвимость посторонний человек может изменять или удалять публично доступные проекты, переписывать проектные данные и уничтожать репозитории целиком. Этим ущерб не ограничивается. Атакующий способен подделать записи о слиянии веток, создав видимость, будто исправление безопасности или иное изменение уже включено в код, хотя на деле этого не произошло. Возможна и блокировка сопровождающих проекта. Такая подмена истории опаснее обычного повреждения файлов: команда может довериться ложной записи и развернуть версию, в которой известная брешь осталась открытой.
Исправления выпущены для GitLab Community Edition (CE) и Enterprise Edition (EE). Безопасными названы релизы 18.11.11, 19.0.8, 19.1.6 и 19.2.4. Уязвимы ветки 19.0 до 19.0.8, 19.1 до 19.1.6 и 19.2 до 19.2.4. Ещё один диапазон в опубликованных данных записан как «2 до 18.11.11»; эта формулировка выглядит обрезанной или ошибочной. Операторам ветки 18.11 разумно не пытаться угадывать пропущенную часть, а установить 18.11.11 либо более новую поддерживаемую сборку.
Джейк Нотт (Jake Knott), главный исследователь безопасности watchTowr, описал перемену так: «Такова новая реальность воспроизведения и эксплуатации уязвимостей: злоумышленники, использующие ИИ [искусственный интеллект], способны сжать время от раскрытия до эксплуатации, и ожидание следующего цикла установки исправлений часто оказывается слишком долгим». ИИ здесь нужен атакующим не как самостоятельный «взломщик», а как средство быстрее разобрать описание ошибки, подготовить рабочий запрос и разнести его по большому числу доступных узлов.
Первоочередная мера для общедоступных самоуправляемых экземпляров GitLab — немедленный переход на 18.11.11, 19.0.8, 19.1.6 или 19.2.4 в зависимости от используемой ветки. Откладывать установку до планового окна обслуживания рискованно: исследователям понадобились минуты для воспроизведения, а первые наблюдаемые атаки последовали в течение нескольких дней. Перед обновлением стоит сохранить резервные копии репозиториев, базы данных и конфигурации, но создание копии не должно превращаться в повод отложить закрытие уязвимости.
Если обновление прямо сейчас невозможно, временно следует закрыть неаутентифицированный доступ к /api/graphql. Второй вариант, более жёсткий, — полностью убрать публичный доступ к репозиториям. Эти ограничения могут нарушить привычную работу внешних пользователей и интеграций, зато сокращают доступную атакующему поверхность. Считать их постоянной заменой исправлению нельзя: после установки безопасной версии правила доступа придётся пересмотреть отдельно.
На ещё не обновлённых серверах нужно проверить журналы веб-доступа на запросы с точной строкой @gl_introduced. Искать следует не одно совпадение, а связанные обращения к GraphQL, повторяющиеся запросы с разных адресов, необычные ответы сервера и последующие операции с проектами. Наличие строки может указывать на разведку или попытку эксплуатации, а её отсутствие само по себе не доказывает, что сервер чист: журналы могли храниться недолго, быть неполными либо уже подвергнуться вмешательству.
После подозрительного запроса требуется сверить историю изменений с фактическим состоянием веток и объектов Git, проверить удалённые проекты, права сопровождающих, блокировки пользователей и записи о слияниях. Особого внимания заслуживают якобы принятые исправления безопасности: запись о merge необходимо сопоставить с коммитами в целевой ветке и содержимым развёрнутой сборки. Если обнаружено расхождение, одного обновления GitLab мало — потребуются восстановление достоверных данных, смена потенциально раскрытых секретов и разбор действий атакующего по сохранённым журналам.
Изображение носит иллюстративный характер
Компания watchTowr, занимающаяся проактивным управлением внешней поверхностью атак, воспроизвела ошибку в течение нескольких минут после её раскрытия. Затем специалисты обнаружили попытки эксплуатации на собственной сети ловушек. В комментарии для The Hacker News исследователи сообщили, что атаки начались в реальных условиях уже через несколько дней после публикации сведений о CVE-2026-19478. Обычного периода, когда администратор мог спокойно изучить бюллетень и запланировать работы, фактически не осталось.
Через уязвимость посторонний человек может изменять или удалять публично доступные проекты, переписывать проектные данные и уничтожать репозитории целиком. Этим ущерб не ограничивается. Атакующий способен подделать записи о слиянии веток, создав видимость, будто исправление безопасности или иное изменение уже включено в код, хотя на деле этого не произошло. Возможна и блокировка сопровождающих проекта. Такая подмена истории опаснее обычного повреждения файлов: команда может довериться ложной записи и развернуть версию, в которой известная брешь осталась открытой.
Исправления выпущены для GitLab Community Edition (CE) и Enterprise Edition (EE). Безопасными названы релизы 18.11.11, 19.0.8, 19.1.6 и 19.2.4. Уязвимы ветки 19.0 до 19.0.8, 19.1 до 19.1.6 и 19.2 до 19.2.4. Ещё один диапазон в опубликованных данных записан как «2 до 18.11.11»; эта формулировка выглядит обрезанной или ошибочной. Операторам ветки 18.11 разумно не пытаться угадывать пропущенную часть, а установить 18.11.11 либо более новую поддерживаемую сборку.
Джейк Нотт (Jake Knott), главный исследователь безопасности watchTowr, описал перемену так: «Такова новая реальность воспроизведения и эксплуатации уязвимостей: злоумышленники, использующие ИИ [искусственный интеллект], способны сжать время от раскрытия до эксплуатации, и ожидание следующего цикла установки исправлений часто оказывается слишком долгим». ИИ здесь нужен атакующим не как самостоятельный «взломщик», а как средство быстрее разобрать описание ошибки, подготовить рабочий запрос и разнести его по большому числу доступных узлов.
Первоочередная мера для общедоступных самоуправляемых экземпляров GitLab — немедленный переход на 18.11.11, 19.0.8, 19.1.6 или 19.2.4 в зависимости от используемой ветки. Откладывать установку до планового окна обслуживания рискованно: исследователям понадобились минуты для воспроизведения, а первые наблюдаемые атаки последовали в течение нескольких дней. Перед обновлением стоит сохранить резервные копии репозиториев, базы данных и конфигурации, но создание копии не должно превращаться в повод отложить закрытие уязвимости.
Если обновление прямо сейчас невозможно, временно следует закрыть неаутентифицированный доступ к /api/graphql. Второй вариант, более жёсткий, — полностью убрать публичный доступ к репозиториям. Эти ограничения могут нарушить привычную работу внешних пользователей и интеграций, зато сокращают доступную атакующему поверхность. Считать их постоянной заменой исправлению нельзя: после установки безопасной версии правила доступа придётся пересмотреть отдельно.
На ещё не обновлённых серверах нужно проверить журналы веб-доступа на запросы с точной строкой @gl_introduced. Искать следует не одно совпадение, а связанные обращения к GraphQL, повторяющиеся запросы с разных адресов, необычные ответы сервера и последующие операции с проектами. Наличие строки может указывать на разведку или попытку эксплуатации, а её отсутствие само по себе не доказывает, что сервер чист: журналы могли храниться недолго, быть неполными либо уже подвергнуться вмешательству.
После подозрительного запроса требуется сверить историю изменений с фактическим состоянием веток и объектов Git, проверить удалённые проекты, права сопровождающих, блокировки пользователей и записи о слияниях. Особого внимания заслуживают якобы принятые исправления безопасности: запись о merge необходимо сопоставить с коммитами в целевой ветке и содержимым развёрнутой сборки. Если обнаружено расхождение, одного обновления GitLab мало — потребуются восстановление достоверных данных, смена потенциально раскрытых секретов и разбор действий атакующего по сохранённым журналам.
