Команда GitLab випустила позапланові оновлення безпеки, якими закрила критичну уразливість обходу двофакторної автентифікації (2FA) та кілька проблем, що дозволяють організувати DoS-атаки (відмову в обслуговуванні) проти GitLab Community Edition (CE) та Enterprise Edition (EE). Адміністраторам самокерованих інстансів рекомендовано якнайшвидше встановити оновлення.
Обхід двофакторної автентифікації GitLab: деталі CVE-2026-0723
Ключова уразливість отримала ідентифікатор CVE-2026-0723 і стосується як GitLab CE, так і GitLab EE. Проблема виникає через некоректну обробку повернених значень у сервісах автентифікації. За наявності ідентифікатора облікового запису жертви зловмисник міг підробити відповідь 2FA-пристрою та успішно пройти перевірку, фактично повністю обходячи двофакторний захист.
За такого сценарію будь-хто, хто володіє або зміг підібрати основну пару логін + пароль, отримує повний контроль над обліковим записом, навіть якщо в організації формально запроваджено обов’язкову 2FA. Для GitLab, який широко застосовується як критична DevSecOps-платформа (репозиторії вихідного коду, CI/CD, секрети, артефакти), це створює значні ризики компрометації коду та інфраструктури розробки.
Чому обхід 2FA у GitLab особливо небезпечний для DevSecOps та ланцюга постачання ПЗ
Двофакторна автентифікація у GitLab, як і на інших платформах, додається саме як другий бар’єр на випадок витоку пароля або його вдалого підбору. Якщо цей бар’єр можна обійти, будь-які раніше викрадені облікові дані миттєво перетворюються на повноцінний доступ до репозиторіїв та CI/CD-процесів.
У контексті ланцюга постачання програмного забезпечення це означає, що зловмисник, захопивши обліковий запис розробника чи DevOps-інженера, може:
— внести шкідливі зміни у вихідний код;
— модифікувати CI/CD-пайплайни для непомітного вбудовування бекдорів;
— підмінити артефакти збірки та контейнерні образи, які потім потраплять до середовищ замовників і партнерів.
Подібні атаки на DevSecOps-платформи вже неодноразово ставали відправною точкою масштабних інцидентів у ланцюгу постачання ПЗ, тому уразливості на кшталт CVE-2026-0723 мають розглядатися як пріоритетні.
DoS-атаки проти GitLab: кілька критичних векторів
Критичні DoS-уразливості CVE-2025-13927 та CVE-2025-13928
Окрім обходу 2FA, розробники GitLab усунули дві критичні уразливості відмови в обслуговуванні, доступні навіть для неавтентифікованих атакувальників.
CVE-2025-13927 дозволяє ініціювати DoS-атаку шляхом надсилання спеціально сформованих запитів із некоректними даними автентифікації. Обробка таких запитів змушує сервер GitLab витрачати непропорційно багато процесорного часу та пам’яті, що може призвести до суттєвого уповільнення або повної недоступності сервісу.
Уразливість CVE-2025-13928 пов’язана з помилками перевірки прав доступу до API. Зловмисник без облікового запису здатен сформувати послідовність API-запитів, яка перевантажує систему та викликає відмову в обслуговуванні. Для компаній, де GitLab є «серцем» CI/CD, подібні DoS-атаки означають зупинку збірок, затримки релізів і прямі фінансові втрати.
Уразливості середньої критичності у Wiki та SSH (CVE-2025-13335, CVE-2026-1102)
Дві додаткові уразливості класифіковано як середньої критичності, але за певних умов вони також можуть призвести до DoS.
CVE-2025-13335 стосується обробки Wiki-документів. Некоректно сформований вміст Wiki здатен обійти перевірку циклічних залежностей і спричинити ресурсомістку обробку даних. Як наслідок, GitLab-інстанс може виявитися перевантаженим. Небезпека полягає в тому, що шкідливий Wiki-документ здатен завантажити навіть користувач з обмеженими правами.
Уразливість CVE-2026-1102 стосується підсистеми SSH-автентифікації. Багаторазова відправка некоректних SSH-запитів дозволяє атакувальнику поступово виснажувати ресурси сервера, створюючи умови для відмови в обслуговуванні, зокрема й на рівні мережевої інфраструктури.
Які версії GitLab захищені та кому необхідно оновлюватися
Для усунення всіх перерахованих уразливостей GitLab випустив оновлення 18.8.2, 18.7.2 та 18.6.4 для Community Edition і Enterprise Edition. Користувачам самостійно розгорнутих інстансів настійливо рекомендується негайно перейти на одну з цих версій після створення резервних копій та планування короткого вікна обслуговування.
Хмарний сервіс GitLab.com уже оновлений і не потребує додаткових дій з боку користувачів. Клієнтам GitLab Dedicated також не потрібно втручатися — оновлення впроваджуються провайдером у рамках керованого сервісу.
За даними Shadowserver, у відкритому доступі перебуває близько 6000 інстансів GitLab CE, а сервіс Shodan фіксує понад 45 000 пристроїв, пов’язаних з GitLab. Частина з них може залишатися вразливою, якщо оновлення безпеки ще не встановлено. Водночас платформа GitLab має понад 30 млн зареєстрованих користувачів і використовується більш ніж половиною компаній із переліку Fortune 100, що робить будь-які уразливості в GitLab важливими для глобальної кіберстійкості.
Практичні кроки для підвищення безпеки GitLab
Оновіть GitLab якнайшвидше. Перевірте поточну версію свого інстансу, підготуйте резервну копію конфігурації та даних і заплануйте встановлення релізів 18.8.2, 18.7.2 або 18.6.4 відповідно до вашої гілки.
Обмежте зовнішній доступ до GitLab. По можливості розташуйте GitLab за VPN або reverse-proxy, використовуйте WAF і списки дозволених IP-адрес, особливо для адміністративної консолі та SSH-доступу. Це знижує ризики як експлуатації уразливостей, так і масового брутфорсу.
Посильте механізми автентифікації. Продовжуйте застосовувати 2FA, а де можливо — впроваджуйте SSO з корпоративним Identity Provider, політики складних паролів і моніторинг аномальної активності входів (незвичні геолокації, масові невдалі спроби тощо).
Налаштуйте моніторинг і сповіщення. Організуйте централізований збір логів GitLab, SSH і веб-сервера, додайте оповіщення на різкі сплески запитів, помилки автентифікації та збільшення навантаження. Це дозволить раніше виявляти ознаки DoS-атак і спроби експлуатації уразливостей.
Упорядкуйте управління вразливостями. Підпишіться на безпекові розсилки GitLab і включіть оперативне встановлення security-оновлень до стандартних DevSecOps-процесів. Критичні уразливості на кшталт CVE-2026-0723 мають закриватися в максимально короткі терміни.
Останні уразливості обходу двофакторної автентифікації та DoS-атаки проти GitLab ще раз демонструють, що DevSecOps-платформи є високовартісною ціллю для зловмисників. Чим швидше інстанси оновлені до захищених версій, а доступ до них сегментований, моніторинг і автентифікація налаштовані належним чином, тим нижчою буде ймовірність компрометації репозиторіїв і зупинки процесів розробки. Якщо GitLab є ключовим елементом вашої інфраструктури, варто вже зараз перевірити поточну версію, встановити патчі безпеки та переглянути базові налаштування захисту платформи.
