Коротко: 24 июля 2026 года исследователи depthfirst выложили рабочий эксплойт для критической уязвимости удалённого выполнения кода (RCE) в self-hosted GitLab. GitLab тихо закрыл дыру ещё 10 июня — в «рутинном» обновлении, без CVE, без бюллетеня безопасности и без предупреждения администраторам. Любой авторизованный пользователь с правом push может выполнить команды на сервере от имени учётной записи git и добраться до исходного кода, секретов и данных CI/CD. Держите свой GitLab? Срочно обновитесь.
Что произошло
24 июля 2026 года исследовательская команда depthfirst опубликовала полноценный прототип эксплойта (PoC) для цепочки удалённого выполнения кода в GitLab редакций Community и Enterprise. Неприятная деталь: сами ошибки GitLab исправил ещё за шесть недель до этого, 10 июня, но ничего не сообщил. Правку провели как обычное «исправление ошибок» в примечаниях к релизу — без идентификатора CVE, без бюллетеня безопасности и без всякого сигнала огромному числу администраторов self-managed GitLab. В итоге многие команды так и не обновились — просто потому, что им не сказали, что обновляться нужно.
Публичный эксплойт мгновенно меняет уровень риска. Он настолько снижает порог входа, что за массовым сканированием и автоматическими атаками на открытые необновлённые инстансы обычно дело идёт в считаные дни. Это тот же сценарий, что мы разбирали с эксплойтом для форумов vBulletin: исправление есть, но каждый необновлённый сервер остаётся открытым настежь — только здесь на этих серверах лежит самый чувствительный актив компании, её код.
Почему уязвимость настолько опасна
Корень проблемы — пара ошибок повреждения памяти в Oj, распространённом Ruby-парсере JSON, написанном как нативное C-расширение (уязвимы версии Oj с 3.13.0 по 3.17.1, исправлено в 3.17.3). GitLab выходит на этот уязвимый код неожиданным путём — через свой рендерер диффов для ноутбуков, небольшой встроенный компонент ipynbdiff, который превращает файлы Jupyter .ipynb в читаемые диффы. Когда пользователь открывает дифф коммита для файла-ноутбука, GitLab передаёт сырые байты из репозитория прямо в парсер Oj внутри рабочего процесса Puma — и специально сформированный ноутбук вызывает повреждение памяти и в итоге выполнение кода.
Условия для атаки тревожно низкие. Нужен лишь авторизованный аккаунт с правом push к любому проекту — без прав администратора, без доступа к CI и без каких-либо действий жертвы. Атакующий коммитит специально подготовленный ноутбук, открывает его дифф — и эксплойт выполняет команды от имени пользователя git. Сами ошибки внесли ещё 8 августа 2021 года, а уязвимый путь с ноутбуками попал в продукт в июле 2022 года вместе с GitLab 15.2.0 — то есть дыра оставалась открытой около 1753 дней, прежде чем её закрыли.
Что под угрозой
Выполнение кода от имени учётной записи git — это почти полный контроль над сервером GitLab. Отсюда атакующий может прочитать все приватные репозитории, извлечь секреты Rails и служебные учётные данные, добраться до данных CI/CD-конвейеров и токенов деплоя. Именно последнее превращает один взломанный сервер в проблему цепочки поставок: украденные секреты конвейера позволяют отравить сборки или пробиться в связанные системы — та же логика эскалации, что мы описывали, когда одна утечка учётных данных обернулась новой волной взломов в материале про утечку миллиардов учётных данных. Для большинства компаний исходный код и лежащие рядом ключи — это и есть главная драгоценность.
Кого это касается?
Под ударом именно self-managed GitLab — инстансы, которые компания разворачивает и обновляет сама. Уязвимы редакции CE и EE с 15.2.0 по 18.10.7, с 18.11.0 по 18.11.4 и с 19.0.0 по 19.0.1. Исправления — в версиях 18.10.8, 18.11.5 и 19.0.2. Собственный облачный сервис GitLab (GitLab.com) обслуживается самой компанией и был закрыт ещё июньским обновлением, так что его пользователям делать ничего не нужно. Совсем старые релизы (с 15.2 по 18.9) вообще сняты с сопровождения по безопасности — им нужен не патч, а переход на поддерживаемую версию.
Как защитить сервер и данные
Обновитесь немедленно. Перейдите на 18.10.8, 18.11.5 или 19.0.2 (или новее). Обходного решения на уровне только настроек нет — реально закрывает дыру лишь обновление ПО.
Не выставляйте GitLab в открытый интернет. Серверу с исходным кодом почти никогда не нужно быть доступным всему миру. Если убрать его за корпоративный VPN, чтобы до страницы входа дотягивались только авторизованные сотрудники из внутренней сети, поверхность атаки резко сокращается, а появление следующей дыры даёт запас времени. Это стандартная эшелонированная защита для внутренней инфраструктуры разработки.
Пересмотрите, у кого есть право push. Раз эксплойту достаточно низкопривилегированного аккаунта с правом записи, проверьте список пользователей и токенов, удалите заброшенные учётки и смените учётные данные и секреты CI/CD, если подозреваете, что сервер был доступен снаружи, пока оставался необновлённым.
Защитите разработчиков в недоверенных сетях. VPN не устраняет серверную дыру — это делает только обновление. Но для инженеров, которые подключаются к внутренним системам из кафе, аэропортов или общего Wi-Fi, no-logs VPN шифрует трафик, чтобы никто в той же сети не перехватил сессии и токены, которые они отправляют. LiMP VPN — no-logs-сервис для iOS и Android; смотрите возможности и тарифы, а больше новостей о безопасности — в нашем блоге.
Затронут ли GitLab.com (облачный сервис)?
Нет. GitLab.com обслуживается самим GitLab и был закрыт в рамках июньского обновления от 10 июня, поэтому пользователям облачного сервиса делать ничего не нужно. Риск касается self-managed-инстансов, которые организации держат на своих серверах и которые так и не обновили, — как раз потому, что исправление вышло тихо, без пометки о проблеме безопасности. Если вы администрируете такой инстанс, относитесь к обновлению как к срочному.
Источники
Материал подготовлен по публикациям The Hacker News и Security Affairs (июль 2026 года), со ссылкой на техническое раскрытие и PoC команды depthfirst.