Неправильный контроль доступа в Gitea позволяет повысить привилегии без учётной записи

vulnerability

В системе управления Git-репозиториями Gitea есть уязвимость, которая позволяет удалённому злоумышленнику повысить привилегии. Затронуты все выпуски продукта до версии 1.27.0, а также операционные системы РЕД ОС 7.3 и 8.0, в состав которых входит этот сервер. Сведения об уязвимости внесены в Банк данных угроз безопасности информации (BDU) под номером BDU:2026-15763 (CVE-2026-56654). Оценка по CVSS 3.1 составляет 9,8, по CVSS 2.0 - ровно 9. Рабочий эксплойт уже доступен публично.

Детали уязвимости

Проблема сосредоточена в двух участках серверного кода. Первый отвечает за выдачу токена доступа - ключа, который клиент предъявляет вместо пароля при обращении к программному интерфейсу (API, набор функций для обмена данными между программами). Второй проверяет подлинность запросов, приходящих напрямую или через обратный прокси, то есть промежуточный сервер, который принимает соединения и передаёт их дальше. В обоих случаях логика проверки прав оказалась неполной. Класс ошибки разработчики описали как неправильный контроль доступа (CWE-284). Так обозначают ситуации, когда система неверно решает, кому и что разрешено. Формально это уязвимость архитектуры, а не единичная опечатка в коде. Способ эксплуатации производитель классифицировал как нарушение авторизации.

Две системы оценки описывают ситуацию по-разному, и этот разрыв сам по себе показателен. Вектор CVSS 3.1 исходит из того, что злоумышленнику не нужны ни учётная запись, ни действия пользователя. Оценка по CVSS 2.0, напротив, предполагает, что атакующий уже прошёл проверку подлинности и лишь расширяет свои полномочия. Практический вывод один. В худшем сценарии достаточно одного сетевого запроса к серверу. Уязвимость подтверждена производителем и признана устранённой в новых версиях продукта.

Gitea - решение для самостоятельного размещения Git-репозиториев. Организация разворачивает его на собственных серверах и хранит там исходный код, конфигурации и служебные учётные данные. Поэтому расширение прав внутри такого сервиса почти всегда означает доступ к чужим проектам. Вместе с ними под удар попадают ключи доступа, пароли к внешним системам, прописанные в файлах проекта, и конвейеры автоматической сборки. У последних часто широкие права на развёртывание. Через них злоумышленник способен продвинуться дальше по инфраструктуре компании. Для заказчика это не отвлечённый риск, а путь к атаке на цепочку поставок, когда вредоносный код попадает в готовый продукт через доверенные инструменты и подрядчиков.

Публикация эксплойта меняет приоритеты служб защиты. Пока рабочий код доступен любому желающему, окно между раскрытием сведений об уязвимости и первыми попытками её использовать сжимается до нескольких часов. Отдельный аспект - российский сегмент. РЕД ОС включена в единый реестр отечественного программного обеспечения, а уязвимость затрагивает её поставки. Значит, обновлять придётся не только сам Git-сервер, но и операционную систему на машинах разработчиков и на сборочных узлах. В крупных организациях такие системы живут годами без внимания администраторов. Именно поэтому ошибка в проверке прав в них даёт долгий и незаметный доступ.

Исправление содержится в версии 1.27.0. Разработчики переписали обе процедуры проверки. Владельцам самостоятельных установок достаточно обновить сервер до актуального выпуска. Пользователям РЕД ОС нужно поставить пакеты из штатных репозиториев обновлений для веток 7.3 и 8.0. После установки стоит просмотреть список действующих токенов. Если в журналах видны обращения с незнакомых адресов или выдача ключей неизвестным клиентам, токены лучше отозвать и выпустить заново. То же касается служебных учётных записей автоматизации.

Там, где обновление откладывают, разумно минимизировать поверхность атаки. Помогает ограничение доступа к веб-интерфейсу по спискам разрешённых адресов, отключение неиспользуемых способов входа и разделение прав отдельных учётных записей. Эти меры не устраняют уязвимость, однако снижают вероятность успешной эксплуатации. Полезно проверить и объём полномочий у токенов автоматизации. Избыточные права служебных ключей увеличивают ущерб при любой ошибке авторизации. Отдельного внимания заслуживает сегментация сети. Если сервер с репозиториями доступен только из внутреннего контура, внешний злоумышленник теряет возможность добраться до него напрямую.

Логические ошибки доступа плохо выявляются автоматическими сканерами. Они не приводят к падению процесса, не оставляют следов в виде повреждённой памяти и не проявляются при обычной работе сервиса. Проверка прав просто отвечает "да" там, где должна ответить "нет". Из-за этого такие уязвимости живут в продуктах дольше, чем ошибки работы с памятью. Добавляет сложности и то, что похожие дефекты часто встречаются в цепочке обработки запросов, где взаимодействуют несколько компонентов. Промежуточный сервер, приложение и система выдачи ключей по очереди принимают решения о доступе. Достаточно одного неверного звена, чтобы вся схема перестала защищать данные.

Git-серверы давно перестали быть вспомогательным инструментом для узкого круга программистов. Сегодня это узлы, через которые проходят код, сборки, ключи и секреты, а потому ошибка в проверке прав обходится дороже, чем кажется при первом чтении бюллетеня. Оценка 9,8 по CVSS 3.1 и открытый эксплойт делают промедление с обновлением неоправданным. Проверить версию установленного Gitea и актуальность пакетов РЕД ОС стоит в первые же дни после выхода исправления. Если такая проверка станет регулярной, часть подобных проблем будет закрываться до того, как эксплойт окажется в открытом доступе.

Ссылки

Комментарии: 0