Дослідник безпеки Yuhang Wu з компанії depthfirst опублікував робочий концепт експлойту (PoC), який дозволяє виконувати довільні системні команди на серверах self-managed GitLab. Вразливість призводить до віддаленого виконання коду (RCE) та запускає процеси від імені системного користувача git. Це дає зловмисникам повний доступ до сховищ вихідного коду, внутрішніх налаштувань та бази даних платформи.

Атака є надзвичайно небезпечною через простоту своєї реалізації. Для запуску шкідливого коду зловмиснику потрібні мінімальні права — достатньо мати звичайний обліковий запис у системі з можливістю створення комітів або завантаження файлів у репозиторій. Весь процес експлуатації зав'язаний на механізмі порівняння змін (diff) для інтерактивних блокнотів Jupyter (файли з розширенням .ipynb), які часто використовуються розробниками та інженерами з машинного навчання.

Технічний механізм вразливості криється в тому, як саме GitLab обробляє та рендерить файли Jupyter у веб-інтерфейсі. Оскільки структура блокнотів побудована на форматі JSON, під час запиту порівняння двох версій файлу .ipynb платформа викликає внутрішні парсери для обчислення та візуального відображення різниці між ними. Через недостатню валідацію вхідних даних у цих парсерах, атакуючий може впровадити спеціально сформовані аргументи або командні конструкції в JSON-структуру файлу. Коли користувач (або сам атакуючий) ініціює запит на відображення порівняння (diff request) у веб-консолі, сервер автоматично виконує закладену команду в операційній системі.

Цей ланцюжок експлуатації не потребує жодних адміністративних привілеїв, наявності активних раннерів для безперервної інтеграції (CI runners) або взаємодії з боку інших користувачів чи адміністраторів системи. Атакуючому достатньо самостійно надіслати запит на порівняння власноруч завантажених файлів, щоб тригерувати виконання коду. Це робить уразливість критичною для компаній, які дозволяють реєстрацію сторонніх користувачів або мають велику кількість внутрішніх розробників з різними рівнями доступу.

Отримання прав користувача git на сервері GitLab еквівалентне повному контролю над усім сервером керування кодом. Зловмисник отримує прямий доступ до файлової системи, де зберігаються всі репозиторії організації, конфігураційні файли (зокрема database.yml із доступами до бази даних), а також секрети та змінні середовища, що використовуються у процесах CI/CD. Крім того, це відкриває можливості для подальшого підвищення привілеїв до рівня root на хості або горизонтального переміщення (lateral movement) всередині корпоративної мережі компанії.

Що це означає на практиці

Для захисту власної інфраструктури від цієї загрози команда пентестерів рекомендує вжити таких невідкладних заходів:

  • Негайне оновлення GitLab: Перевірте версію вашого self-managed GitLab. Робочий експлойт був протестований на версії 18.11.3. Якщо ви використовуєте вразливу версію або попередні збірки цієї гілки, терміново встановіть офіційні патчі від GitLab. Перехід на безпечні версії є єдиним надійним способом усунення проблеми.
  • Аналіз логів веб-сервера: Проведіть аудит журналів доступу GitLab на предмет підозрілих запитів, які містять звернення до порівняння diff для файлів із розширенням .ipynb. Особливу увагу слід звернути на активність нових або малоактивних користувачів, які раптово завантажили Jupyter-блокноти та одразу після цього ініціювали запити порівняння.
  • Моніторинг системних процесів: Налаштуйте правила виявлення аномальної активності в операційній системі, де розгорнуто GitLab. Будь-які дочірні процеси, що запускаються від імені користувача git (наприклад, виклики curl, wget, bash, sh, nc або запуск неочікуваних скриптів), мають розглядатися як інцидент безпеки та автоматично блокуватися.
  • Обмеження вихідного мережевого трафіку: Налаштуйте правила міжмережевого екрана (firewall) для сервера GitLab так, щоб максимально обмежити вихідні з'єднання (egress filtering). Це завадить атакуючому успішно отримати зворотний шелл (reverse shell) або завантажити додаткові шкідливі інструменти з інтернету у випадку успішної експлуатації.
  • Аудит прав користувачів: Обмежуйте можливість реєстрації нових користувачів на ваших публічних серверах GitLab та регулярно проводьте інвентаризацію облікових записів. Вимкніть відкриту реєстрацію (sign-up), якщо вона не є життєво необхідною для бізнес-процесів.