КИБЕРБЕЗОПАСНОСТЬ

GitLab закрыл критическую дыру: патчить self-managed нужно срочно

CVE-2026-85706 получила максимальную критичность: GitLab выпустил патчи для CE и EE, а сканирование уязвимых серверов уже началось.

✍️ Редакция iTech News | 12.09.2026 | ⏱ 3 мин | Источник: BleepingComputer
🦠

Уязвимость GitLab CVE-2026-85706 получила максимальную степень критичности: через нее неавторизованный атакующий при определенных условиях может читать произвольные данные с уязвимого сервера. Для команд, которые держат self-managed GitLab внутри периметра или торчащим в интернет, это не «поставим в пятницу вечером», а задача уровня «закрыть до следующего кофе».

GitLab призвала администраторов немедленно обновить серверы, сообщает BleepingComputer. Проблема связана с path traversal в API коммитов репозитория: из-за некорректного ограничения путей и недостаточной проверки аутентификации запрос может добраться до данных, к которым у внешнего пользователя доступа быть не должно. В худшем сценарии это секреты, учетные данные, токены и другая чувствительная информация. То есть ровно то, что обычно превращает одну багу в длинную неделю для security- и platform-команд.

Баг нашел исследователь под ником s3ntago и передал через программу GitLab на HackerOne. CVE-2026-85706 затрагивает GitLab Community Edition и Enterprise Edition; исправления вышли в версиях 19.3.2, 19.2.6 и 19.1. GitLab.com уже работает на исправленной версии, а клиентам GitLab Dedicated, по данным компании, ничего делать не нужно. Все остальные self-managed-инсталляции остаются зоной ответственности своих админов, и именно там сейчас главный риск.

Формально GitLab пока не пометила CVE-2026-85706 как уязвимость, которая уже эксплуатируется в реальных атаках. Но это слабое утешение: компания watchTowr уже заметила сканирование интернет-доступных GitLab-серверов на предмет этой дыры. По ее оценке, атакующему достаточно одного HTTP-запроса, чтобы попытаться прочитать произвольные файлы. Для защитников практический вывод простой: обновление важнее красивого отчета, но логи тоже стоит поднять. В первую очередь искать POST-запросы к адресам вида /api/v4/projects/{id}/repository/commits/, где встречается параметр file.path.

Одновременно GitLab закрыла еще одну критическую проблему — CVE-2026-87719. Она связана с небезопасной десериализацией в GraphQL subscription serializer и затрагивает GitLab EE. В отличие от CVE-2026-85706, здесь нужен аутентифицированный пользователь с доступом к Duo Chat, но последствия тоже неприятные: кража чувствительных учетных данных и конфигураций Advanced Search. Для компаний, где GitLab давно стал не просто репозиторием, а центром DevSecOps-процессов, это напоминание: поверхность атаки растет вместе с удобством платформы.

Контекст у истории неприятно знакомый. В мае 2023 года GitLab уже исправляла path traversal максимальной критичности — CVE-2023-2825. Тогда под угрозой тоже были закрытый код, пользовательские учетные данные, токены и файлы на не обновленных серверах. В 2024 году CISA и FBI отдельно призывали разработчиков выбрасывать path traversal из продуктов еще до релиза и называли такие баги фактически «непростительными» для индустрии. Звучит жестко, но для систем, которые хранят код, CI/CD-секреты и доступы к инфраструктуре, это не академический спор о качестве кода.

GitLab — слишком крупная цель, чтобы рассчитывать на тишину после публикации патча. Платформой пользуются более 30 млн зарегистрированных пользователей, а среди клиентов — больше половины компаний Fortune 100, включая Nvidia, Airbus, T-Mobile, Lockheed Martin, Goldman Sachs и UBS. Даже если ваша инсталляция куда скромнее, атакующие обычно не начинают с рейтинга Fortune: они начинают с массового сканирования и списка открытых хостов. Маленький сервер с забытым проектом и старыми токенами может оказаться удобнее, чем крепость с выделенной командой SOC.

Для русскоязычных IT-команд история упирается не только в конкретный патч. Self-managed GitLab часто ставят из соображений контроля, комплаенса и привычки: свой сервер, свои раннеры, свои секреты, своя боль. Но такая модель требует дисциплины обновлений, инвентаризации публичных инстансов и нормальной реакции на CVE максимальной критичности. Уязвимость GitLab CVE-2026-85706 показывает, что окно между релизом исправления и первыми пробами снаружи сжимается до часов; дальше выигрывают не самые умные, а самые быстрые и организованные.

Поделиться: Telegram X LinkedIn