CVE-2026-85706: Критична вразливість обходу директорій у GitLab, яку експлуатують у реальних умовах

GitLab випустила термінові оновлення безпеки для вразливості найвищого рівня у Community Edition (CE) та Enterprise Edition (EE), яка дозволяє неавторизованим зловмисникам читати довільні файли з вразливих серверів. Відстежується як CVE-2026-85706 і оцінена в 10.0 за шкалою CVSS, уразливість знаходиться в API комітів репозиторію та виникає через неправильно налаштоване обмеження шляхів у поєднанні з відсутністю забезпечення аутентифікації.

Ризик зріс майже одразу після розкриття. Дослідники з безпеки спостерігали за інтернет-скануванням, що почалося приблизно о 06:00 за UTC 11 вересня 2026 року, незабаром після того, як GitLab випустила патчі. В подальшому CISA додала вразливість до свого каталогу Відомих експлуатованих вразливостей на основі доказів активної експлуатації.

Успішна експлуатація може розкрити чутливі файли, збережені на сервері GitLab, включаючи дані конфігурації, облікові дані, секрети, логи та іншу інформацію, доступну GitLab сервісу. У середовищах розробки ті файли можуть містити секрети CI/CD, облікові дані розгортання, токени, дані, пов’язані з вихідним кодом, та інформацію, яка може підтримувати подальші компрометації.

Ця уразливість є особливо небезпечною для інтернет-направлених автономних установок GitLab, оскільки експлуатація не вимагає облікового запису, існуючих привілеїв або взаємодії з користувачем. Згідно з watchTowr, основною попередньою умовою для спостережуваного шляху атаки є те, що інстанція GitLab містить щонайменше один публічний проєкт.

Аналіз CVE-2026-85706

Уразливість є проблемою обходу шляху в API комітів репозиторію GitLab. GitLab описує кореневу причину як недостатнє обмеження шляхів файлів у поєднанні з невиконанням аутентифікації на ураженій функціональності. Це дозволяє керованій зловмисником інформації про шлях втекти з місця, де GitLab очікує, що файли репозиторію мають знаходитися, і посилатися на інші файли, доступні застосунку.

Вектор CVSS, призначений GitLab – CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Він відображає віддалено експлуатовану уразливість з низькою складністю атаки, без вимоги до аутентифікації і без взаємодії з користувачем. GitLab присвоює високий вплив на конфіденційність і цілісність, тоді як доступність не зазнає прямого впливу від самого механізму читання файлів.

Найважливішими деталями для CVE-2026-85706 є те, що зловмисники можуть взаємодіяти з уразливим API комітів репозиторію віддалено і запитувати шляхи, які повинні припадати за межами дозволеної директорії репозиторію. Якщо GitLab не вдається правильно обмежити цей шлях, сервер може повернути вміст довільного файлу, доступного процесу GitLab.

Згідно з watchTowr, експлуатація може розкрити специфічні для GitLab файли конфігурації та логи, які містять облікові дані, секрети та іншу чутливу інформацію. Залежно від конфігурації системи і дозволів на файли, зловмисники можуть також націлюватися на SSH-ключі, файли оточення, облікові дані бази даних, токени розгортання або інші чутливі дані застосунку.

CVE-2026-85706 впливає на такі видання GitLab CE та EE:

• Усі версії з 18.7 до 19.1.8
• Усі версії з 19.2 до 19.2.6
• Усі версії з 19.3 до 19.3.2

GitLab.com вже використовувала версію з виправленням, коли проблема була розкрита, тоді як замовникам GitLab Dedicated не потрібно вживати жодних дій. Термінова вимога до усунення дефекту стосується переважно організацій, що експлуатують автономні інстанції GitLab.

Вимога наявності щонайменше одного публічного проєкту суттєво збільшує можливість компрометації організацій, які навмисно розміщують репозиторії з відкритим кодом, публічні проєкти розробки, спільнотні ресурси або інший контент, доступний анонімно у власній інфраструктурі GitLab. Зловмиснику не потрібно бути учасником проєкту або мати дійсний обліковий запис GitLab перед спробою експлуатації.

Наслідки можуть поширюватися на більшу шкоду, ніж просто розкриття інформації. GitLab часто знаходиться в центрі конвеєрів розробки програмного забезпечення і зберігає вкрай чутливі матеріали, включаючи вихідний код, змінні CI/CD, облікові дані розгортання, конфігурацію інфраструктури, токени доступу та інтеграційні секрети.

Якщо зловмисник отримає такі облікові дані через довільний доступ до файлів, початкова вразливість GitLab може стати відправною точкою для додаткових дій втручання. Викрадені секрети можуть потенційно надати доступ до репозиторіїв вихідного коду, інфраструктури CI/CD, хмарних сервісів, реєстрів контейнерів, систем розгортання або інших підключених ресурсів.

Це також вводить ризик для ланцюга постачання ПЗ. Доступ до облікових даних розробки або інфраструктури зборки може дозволити зловмиснику спробувати несанкціоновані зміни у репозиторіях, маніпулювати процесом створення, викрасти власний код або скомпрометувати системи, що довіряють артефактам, створеним у вразливому середовищі GitLab.

GitLab відзначила дослідника з безпеки s3ntago за повідомлення про вразливість через програму винагород за помилки HackerOne. Точна дата приватного відкриття і звітності не була оприлюднена. GitLab випустила виправлені версії 10 вересня 2026 року і публічно задокументувала вразливість як частину критичного випуску патчу.

