Gitea усунула критичну вразливість віддаленого виконання коду (CVE-2026-60004, CVSS 9.8), яка дає змогу користувачу з правами запису до репозиторію впровадити виконуваний Git-хук через API-ендпоінт diffpatch і виконати довільні команди від імені сервісного облікового запису Gitea. Вразливість впливає на всі версії починаючи з 1.17 до 1.27.1. Виправлення доступне у версії 1.27.1. Публічний код експлойта (PoC) уже доступний, хоча на момент публікації підтверджених випадків експлуатації в реальних атаках не зафіксовано. Усі адміністратори self-hosted інсталяцій Gitea мають оновитися негайно.
Механізм експлуатації
Уразливий ендпоінт POST /api/v1/repos/{owner}/{repo}/diffpatch застосовує користувацький патч всередині спільного bare тимчасового клону репозиторію. Згідно з офіційним advisory Gitea, уразливі збірки викликають git apply з прапорцями --index, --recount, --cached і --binary. За наявності Git версії 2.32 і вище додатково активується прапорець -3 (three-way merge fallback).
Атака будується на такому ланцюжку:
- Зловмисник надсилає один і той самий патч двічі, створюючи колізію типу add/add.
- Механізм three-way fallback витягує проіндексований шлях у робоче дерево, попри використання
--cached. - Оскільки тимчасовий клон є bare-репозиторієм, його коренева директорія збігається з
$GIT_DIR. Виконуваний файл, розміщений за шляхомhooks/post-index-change, потрапляє безпосередньо до директорії хуків Git. - Git автоматично виконує хук
post-index-changeпід час оновлення індексу — зловмисник отримує виконання довільного коду.
PoC демонструє повний цикл атаки без необхідності зворотного з’єднання: хук зберігає вивід команд у Git-об’єкти, створює гілку з результатом, і зловмисник забирає дані через автентифікований Smart HTTP.
Умови експлуатації та поверхня атаки
Формально ендпоінт вимагає автентифікації та прав запису до репозиторію — маршрут викликає reqToken(), який відхиляє неавторизовані запити. Однак конфігурація Gitea за замовчуванням залишає реєстрацію відкритою, не вимагає підтвердження email чи ручного затвердження, не позначає нових користувачів як обмежених і не встановлює ліміт на створення репозиторіїв. На незмінений інсталяції зовнішній відвідувач може самостійно зареєструватися, створити репозиторій і отримати необхідні права запису.
Повний набір умов для експлуатації:
- Права запису до репозиторію (досяжні через відкриту реєстрацію)
- Git версії 2.32 або вище на сервері
- Увімкнений маршрут
diffpatch - Тимчасова файлова система з можливістю запису та виконання
Наслідки компрометації
Успішна експлуатація надає зловмиснику привілеї облікового запису операційної системи, під яким працює Gitea. Згідно з advisory, залежно від ступеня ізоляції інстансу це може призвести до розкриття:
- Секретів застосунку та змінних оточення
- Змонтованих репозиторіїв
- Облікових даних і вмісту бази даних
- OAuth-токенів
- Доступних внутрішніх сервісів у мережі
З огляду на те, що Gitea часто розгортається як центральний вузол для зберігання вихідного коду організації, компрометація інстансу може стати точкою входу для атак на ланцюжок постачання.
Особливості розкриття та виправлення
Хронологія подій заслуговує на окрему увагу. Виправлення було змерджене та бекпортоване 26 липня 2026 року. Версія 1.27.1 вийшла 27 липня, а security advisory опубліковано 28 липня. При цьому у release notes виправлення вказане в розділі MISC як «refactor: git patch apply», а не в розділі SECURITY. Така розмітка може призвести до того, що адміністратори, які відстежують лише security-фікси, пропустять критичне оновлення.
Суть виправлення — зміна типу тимчасового клону з bare на non-bare. Коментар у коді коміта прямо попереджає, що команди Git з прапорцем --index можуть оперувати робочим деревом. У non-bare клоне коренева директорія більше не збігається з $GIT_DIR, що розриває ланцюжок впровадження хука.
Вразливість виявлена дослідником безпеки Shai Rod (NightRang3r), який вказаний як автор знахідки в advisory Gitea. Окрім RCE, у версії 1.27.1 також усунуто проблему включення файлів у рендері Org-mode: директиви #+INCLUDE тепер повертаються як звичайний текст замість читання файлів із файлової системи сервера. Окремий advisory чи CVE для цієї проблеми Gitea не публікувала.
Рекомендації
- Негайно оновіть усі self-hosted інсталяції Gitea до версії 1.27.1. За даними Gitea, хмарні інстанси Gitea Cloud оновлюються автоматично.
- Вимкніть відкриту реєстрацію як тимчасовий захід на період оновлення. Це усуває шлях атаки для зовнішніх неавтентифікованих користувачів, але не захищає від наявних користувачів із правами запису.
- Перевірте версію Git на сервері: експлуатація потребує Git 2.32+. Якщо з якихось причин оновлення Gitea неможливе негайно, пониження версії Git нижче 2.32 може слугувати тимчасовим обхідним рішенням (з урахуванням можливих побічних ефектів).
- Проведіть аудит логів на предмет підозрілих викликів ендпоінта
/api/v1/repos/{owner}/{repo}/diffpatch, особливо повторних запитів з ідентичним вмістом патча. - Перевірте ізоляцію сервісного облікового запису Gitea: обмежте доступ до секретів, баз даних і внутрішніх сервісів за принципом мінімальних привілеїв.
Поєднання CVSS 9.8, публічного PoC, відкритої реєстрації за замовчуванням і неочевидної розмітки виправлення у changelog робить CVE-2026-60004 однією з найнебезпечніших вразливостей в екосистемі self-hosted Git-платформ останнім часом. Єдина надійна дія — оновлення до Gitea 1.27.1 з подальшим переглядом конфігурації реєстрації та ізоляції інстансу. Запис у NVD підтверджує критичний рівень серйозності вразливості.
