Разработчики платформы управления репозиториями Gitea выпустили обновление 1.27.0, закрывающее уязвимость с максимальным рейтингом опасности CVSS 10.0. Проблема, получившая идентификатор CVE-2026-58443, позволяла API-токенам с ограничением "только публичные репозитории" изменять приватные ветки запросов на слияние и запускать встроенный CI/CD-инструмент Gitea Actions в приватных репозиториях.
Уязвимость CVE-2026-58443
Уязвимость затрагивает все версии Gitea до 1.26.4 включительно. Она относится к категории CWE-863 (некорректная авторизация) и связана с непоследовательной проверкой ограничений на API-токены. В Gitea существует тип токена, помеченный как public-only, который, по замыслу разработчиков, не должен иметь доступа к приватным репозиториям ни при каких обстоятельствах. Однако исследователи безопасности обнаружили, что проверка этого ограничения выполняется только на уровне маршрута API, а не на уровне конечного хранилища данных.
Механизм эксплуатации выглядит следующим образом. Уязвимый эндпоинт POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/update принимает запрос на обновление ветки запроса на слияние. Gitea проверяет public-only-ограничение для репозитория, указанного в URL, - то есть для публичного базового репозитория. Поскольку он публичный, токен проходит проверку. Однако в процессе обработки запроса система определяет, может ли пользователь обновлять целевую ветку, используя стандартные права доступа учётной записи, а не ограничения активного токена. Если у злоумышленника есть обычное право на запись в приватную ветку, он может использовать public-only токен для её обновления, хотя напрямую изменить файлы в том же репозитории этот токен не может.
В результате операции слияния или перебазирования коммиты из публичного базового репозитория попадают в приватную целевую ветку. Исследователи также продемонстрировали, что этот же механизм может активировать рабочие процессы Gitea Actions, настроенные на события push в приватном репозитории. В опубликованном коде подтверждения концепции указано, что после вызова уязвимого эндпоинта система создала запись о запуске Actions и задачу для приватного репозитория, хотя использовался токен с ограничением "только публичный доступ".
Возможные последствия эксплуатации выходят за рамки простого внесения изменений в приватные ветки. Запуск рабочих процессов Gitea Actions в приватном репозитории позволяет атакующему влиять на инфраструктуру непрерывной интеграции и развёртывания. В зависимости от настроек CI/CD злоумышленник может изменить процессы сборки, развёртывания или выполнить команды в доверенном окружении, например, в Docker-контейнерах.
Для успешной атаки злоумышленнику требуется несколько условий: действующий public-only токен с областью write:repository, принадлежащий пользователю, имеющему право на запись в приватную целевую ветку; доступ к публичному базовому репозиторию; а также существующий запрос на слияние между этим публичным репозиторием и приватным. Сама атака не требует взаимодействия с пользователем и выполняется по сети при низком уровне привилегий.
Разработчики Gitea в бюллетене безопасности GHSA-xxjv-752h-3vp2 классифицировали проблему как критическую. Вектор воздействия описан как CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H - атака сетевого уровня с низкой сложностью, не требующая действий жертвы, изменяющая контекст безопасности и влияющая на целостность и доступность данных.
Компаниям и организациям, использующим самоуправляемую версию Gitea, рекомендуется немедленно обновить систему до версии 1.27.0. В качестве временных мер защиты до установки патча администраторам следует пересмотреть использование public-only токенов, отозвать все ненужные токены с правом записи в репозитории, а также проверить логи активности API на предмет вызовов эндпоинта /pulls/{index}/update и необычных запусков Actions в приватных репозиториях.
Обнаружение этой уязвимости продолжает тенденцию роста внимания к проблемам авторизации и разграничения доступа в системах совместной разработки. Атаки, использующие непоследовательную проверку токенов и прав доступа, становятся всё более изощрёнными, и производителям платформ управления кодом приходится уделять особое внимание тестированию граничных случаев в логике авторизации.
Ссылки