Переход з розкриття до ворожих дій був надзвичайно швидким. WatchTowr сказала, що її мережа honeypot Attacker Eye виявила поведінкові проби, спрямовані на уразливість приблизно з 06:00 за UTC 11 вересня, що вказує на те, що зовнішні актори вже зворотньо інженерили вразливість і почали тестування систем GitLab із доступом до Інтернету.

CISA додала вразливість до свого каталогу KEV пізніше 11 вересня після підтвердження доказів активної експлуатації. Федеральні агентства виконавчої гілки США були проінструктовані усунути уражені системи до 14 вересня 2026 року, і CISA також позначила вразливість як таку, що вимагає судової експертизи відповідно до Директиви з операційного регулювання 26-04.

Публічний код PoC для CVE-2026-85706 з’явився незабаром після розкриття, що ще більше знижує технічний бар’єр для зацікавлених зловмисників у відтворенні поведінки довільного читання файлів. У поєднанні з низькою складністю вразливості і неавторизованим шляхом атаки, публічне відтворення збільшує ймовірність більш широкої опортуністичної експлуатації.

На даний момент немає комплексного набору специфічних для кампанії IOC CVE-2026-85706, таких як IP-адреси атакуючих, домени або хеші шкідливого ПЗ, які можуть надійно ідентифікувати експлуатацію. Натомість, найкориснішим індикатором є структура запитів, спрямованих на вразливий API GitLab.

WatchTowr рекомендує шукати HTTP POST запити, спрямовані на шляхи, що збігаються з:

/api/v4/projects/{id}/repository/commits/

Захисники повинні звернути особливу увагу, коли ці запити містять підозрілі параметри file.Path або здається, що вони вимагають файли, не пов’язані з репозиторієм, який доступний.

Мітагція CVE-2026-85706

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

• GitLab 19.1.8
• GitLab 19.2.6
• GitLab 19.3.2

Будь-яка пізніша підтримувана версія, що містить виправлення безпеки, повинна також вирішувати вразливість. Адміністратори повинні перевірити точну працюючу версію, а не припускати, що автоматичне оновлення відбулося.

Організації, які не можуть одразу виправити проблему, повинні обмежити зайвий публічний доступ до ураженої інстанції GitLab або обмежити з’єднання на рівні зворотних проксі, файєрволу, балансувальника навантаження чи мережевого рівня, допоки оновлення не буде завершено. Це лише тимчасовий захід зниження експозиції і не повинен замінювати установку виправленої версії від GitLab.

Виявлення CVE-2026-85706 повинно починатися з ідентифікації всіх самокерованих інстанцій GitLab, їх точних версій і того, чи були вони доступні з Інтернету після 10 вересня. Системи, що розміщують один або більше публічних проєктів, повинні отримати особливо високий пріоритет для розслідування.

Щоб виявити експлуатацію або розвідку CVE-2026-85706, захисники повинні переглянути телеметрію GitLab, зворотних проксі, WAF та веб-серверів для:

• HTTP POST запитів до /api/v4/projects/{id}/repository/commits/
• Запити, що містять незвичайні параметри file.Path
• Послідовності обходу шляхів, що намагаються вийти за межі очікуваних директорій репозиторіїв
• Запити конфігурації або логів GitLab через API репозиторіїв
• Велика кількість запитів API комітів репозиторію з невідомих раніше джерел
• Анонімний доступ з подальшими незвичайними спробами отримати ресурси на сервері
• Неочікуваний доступ до облікових даних, конфігураційних файлів чи секретів застосунку
• Нова активність аутентифікації із використанням облікових даних, які могли бути розкриті через GitLab
• Незрозумілий доступ до CI/CD, хмари, реєстру чи інфраструктури розгортання після підозрілої активності GitLab

WatchTowr спеціально рекомендує аналізувати шаблон API комітів репозиторію, оскільки це може надати прямі докази спроб проби або експлуатації вразливого кінцевого пункту.

Виправлення повинно також супроводжуватися ретроспективним розслідуванням. Вимога CISA до судової експертизи відображає можливість того, що організації могли бути скомпрометовані до розгортання виправлення, особливо зважаючи на те, як швидко почалися атаки після розкриття.

Якщо виявлена підозріла активність читання файлів, адміністратори повинні з’ясувати, які саме файли могли бути доступні. Секрети, що містяться у потенційно розкритих файлах, слід вважати скомпрометованими, доки не доведено зворотне.

Організації повинні розглянути можливість ротації:

• Токенів доступу GitLab та особистого доступу
• Токенів розгортання
• Змінних і секретів CI/CD
• Облікових даних бази даних
• SSH-ключів
• Облікових даних хмари
• Облікових даних реєстру контейнерів
• API токенів та інтеграційних токенів
• OAuth секретів
• Облікових даних розгортання та автоматизації

Команди безпеки також повинні розслідувати системи, що довіряли цим обліковим даним. Оновлення GitLab закриває вразливу ділянку для читання файлів, але не може анулювати секрети, що вже були отримані зловмисником.

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

Зважаючи на серйозність CVSS 10.0, підтверджену експлуатацію, публічне відтворення та швидкий перехід від розкриття до сканування, усунення дефекту слід розглядати як екстрену ситуацію для інтернет-направлених автономних розгортань GitLab.