Критическая уязвимость Gitea в официальном Docker-образе уже ушла в реальные атаки: злоумышленник может выдать себя за любого пользователя, включая администратора, если инстанс поднят с дефолтной конфигурацией. Для команд, которые держат свой Git-сервер внутри компании или публикуют его наружу, это неприятный сценарий без лишней драмы: пароль не нужен, токен не нужен, достаточно правильно подставить один HTTP-заголовок.
О проблеме CVE-2026-20896 сообщает BleepingComputer. Речь идет о self-hosted Git-сервисе Gitea и его официальных Docker-образах до версии 1.26.2 включительно. По данным издания, сейчас в публичном интернете видно около 6200 инстансов Gitea, хотя точное число реально уязвимых систем неизвестно.
Суть бага в том, что официальный Docker-образ поставлялся с настройкой REVERSE_PROXY_TRUSTED_PROXIES=*. Если у развертывания включена аутентификация через reverse proxy, Gitea начинает доверять заголовкам вроде X-WEBAUTH-USER от любого источника, а не только от доверенного прокси. На практике это означает простой и неприятный трюк: любой клиент, который может достучаться до HTTP-порта контейнера напрямую, способен назвать себя нужным логином и войти от чужого имени. В первую очередь под ударом очевидные учетные записи вроде admin или gitea_admin, но логика работает не только для них.
Проблему подтвердил Майкл Кларк, ведущий исследователь безопасности в Sysdig. Его команда зафиксировала эксплуатацию уязвимости вживую: по словам Кларка, сенсоры Sysdig увидели первый инцидент через 13 дней после выхода advisory. Он описал схему почти издевательски коротко: ни пароля, ни токена, только один заголовок. В нормальной инфраструктуре такие заголовки действительно могут использоваться для проброса уже проверенной идентичности пользователя от внешнего прокси до приложения. Но здесь доверие оказалось слишком широким, и ровно это превратило механизм удобной интеграции в дверь без замка.
Почему история неприятнее, чем кажется
Gitea часто выбирают команды, которым нужен свой GitHub без лишнего веса: open source, self-hosted, понятная модель развёртывания, pull request'ы, CI/CD, хранение исходников и рабочая коллаборация в одном месте. То есть это не просто еще один веб-интерфейс, который можно ненадолго выключить и отложить разбор до понедельника. Если атакующий получает доступ под админом или под аккаунтом разработчика, дальше он уже работает в ядре инженерного контура: может читать приватные репозитории, вмешиваться в процесс ревью, подменять код, трогать пайплайны и, в плохом сценарии, разворачивать supply chain-инцидент не на одном сервере, а по всей цепочке сборки.
Здесь особенно важна одна деталь: баг касается не экзотической сборки и не редкой комбинации опций, а дефолтной конфигурации официального Docker-образа. Для DevOps-команд это всегда красный флаг. Мы слишком привыкли считать официальный образ безопасной отправной точкой, а дефолтные параметры — чем-то вроде «разумного минимума». История с уязвимостью Gitea напоминает старое правило: официальный не значит безопасный, а параметр по умолчанию не обязан совпадать с тем, что вы бы подписали после нормального security review.
Отдельный неприятный слой — архитектурный. Во многих компаниях Gitea действительно ставят за reverse proxy, но при этом контейнер, сервис или внутренний HTTP-порт остаются достижимыми из соседних сегментов сети, VPN или сервисной подсети. Снаружи все может выглядеть аккуратно: TLS, прокси, SSO, корпоративный доступ. А внутри остается короткий путь к контейнеру в обход точки, которая вообще-то и должна была проверять пользователя. В такой схеме баг уже не выглядит как узкий edge case: он упирается в типичный разрыв между «как это задумывалось» и «как оно реально доступно в инфраструктуре».
Что делать администраторам и командам
Разработчики Gitea выпустили версии 1.26.3 и 1.26.4, которые закрывают CVE-2026-20896, причем пользователям рекомендовали обновляться сразу до самой свежей версии. Причина практическая: в 1.26.4 исправлен не только этот баг, но и дополнительная проблема, а также регрессия, появившаяся в 1.26.3. Для production-команд это означает вполне прямой маршрут: не пытаться выбирать «минимально достаточный» патч по памяти, а проверять актуальный безопасный релиз и поднимать его как можно быстрее.
Предупреждение выпустило и киберагентство Сингапура — CSA. Если моментально обновиться нельзя, регулятор советует убрать звездочку из REVERSE_PROXY_TRUSTED_PROXIES и ограничить список конкретными доверенными IP-адресами. Параллельно имеет смысл просмотреть access logs на предмет подозрительной активности. И здесь как раз не стоит успокаивать себя формулой «если бы нас ломали, мы бы заметили». В историях с подменой identity-заголовков следы могут выглядеть как вполне легитимные логины под известными пользователями, особенно если команда не привыкла анализировать источник запроса, сетевой маршрут и контекст входа.
Для русскоязычной IT-аудитории вывод неприятный, но полезный. Если у вас Gitea живет в Docker и до него можно достучаться напрямую, проверка должна быть не «обновились ли мы вообще», а «обновились ли мы на безопасную версию, закрыт ли обход прокси и кто уже успел походить по инстансу». Отдельно стоит проверить сервисные аккаунты, административные логины, историю действий в репозиториях и изменения в CI/CD-настройках. Когда уязвимость работает через подмену личности, ущерб часто начинается не с падения сервиса, а с тихих изменений в коде и инфраструктуре.
История с Gitea хорошо показывает, как меняется профиль риска у developer tooling: атакуют уже не только VPN, почту и внешние веб-приложения, но и инженерные платформы, от которых зависит выпуск продукта. И чем сильнее компании собирают разработку, деплой и доступы в один контур, тем дороже обходится любая ошибка в доверии между прокси, контейнером и приложением.