CVE-2026-60004 експлуатують проти серверів Gitea

CISA підтвердила експлуатацію CVE-2026-60004 у Gitea. Перевірте версії, відкриту реєстрацію, журнали diffpatch і доступні серверу секрети.

Шляхи репозиторію Gitea утворюють Git-хук, який відкриває сервер для CVE-2026-60004.

CISA додала CVE-2026-60004 до каталогу відомих експлуатованих вразливостей після підтвердження атак на критичну вразливість ін’єкції коду в Gitea. Адміністраторам Gitea версій від 1.17 до 1.27.0 слід негайно оновитися до 1.27.1 або новішої версії, зберегти журнали та перевірити облікові записи й репозиторії, створені під час доступності сервера. Вразливість перетворює звичайне право запису до репозиторію на виконання команд оболонки від імені системного користувача Gitea.

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

Кого стосується CVE-2026-60004?

Офіційний бюлетень називає вразливими версії Gitea від 1.17 до 1.27.1, не включаючи 1.27.1. Для експлуатації також потрібні Git 2.32 або новіший, увімкнений маршрут diffpatch і тимчасова файлова система з дозволом запису та виконання.[2]

СитуаціяРизик і дія
Gitea 1.17–1.27.0 та виконані умови атакиСервер уразливий. Негайно оновіться до 1.27.1 або новішого підтримуваного випуску.
Відкрита реєстрація і створення репозиторіївВідвідувач може зареєструватися, створити репозиторій і отримати потрібне для атаки право запису. Обмежте обидві можливості на час оновлення.
Реєстрацію вимкненоШлях без попереднього облікового запису закритий, але ризик від чинних авторів, викрадених облікових записів і токенів залишається.
Gitea 1.27.1 або новішаКонкретну вразливість Git-хука в diffpatch виправлено. Якщо сервер раніше був уразливим, перевірку на компрометацію все одно потрібно завершити.

CISA встановила для охоплених федеральних систем строк усунення до 28 серпня 2026 року, а використання в ransomware-кампаніях позначила як невідоме.[1] Іншим організаціям не варто сприймати цю дату як безпечний період очікування: доступний з інтернету вразливий інстанс потребує термінового оновлення та пошуку слідів атаки.

Як працює RCE через Git-хук у Gitea

Gitea застосовувала контрольовані атакувальником патчі у спільному тимчасовому bare-клоні. Подавши той самий спеціально сформований патч двічі, атакувальник міг створити конфлікт add/add і запустити трьохсторонній fallback-механізм Git. У bare-клоні корінь репозиторію одночасно є $GIT_DIR, тому виконуваний файл за шляхом hooks/post-index-change ставав активним Git-хуком, а не звичайним файлом репозиторію.

Після цього Git виконував хук під час оновлення індексу. Команда запускалася від імені сервісного користувача Gitea, а опублікований proof of concept міг повернути результат через Git-об’єкти без вихідного мережевого з’єднання. Код повернення хука не передавався у відповідь API, тому звичайна на вигляд відповідь diffpatch не доводить, що експлуатація не вдалася.

У Gitea 1.27.1 роботу з патчами змінили: тимчасовий клон більше не є bare-клоном, тому шлях усередині репозиторію не може перетворитися на активний хук у $GIT_DIR.[3]

Що адміністраторам Gitea перевірити зараз

  1. Зафіксуйте поточний стан до змін. Збережіть версію Gitea, налаштування реєстрації та створення репозиторіїв, версію Git, обліковий запис служби, активні процеси й з’єднання, а також потрібні журнали доступу та програми.
  2. Оновіться до 1.27.1 або новішої версії. Використайте актуальний підтримуваний випуск для вашого способу розгортання, протестуйте оновлення та переконайтеся, що замінено кожен вузол або контейнер.
  3. Перевірте маршрут diffpatch. Шукайте в журналах API та reverse proxy повторні запити до шляхів на кшталт /api/v1/repos/{owner}/{repo}/diffpatch, особливо пари запитів із малим інтервалом.
  4. Зіставте події облікових записів і репозиторіїв. Перевірте нові реєстрації, створені репозиторії, несподіваних авторів, використання токенів і операції з патчами з того самого джерела, облікового запису або часового проміжку.
  5. Шукайте сліди поза вебжурналами. Перевірте дочірні процеси служби Gitea, запуск оболонок, незвичний доступ до файлів, зміни репозиторіїв і читання конфігурації, бази даних, OAuth- та інтеграційних секретів. Очищення тимчасового клону могло видалити сам встановлений хук.

Якщо ви використовуєте інший self-hosted Git-сервіс, не припускайте, що ця сама вразливість стосується і його. Водночас правила посилення захисту подібні: обмежте реєстрацію, право створювати репозиторії, доступ авторів і привілеї сервісного облікового запису. Наш матеріал про RCE у Gogs та відкриту реєстрацію показує, як подібна межа дозволів перетворюється на шлях атаки на іншій платформі.

Що робити за підозри на експлуатацію

Ізолюйте уражений сервер або контейнер Gitea, не знищуючи мінливі докази. Збережіть журнали, дані про процеси, базу даних, репозиторії, конфігурацію, підключені томи та forensic-копію хоста до відновлення з довіреного образу. Не покладайтеся лише на відсутність тимчасового Git-хука: атакувальник міг виконати команди й закріпитися в іншому місці.

Після локалізації змініть секрети програми Gitea, облікові дані бази даних, OAuth- та інтеграційні ключі, deploy keys, токени доступу й усі облікові дані, доступні сервісному користувачу. Відкличте активні сесії та перевірте вміст репозиторіїв, хуки, секрети Actions, релізи, пакети й недавні адміністративні зміни. Змінюйте секрети з чистої адміністративної системи, а не з потенційно скомпрометованого сервера.

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

Джерела

  1. Cybersecurity and Infrastructure Security Agency. “CISA Adds One Known Exploited Vulnerability to Catalog.” CISA, 25 серпня 2026 року. повідомлення CISA.
  2. Gitea Project. “Remote Code Execution via diffpatch Git Hook Installation.” GitHub Security Advisory GHSA-rcr6-4jqh-j84m, опубліковано 28 липня 2026 року; дата доступу 25 серпня 2026 року. бюлетень Gitea.
  3. Gitea Project. “Gitea 1.27.1 Is Released.” Gitea Blog, 27 липня 2026 року. повідомлення про випуск Gitea.

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