В Gitea 28.3.0, опубликованной 1 ноября 2026 года, исправили ошибки, позволявшие обходить ограничения API-токенов, получать доступ к чужим учётным записям через OAuth2 и запускать автоматические задачи с секретами репозитория. Изменения затрагивают администраторов собственных Git-серверов и команды, которые используют Gitea Actions для сборки и проверки кода.
Gitea — платформа для хранения Git-репозиториев и совместной разработки, которую можно разместить на собственном сервере. В третьем обслуживающем выпуске ветки 28 разработчики сосредоточились на проверке прав доступа: в ряде случаев сервер выполнял запросы, хотя токен или пользователь должны были иметь более узкие полномочия.
API-токены с ограничением public-only больше не открывают закрытые данные
Токен Gitea позволяет программе обращаться к серверу от имени пользователя. Например, CI-система может создавать релизы или запрашивать сведения о репозитории через API. Ограничение public-only предназначено для работы только с общедоступными ресурсами, но до версии 28.3.0 некоторые маршруты API его игнорировали.
Один из наиболее серьёзных случаев, CVE-2026-117635, касался административного API. Если токен с ограничением public-only принадлежал администратору сервера, с его помощью можно было выполнять закрытые административные операции: получать адреса электронной почты пользователей, создавать администраторов и токены регистрации исполнителей Actions. Исправление заставляет эти маршруты учитывать заданное ограничение.
В другой ситуации владелец организации мог использовать аналогичный токен для удаления её репозиториев, включая приватные (CVE-2026-119441). Уязвимости в профилях и лентах активности позволяли видеть сведения о закрытых репозиториях и организациях. Отдельная ошибка в реестре OCI-пакетов допускала перенос закрытого объекта в публичный пакет при обходе ограничений токена (CVE-2026-117685).
Общая причина этих проблем заключалась в непоследовательной проверке полномочий в разных частях сервера. Для организаций, где одни и те же учётные записи управляют публичными проектами и приватным кодом, разделение прав токена определяет, какие данные доступны внешним интеграциям.
Ошибка привязки OAuth2 позволяла войти в существующий аккаунт
CVE-2026-120263 затрагивала экземпляры Gitea с открытой регистрацией и настройкой ACCOUNT_LINKING = auto. При входе через внешний OAuth2-провайдер форма привязки позволяла указать имя или адрес электронной почты уже существующей учётной записи Gitea. В результате внешняя идентификация могла оказаться связанной с чужим аккаунтом, а вход выполнялся без его пароля.
Разработчики изменили автоматическую привязку: теперь она ориентируется на имя пользователя или электронный адрес, полученные от самого внешнего провайдера. Указанные в форме чужие данные больше не должны определять, к какому локальному аккаунту подключается внешняя авторизация.
Уязвимость зависела от сочетания настроек. Для сервера, на котором не используется автоматическая привязка с открытой регистрацией, описанный сценарий не является тем же самым риском. Это различие позволяет точнее оценить, какие установки затрагивала ошибка.
В Gitea Actions исправили опасный запуск задач при проверке pull request
Gitea Actions запускает автоматические задания: тесты, сборки и публикацию пакетов. Такие задания могут получать секреты проекта, например токены для обращения к другим сервисам. Поэтому источник исполняемого workflow и права его запуска имеют значение для безопасности.
Уязвимость CVE-2026-118386 проявлялась при проверке pull request, исходная ветка которого находилась в том же репозитории. Пользователь с правом чтения мог отправить review с идентификатором собственного коммита. Gitea брала определение workflow из указанного коммита и запускала его без согласования, предоставляя секреты репозитория и токен с правом записи. В 28.3.0 задания, запускаемые событием pull_request_review, используют исходную ветку самого pull request.
Исправили и отдельную проблему служебного GITEA_TOKEN (CVE-2026-112887). До обновления токен задачи мог через GET /api/v1/user/repos получить перечень всех приватных репозиториев экземпляра Gitea. Теперь системные пользователи не считаются владельцами репозиториев, а соответствующие пользовательские маршруты API доступны только обычным аккаунтам и ботам.
Ещё одно исправление касается артефактов — файлов, которые сохраняются после выполнения задания. В старом механизме загрузки неверно обрабатывался HTTP-заголовок Content-Encoding. Из-за этого загруженный файл мог открываться в браузере как HTML на домене Gitea, создавая возможность сохранённой XSS-атаки (CVE-2026-113429).
Архивные репозитории получили более строгую защиту от изменений
Архивация репозитория обычно означает, что проект сохраняется для просмотра без дальнейшего редактирования. Однако некоторые API-запросы Gitea позволяли изменять его содержимое даже после перевода в архив.
В Gitea 28.2.0 разработчики уже ограничили редактирование, удаление и смену меток задач. Выпуск 28.3.0 расширил проверки: теперь API отклоняет изменения выпусков, меток, этапов разработки, комментариев и других данных архивных репозиториев. Ранее можно было, в частности, заменять файлы релизов и менять сроки задач (CVE-2026-116296, CVE-2026-118504).
Исправления коснулись и отображения закрытых сведений. Например, доски проектов могли показывать названия и состояние приватных pull request пользователям, у которых отсутствовало право на их чтение (CVE-2026-119533). Для команд, использующих публичные доски вместе с приватными репозиториями, это устраняет конкретный источник утечки метаданных.
Списки задач и pull request стали быстрее, а Actions экономнее использует SQLite
Помимо исправлений безопасности, разработчики оптимизировали страницы со списками задач и запросов на слияние. Скорость их загрузки улучшили за счёт исправления индексов таблиц и уменьшения повторных обращений к данным репозитория. Численных результатов тестирования в официальном анонсе нет.
Для Gitea Actions убрали лишний индекс, из-за которого SQLite при открытии некоторых страниц, включая административную очередь заданий, читала почти все строки с заданиями. Успешные проверки токенов исполнителей теперь кэшируются, а задания из репозиториев с отключёнными Actions больше не передаются исполнителям.
Среди других изменений — восстановление миграции из OneDev 16.8 и новее, использование курсорной пагинации при переносе задач из GitHub и исправление отображения различий для переименованных файлов. Всего в выпуск включили 60 объединённых запросов на изменение кода.
Обновление Gitea 28.3.0 и резервная копия сервера
Gitea распространяется в виде готовых исполняемых файлов, пакетов и контейнеров. В официальной документации порядок обновления зависит от способа установки: для Docker загружается новый образ и перезапускается контейнер с сохранёнными данными, для установки из бинарного файла заменяется исполняемый файл после остановки службы.
Перед обновлением документация предусматривает резервное копирование базы данных, конфигурации, каталога APP_DATA_PATH и внешнего хранилища, если оно используется. Копию создают при остановленном экземпляре, чтобы состояние базы и файлов репозиториев было согласованным. При первом запуске новой версии Gitea проверяет структуру базы данных и при необходимости выполняет миграции.
Есть и изменение, связанное с исходящими HTTPS-соединениями: официальные бинарные сборки Gitea 28.3.0 созданы с использованием Go 1.27.3. В этой версии изменено доверие к некоторым промежуточным сертификатам, что относится к проверке подключений Gitea к OAuth2-провайдерам, webhook-адресам и удалённым источникам миграции.
Gitea 28.3.0 меняет границы доступа к репозиториям и автоматизации
Третий обслуживающий выпуск ветки 28 охватывает сразу несколько независимых механизмов авторизации: пользовательские API-токены, вход через внешний OAuth2-провайдер и служебные полномочия Actions. Для каждого из них разработчики описали конкретные условия возникновения ошибок и внесённые ограничения.
Проверки прав теперь охватывают дополнительные API-маршруты, а архивные репозитории защищены от большего числа операций изменения. Одновременно исправления индексов и запросов к базе данных затрагивают повседневную работу со списками задач и очередями автоматических заданий.
