Разработчики GitLab выпустили внеплановые обновления безопасности, закрывающие критическую уязвимость обхода двухфакторной аутентификации (2FA) и несколько багов, позволяющих вызвать отказ в обслуживании (DoS) на серверах GitLab Community Edition и Enterprise Edition. Владельцам самоуправляемых инстансов GitLab рекомендуется установить патчи как можно быстрее.
Обход двухфакторной аутентификации GitLab (CVE-2026-0723)
Ключевая проблема получила идентификатор CVE-2026-0723 и затрагивает как GitLab CE, так и GitLab EE. Уязвимость связана с некорректной обработкой возвращаемых значений в сервисах аутентификации. При знании идентификатора аккаунта жертвы злоумышленник мог подделать ответ устройства и пройти проверку двухфакторной аутентификации, фактически обходя 2FA.
Это означает, что при успешной эксплуатации атакующий получал возможность полного захвата учётной записи при наличии или подборе основного логина/пароля. Для GitLab, который часто используется как критически важная DevSecOps-платформа (хостинг исходного кода, CI/CD, управление секретами и артефактами), такой сценарий напрямую ведёт к рискам компрометации кода, внедрения бэкдоров и подмены артефактов поставки ПО.
Почему обход 2FA особенно опасен для DevSecOps-сред
Двухфакторная аутентификация в GitLab и других платформах введена как дополнительный барьер на случай утечки или подбора пароля. Обход 2FA превращает любую ранее украденную связку «логин + пароль» в полноценный доступ, даже если администратор формально включил обязательную двухфакторную авторизацию.
В контексте цепочки поставки ПО (software supply chain) это критично: компрометация одного аккаунта разработчика или DevOps-инженера может дать злоумышленнику возможность внедрить вредоносный код в репозиторий, пайплайн CI/CD или образ контейнера, а затем тихо распространить его на клиентов и партнёров.
DoS-атаки на GitLab: три вектора отказа в обслуживании
Критические DoS-уязвимости CVE-2025-13927 и CVE-2025-13928
Помимо обхода 2FA, в GitLab CE/EE закрыты ещё две критические уязвимости отказа в обслуживании, которые могут использоваться неаутентифицированными злоумышленниками.
Уязвимость CVE-2025-13927 позволяет вызвать DoS путём отправки специальных запросов с некорректными данными аутентификации. В результате сервер GitLab тратит непропорционально много ресурсов на обработку таких запросов, что может приводить к перегрузке и недоступности сервиса.
Вторая критическая проблема, CVE-2025-13928, связана с ошибками валидации прав доступа к API. Атакующий без учётной записи способен сформировать последовательность запросов, которая приводит к отказу в обслуживании. Для компаний, зависящих от стабильной работы CI/CD-пайплайнов и репозиториев, подобные DoS-атаки означают прямые простои разработки и срывы релизов.
Уязвимости средней серьёзности: Wiki и SSH (CVE-2025-13335 и CVE-2026-1102)
Разработчики также устранили две уязвимости среднего уровня риска, которые тем не менее могут привести к отказу в обслуживании.
Первая, CVE-2025-13335, связана с обработкой Wiki-документов. Некорректно сформированный Wiki-контент мог обойти проверку циклических зависимостей и привести к ресурсозатратной обработке, вызывая DoS. Такой вектор опасен тем, что вредоносный документ может быть загружен пользователем с ограниченными правами.
Вторая уязвимость, CVE-2026-1102, затрагивает подсистему SSH-аутентификации. Повторная отправка некорректных SSH-запросов на аутентификацию позволяла злоумышленнику перегружать сервер, создавая условия отказа в обслуживании, в том числе на уровне сетевой инфраструктуры.
Какие версии GitLab защищены и кому нужно обновляться
Для устранения всех перечисленных уязвимостей GitLab выпустил обновления 18.8.2, 18.7.2 и 18.6.4 для Community Edition и Enterprise Edition. Компания подчёркивает, что всем, кто использует самостоятельно развернутый GitLab, следует немедленно перейти на одну из этих версий.
Платформа GitLab.com уже обновлена и не требует действий со стороны пользователей. Клиентам GitLab Dedicated также не нужно предпринимать шаги: обновление применяется провайдером автоматически в рамках управляемого сервиса.
Масштаб риска: тысячи открытых GitLab-инстансов
По данным Shadowserver, в открытом доступе сейчас находится порядка 6000 экземпляров GitLab CE. Сервис Shodan обнаруживает свыше 45 000 устройств, связанных с GitLab. Часть из них могут быть напрямую уязвимы к описанным атакам, если обновления ещё не установлены.
Согласно официальной статистике, DevSecOps-платформа GitLab насчитывает более 30 млн зарегистрированных пользователей. Среди клиентов — свыше 50% компаний из списка Fortune 100, включая Nvidia, Airbus, T-Mobile, Lockheed Martin, Goldman Sachs и UBS. Это делает любые уязвимости GitLab потенциально значимыми с точки зрения глобальной кибербезопасности и устойчивости цепочек поставки ПО.
Практические рекомендации по защите GitLab
Обновите GitLab как можно быстрее. Проверьте текущую версию, спланируйте краткое окно обслуживания, создайте резервную копию и установите релизы 18.8.2, 18.7.2 или 18.6.4 в зависимости от вашей ветки.
Минимизируйте внешний доступ. Ограничьте доступ к GitLab из интернета с помощью VPN, reverse-proxy, WAF и списков разрешённых IP-адресов, особенно для административного интерфейса и SSH.
Усилите аутентификацию. Продолжайте использовать 2FA, а при возможности внедряйте SSO с корпоративным Identity Provider, политиками сложных паролей и мониторингом аномальной активности входов.
Включите мониторинг и алерты. Настройте сбор логов GitLab, SSH и веб-сервера, создайте оповещения на аномальные всплески запросов, ошибки аутентификации и резкое увеличение нагрузки — это поможет вовремя обнаружить попытки DoS-атаки или брутфорса.
Регулярно отслеживайте бюллетени безопасности. Подпишитесь на security-рассылку GitLab и внедрите в процессы DevSecOps практику своевременного управления уязвимостями, чтобы не пропускать критические обновления, подобные CVE-2026-0723.
Свежие уязвимости GitLab вокруг обхода двухфакторной аутентификации и DoS-атак ещё раз показывают, что DevSecOps-платформы сами по себе являются высокоценной целью для злоумышленников. Чем быстрее установлены обновления безопасности и чем лучше выстроены процессы мониторинга, сегментации и аутентификации, тем ниже риск компрометации репозиториев и сбоев в разработке. Если GitLab является ключевым элементом вашей инфраструктуры, имеет смысл прямо сейчас проверить версию, обновить инстансы и пересмотреть базовые настройки безопасности платформы.
