Компания GitLab выпустила важные обновления безопасности, устраняющие четыре уязвимости, включая критическую XSS-уязвимость, которая позволяла злоумышленникам выполнять действия от имени пользователей через инъекцию вредоносного контента. Выпущены патчи для версий 18.1.2, 18.0.4 и 17.11.6 как для Community Edition (CE), так и для Enterprise Edition (EE), и всем пользователям самоуправляемых инсталляций настоятельно рекомендуется немедленно обновить систему.
Критическая XSS-уязвимость и её последствия
Самая опасная из обнаруженных уязвимостей получила идентификатор CVE-2025-6948 и оценку 8.7 по шкале CVSS. Эта проблема затрагивает все версии GitLab CE/EE начиная с 17.11 вплоть до 17.11.5, версии 18.0 до 18.0.3 и 18.1 до 18.1.1. Уязвимость позволяет злоумышленникам внедрять вредоносный JavaScript-код в страницы GitLab, что может привести к выполнению несанкционированных действий от имени пользователей, включая кражу учетных данных, изменение настроек проектов или даже компрометацию всей системы.
Исследователь безопасности, известный под псевдонимом yvvdwf, обнаружил эту уязвимость в рамках программы Bug Bounty на платформе HackerOne. Высокий уровень опасности объясняется тем, что атакующий может полностью захватить сессию пользователя и получить контроль над репозиториями, CI/CD-конвейерами и другими критически важными функциями GitLab.
Другие обнаруженные уязвимости
Помимо критической XSS-уязвимости, GitLab исправил ещё три проблемы, связанные с неправильной проверкой прав доступа. Первая из них, CVE-2025-3396 (CVSS 4.3), позволяет владельцам проектов обходить ограничения на форки через манипуляции с API. Эта уязвимость существовала с версии 13.3, а значит, могла использоваться злоумышленниками на протяжении нескольких лет.
Остальные две уязвимости, CVE-2025-4972 и CVE-2025-6168, получили низкий рейтинг опасности (CVSS 2.7), но всё же требуют внимания. Они затрагивают только Enterprise Edition и позволяют авторизованным пользователям обходить ограничения на приглашение новых участников в группы через API или веб-интерфейс. Хотя их эксплуатация требует определённых привилегий, в корпоративных средах это может стать серьёзным риском для управления доступом.
Обновление rsync и дополнительные меры безопасности
В рамках патчей GitLab также обновил rsync до версии 3.4.1, устранив две уязвимости (CVE-2024-12084 и CVE-2024-12088), которые могли использоваться для атак, связанных с обработкой символических ссылок и переполнением буфера. Это демонстрирует комплексный подход компании к устранению не только собственных уязвимостей, но и проблем в зависимых компонентах.
Рекомендации по обновлению и защите
GitLab.com уже развернул исправления, а пользователям Dedicated-версий ничего предпринимать не нужно. Однако все остальные организации, использующие самоуправляемые инсталляции, должны немедленно обновиться до последних версий. Компания придерживается политики ответственного раскрытия информации, публикуя детали уязвимостей только через 30 дней после выхода патчей, чтобы дать пользователям время на обновление.
Эксперты по кибербезопасности рекомендуют не откладывать установку обновлений, так как уязвимости, подобные CVE-2025-6948, могут быть быстро использованы злоумышленниками для атак на корпоративные системы. Дополнительно стоит усилить мониторинг подозрительной активности в GitLab, особенно если обновление пока невозможно.
Кроме того, компаниям следует пересмотреть настройки доступа к API и убедиться, что все роли пользователей имеют минимально необходимые привилегии. Регулярный аудит логов поможет выявить попытки эксплуатации уязвимостей до того, как они приведут к серьёзным последствиям.
Заключение
Обнаруженные уязвимости в GitLab ещё раз подчёркивают важность своевременного обновления программного обеспечения, особенно в корпоративных средах, где атаки на системы контроля версий могут привести к утечке критически важных данных. Компаниям следует не только применять патчи, но и внедрять многоуровневую защиту, включая WAF-решения, сегментацию сети и строгий контроль доступа. GitLab продолжает совершенствовать свои механизмы безопасности, но ответственность за защиту инфраструктуры лежит и на самих пользователях.
