Критическую ошибку в Gitea Docker успели начать проверять злоумышленники уже через 13 дней после раскрытия. Речь идет о CVE-2026-20896 с оценкой 9,8: контейнер мог поверить подставному HTTP-заголовку X-WEBAUTH-USER и пустить постороннего в систему без пароля.

Sysdig сообщила, что видела первые попытки эксплуатации в дикой среде. По данным компании, атакующие пока не прошли дальше разведки, но сам факт такой скорости показывает: уязвимости в DevOps-инструментах живут не в вакууме, а в боевой инфраструктуре.

История инцидента

Проблему нашли в Docker-образах Gitea — платформы для кода и командной работы. Суть ошибки проста и неприятна: образ по умолчанию доверял всем источникам, потому что в шаблоне app.ini жестко прописали REVERSE_PROXY_TRUSTED_PROXIES = *.

В нормальной конфигурации доверять нужно только локальному прокси, а не любому узлу, который достучался до порта контейнера. Но здесь проверка превращалась в формальность: если администратор включал авторизацию через reverse proxy, приложение принимало X-WEBAUTH-USER откуда угодно и считало пользователя авторизованным.

Исследователь Али Мустафа, которому приписывают обнаружение бага, прямо описал риск: при включенной авто-регистрации учетная запись с именем администратора могла сразу получить админские права. Для атакующего это короткий путь к исходникам, секретам и внутренним настройкам.

Что пошло не так в защите

Главная ошибка — избыточное доверие по умолчанию. Вместо строгого allowlist для прокси разработчики фактически оставили дыру открытой для любого источника, который видел HTTP-порт контейнера.

Такой промах опасен именно в Docker-среде. Контейнер часто считают изолированным, но в реальности его нередко публикуют в сеть, ставят за балансировщик или поднимают рядом с сервисами, где один неверный флаг ломает всю схему доверия.

Проблема усугублялась тем, что безопасное значение переменной было известно заранее: 127.0.0.0/8,::1/128. То есть локальный контур уже был описан, но официальный образ выбрал * и обнулил смысл фильтра.

Для команд, которые строят инфраструктуру вокруг кодовых репозиториев, это хороший повод пересмотреть не только настройки, но и саму привычку верить шаблонам из образов. В роадмапе по информационной безопасности мы уже показывали, почему базовая проверка конфигов часто важнее громких защитных обещаний.

Уроки для читателя

Первый вывод — не путать «доступно изнутри» с «безопасно по умолчанию». Если сервис принимает заголовок, который влияет на авторизацию, список доверенных источников должен быть минимальным и понятным.

Второй вывод — контейнер надо проверять так же тщательно, как обычный сервер. Образ с Docker Hub или из внутреннего реестра не становится надежным только потому, что он «официальный» или «последний».

Третий вывод — отдельное внимание стоит уделять секретам и правам админа. Как мы уже разбирали в материале про хранение секретов в конфигурациях, утечка одного параметра нередко тянет за собой полный захват среды.

Еще один важный момент — публично доступные сервисы привлекают внимание очень быстро. Уязвимость успели заметить и проверить почти сразу после раскрытия, а значит, окно для реакции у администраторов короткое.

Практические выводы и чек-лист

Владельцам Gitea нужно обновиться до версии 1.26.3 или новее: именно там убрали опасный wildcard и сделали reverse-proxy-аутентификацию опциональной. Если вы держите репозиторий в контейнере, проверьте не только версию, но и реальную схему доступа к порту.

Для обычных пользователей этот кейс — напоминание о цифровой гигиене: пароли, 2FA, контроль доступа к устройствам и осторожность с публичными сетями. Если вы часто подключаетесь через общие точки доступа, уместно добавить защиту трафика на выезде как один из инструментов вместе с менеджером паролей и двухфакторной защитой.

  • Проверьте версию Gitea и обновите Docker-образ до 1.26.3 или новее.
  • Убедитесь, что REVERSE_PROXY_TRUSTED_PROXIES не стоит в значении *.
  • Ограничьте доступ к HTTP-порту контейнера только нужной сети или прокси.
  • Отключите авто-регистрацию, если она не нужна бизнесу.
  • Проверьте, не может ли внешний узел достучаться до Gitea напрямую.
  • Пересмотрите права администраторов и список учетных записей с привилегиями.
  • Используйте 2FA для всех критичных аккаунтов.
  • Регулярно ревизуйте конфиги контейнеров и шаблоны образов.
Поделиться: