GitLab закликає терміново оновитися: критична CVE-2026-85706 з рейтингом 10.0 уже експлуатується

Якщо у вас власний GitLab, відкладати оновлення вже небезпечно. GitLab випустила критичні патчі для CVE-2026-85706 — уразливості в repository commits API, яка за певних умов дозволяє неавторизованому користувачу читати довільні файли із сервера. Оцінка CVSS — максимальні 10.0, а GitLab прямо підтверджує, що CVE вже додана до каталогу Known Exploited Vulnerabilities CISA.

Ризик особливо неприємний для DevOps-інфраструктури: файл, який «просто прочитали», може містити конфігурацію, токен, ключ або інший секрет, що відкриє наступний етап атаки. Тому правильна реакція — не лише поставити патч, а й оцінити, чи не могли секрети вже бути скомпрометовані.

Що відомо про CVE-2026-85706

За офіційним advisory GitLab, проблема пов’язана з improper path confinement і відсутнім enforcement автентифікації в repository commits API. За певних умов віддалений користувач без автентифікації міг прочитати довільні файли із GitLab-сервера.

Вектор CVSS, який публікує GitLab, показує найгірше поєднання для інтернет-сервісу: атака мережева, низької складності, не потребує облікового запису й взаємодії жертви. Саме тому базовий бал — 10.0.

Які версії GitLab уразливі

Офіційна матриця така: усі GitLab CE/EE від 18.7 до версій перед 19.1.8; гілка 19.2 до 19.2.6; гілка 19.3 до 19.3.2. Виправлення вийшли у 19.1.8, 19.2.6 та 19.3.2. GitLab рекомендує self-managed інсталяціям оновитися негайно.

Для користувачів GitLab.com та GitLab Dedicated ситуація інша: GitLab повідомляє, що керована інфраструктура вже пропатчена і клієнтам цих сервісів окремо нічого робити не потрібно.

Чому arbitrary file read може перерости у великий інцидент

Назва «читання файлів» звучить менш драматично, ніж remote code execution, але для GitLab це дуже серйозний клас проблеми. Сервер DevOps часто знаходиться в центрі ланцюга постачання: він бачить приватний код, CI/CD, deployment-конфігурацію та інтеграції з іншими системами. Доступ до чутливого локального файла може дати атакувальнику матеріал для подальшого проникнення.

Тому після патча варто мислити не лише категорією «вразливість закрита». Якщо інстанс був доступний з інтернету в період ризику, адміністратору потрібно перевірити ознаки експлуатації та вирішити, які секрети потенційно могли бути прочитані.

GitLab уже дала три detection-сценарії

У patch release GitLab окремо перелічує три threat detections для self-managed клієнтів: спробу LFI з читанням gitlab.yml, LFI через параметр metadata.path і спробу LFI з file path. Це корисна відмінність від типового advisory: адміністратор отримує не тільки номер патча, а й напрямок для hunting.

Що робити адміністратору зараз

Перше — оновитися. Залишатися на вразливій версії після появи KEV — погана ставка. Оберіть актуальний підтримуваний реліз своєї гілки, не нижче 19.1.8, 19.2.6 або 19.3.2 відповідно.

Друге — перевірити журнали й detection rules. Сам факт успішного оновлення не відповідає на питання, чи не було доступу до файлів раніше.

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

Четверте — перевірити процедуру оновлення. GitLab попереджає, що цей patch release містить database migrations. Для single-node інсталяцій можливий downtime, тоді як multi-node можна оновлювати за zero-downtime процедурою.

Чому ця CVE важлива для українського IT

GitLab широко використовується командами розробки, інтеграторами, продуктовими компаніями та внутрішніми IT-відділами. В Україні self-hosted інфраструктура додатково популярна там, де код і deployment не хочуть виносити у зовнішній SaaS. Саме такі інсталяції й потребують уваги.

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

Що ще виправили в тому самому релізі

Пакет 19.3.2/19.2.6/19.1.8 містить не одну CVE. GitLab також описує критичну CVE-2026-87719 з оцінкою 9.9 в GraphQL subscription serializer для GitLab EE, а також низку high і medium проблем. Тобто навіть якщо конкретний commits API у вашому сценарії не використовується, відкладати patch release все одно немає сенсу.