Почему Docker-образ Gitea сам открывал дверь любому пользователю интернета?

Уязвимость получила номер CVE-2026-20896 и оценку 9.8 по шкале CVSS — почти максимум из возможных десяти баллов. Дело не в сложном эксплойте и не в цепочке из нескольких багов. Проблема сидела в конфигурационном файле, который разработчики сами же зашили в официальный Docker-образ Gitea.
Почему Docker-образ Gitea сам открывал дверь любому пользователю интернета?
Изображение носит иллюстративный характер

Суть в следующем. Gitea поддерживает работу через реверс-прокси с аутентификацией — то есть сервер доверяет заголовку X-WEBAUTH-USER, который прокси подставляет после проверки логина пользователя. Идея нормальная, так работают многие корпоративные системы. Но чтобы это работало безопасно, Gitea должен доверять этому заголовку только если он пришёл от самого прокси, а не откуда угодно. За это отвечает параметр REVERSE_PROXY_TRUSTED_PROXIES в файле app.ini. Документация советует ставить туда 127.0.0.0/8,::1/128 — то есть доверять только localhost, откуда и должен приходить трафик от прокси, стоящего на том же хосте.
А теперь ключевой момент: в официальном Docker-образе Gitea этот параметр был захардкожен как звёздочка — REVERSE_PROXY_TRUSTED_PROXIES =. Звёздочка означает «доверяй всем». Вся проверка источника запроса превращалась в фикцию.
Чтобы уязвимость сработала, администратору достаточно было включить ENABLE_REVERSE_PROXY_AUTHENTICATION = true — стандартный шаг при настройке Gitea за прокси — и не трогать значение trusted proxies, оставив его на дефолтном (то есть уязвимом) уровне. После этого любой, кто мог достучаться до HTTP-порта контейнера напрямую, минуя сам прокси, получал возможность подделать заголовок X-WEBAUTH-USER и войти под любым существующим логином. Без пароля. Без токена. Достаточно было угадать или узнать имя учётной записи — а для админских аккаунтов это обычно не бином Ньютона: admin, gitea_admin и тому подобные варианты перебираются за секунды. Если на сервере вдобавок включена автоматическая регистрация пользователей, атакующий мог создать себе учётку с именем администратора и получить полные права мгновенно.
Уязвимость нашёл исследователь Али Мустафа, известный под ником rz1027. Он же передал технические детали журналистам The Hacker News по электронной почте, разложив по полочкам механизм атаки. Пострадали все версии Gitea Docker вплоть до 1.26.2 включительно. Исправление вышло в версии 1.26.3 в конце прошлого месяца — разработчики убрали хардкод звёздочки и сделали аутентификацию через реверс-прокси действием, которое нужно явно и осознанно включать, а не тем, что работает «из коробки» с опасными настройками.
Компания Sysdig, занимающаяся облачной безопасностью, зафиксировала первую попытку эксплуатации этой уязвимости в реальных условиях всего через 13 дней после публичного раскрытия информации. Для критической уязвимости с CVSS 9.8 это довольно быстро — злоумышленники мониторят такие публикации и проверяют доступные цели почти сразу.
По оценке Sysdig, в интернете открыто около 6200 инстансов Gitea, потенциально уязвимых к такой атаке. Первое действие атакующего было прослежено до IP-адреса 159.26.98.241, принадлежащего сервису ProtonVPN — типичный способ спрятать реальное происхождение трафика.
Майкл Кларк, старший директор по исследованию угроз в Sysdig, прокомментировал зафиксированную активность так: пока она ограничивается разведкой и первичным зондированием, атака не переросла в полноценную эксплуатацию с захватом системы. По мнению команды Sysdig, ранее обнаружение попытки, вероятно, застало злоумышленника на самой начальной стадии, не дав кампании развиться дальше.
Тем не менее ситуация остаётся напряжённой ровно до тех пор, пока администраторы не обновятся до версии 1.26.3. Учитывая критичность оценки и уже зафиксированные попытки сканирования, откладывать патч не стоит — разница между разведкой и реальным взломом административной панели может составить всего несколько дней, как показала практика с этим самым CVE.


Новое на сайте

20327Кости прерий: как истребление бизонов породило целую индустрию — и сама себя же уничтожила 20326Кто и зачем взламывает серверы Ollama и ComfyUI ради ключей от AWS? 20325Как злоумышленники спрятали командный сервер внутри блокчейна и почему его невозможно... 20324Брюссель заставляет Android делиться секретами с чужими ИИ-помощниками 20323WordPress: как два бага слились в одну критическую дыру, которую назвали wp2shell 20322Как китайские хакеры обманули DigiCert и украли сертификаты для подписи кода? 20321Что скрывается за уязвимостью, которую агентство США внесло в список активно используемых... 20320Автономные системы наступают быстрее, чем инфраструктура для управления ими: кто выиграет... 20319Почему в OpenSSL нашли дыру, съедающую память серверов, но не дали ей даже номер CVE? 20317SonicWall SMA 1000: как два бага превратили VPN-шлюз в бэкдор для атакующих 20316Может ли уязвимость в клиенте Zoom для Windows открыть доступ к чужому аккаунту без... 20315TELEPUZ: новый вредонос на C, который научился прятаться в Telegram, Steam и блокчейне... 20314Дома из дёрна: как исландцы триста лет прятались от холода под слоем земли и травы 20313Как один токен от чужого сервиса мог впустить злоумышленника в чужой аккаунт n8n?
Ссылка