Критическая уязвимость Gitea: чтение файлов сервера через Org-разметку без входа

· Безопасность
В версиях Gitea с 1.22.1 по 1.27.0 неавторизованный злоумышленник мог прочитать любой файл, доступный служебной учётной записи. Достаточно публичного репозитория и особым образом составленной Org-разметки.

cover.svg

Разработчики самостоятельно размещаемой Git-платформы Gitea устранили критическую уязвимость, позволявшую читать произвольные файлы на сервере без какой-либо аутентификации. Ошибка получила идентификатор CVE-2026-59774 и максимально высокий по меркам такого класса рейтинг CVSS — 9.8. Официальный бюллетень вышел 2 августа, исправление доступно в версии 1.27.1.

Уязвимости подвержены сборки с 1.22.1 по 1.27.0. Для атаки не требуется ни учётная запись, ни право записи в репозиторий — хватает одного публичного репозитория с включённым разделом кода и специально сформированной разметки в формате Org-mode.

Где сломалось

Путь чтения файлов проходит через конечную точку рендеринга разметки POST /{owner}/{repo}/markup. Маршрут допускает необязательный вход и проверяет доступ на чтение — но анонимный запрос успешно проходит эту проверку для любого публичного репозитория. Instance без публичных репозиториев анонимной атаке через эту точку не подвержен.

Суть проблемы — в обработчике Org-mode. В Gitea 1.27.0 библиотека go-org инициализировалась вызовом org.New(), при этом стандартный обработчик чтения файлов (ioutil.ReadFile в go-org 1.9.1) не переопределялся. Директива Org-mode #+INCLUDE принимает абсолютные пути и передаёт их этому обработчику. Злоумышленнику достаточно отправить разметку с режимом Mode: file — и в ответ он получает содержимое файлов, доступных служебной учётной записи. Патч (PR #38642, бэкпорт в #38645) теперь возвращает путь включения как обычный текст, а не читает его с файловой системы.

От чтения файла к выполнению команд

Сам по себе баг не даёт удалённого выполнения кода в один запрос. Однако, по данным бюллетеня Gitea, цепочку можно достроить: прочитать app.ini, извлечь INTERNAL_TOKEN, через внутренний логгер внедрить Git-хук и запустить его во время анонимного клонирования. Издание The Hacker News отмечает, что независимо опубликованного эксплойта, демонстрирующего эту цепочку, найти не удалось — сценарий пока подтверждается только самим вендором.

Что делать администраторам

Cloud-инстансы Gitea обновляются автоматически, а владельцам локальных установок настоятельно рекомендуется немедленно перейти на 1.27.1. Одного обновления может оказаться недостаточно: если в логах виден вызов конечной точки разметки на уязвимой сборке, все данные, доступные служебной учётной записи, следует считать скомпрометированными и сменить внутренний токен, материалы OAuth и JWT, а также учётные данные базы данных. Стоит также проверить каталоги хуков репозиториев на посторонние исполняемые файлы.

Уязвимость обнаружила автономная система наступательной безопасности XBOW Security; ту же проблему независимо сообщил исследователь под ником NightRang3r. Случаев эксплуатации в дикой природе на 5 августа не зафиксировано, в каталоге CISA KEV запись не значилась. Это уже не первая критическая брешь в Gitea за последние месяцы: в июне была закрыта ошибка обхода аутентификации через reverse-proxy, а в мае — проблема контроля доступа в реестре контейнеров.


Источник: The Hacker News

Комментарии

Войдите, чтобы комментировать.

  • Пока нет комментариев.