Критическая уязвимость в инфраструктуре GitHub позволяет выполнить произвольный код одной командой git push

GitHub

Исследователи компании Wiz обнаружили опасную проблему в системах управления репозиториями GitHub. Уязвимость, зарегистрированная под идентификатором CVE-2026-3854, затрагивает как облачный сервис GitHub.com, так и корпоративные установки GitHub Enterprise Server. Она позволяет любому аутентифицированному пользователю удалённо выполнять произвольные команды на внутренних серверах. Для этого достаточно отправить обычную команду git push, то есть передать изменения в репозиторий.

Уязвимость CVE-2026-3854

По данным Wiz, корень проблемы кроется в архитектуре обработки операций отправки. Внутренняя инфраструктура GitHub использует несколько сервисов, которые последовательно обрабатывают команду git push. При этом критически важные метаданные безопасности передаются через внутренний заголовок под названием X-Stat. Основной шлюз, сервис babeld, копирует управляемые пользователем параметры push-опций прямо в этот заголовок, не очищая символ точки с запятой. А именно точка с запятой в заголовке X-Stat служит разделителем полей. В результате атакующий может внедрить собственные метаданные, просто включив точку с запятой в опции push.

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

Для превращения этой инъекции в полноценное удалённое выполнение кода исследователям потребовалось объединить три конкретных внедрения полей. Во-первых, они подменили значение rails_env на нерабочее (непродуктивное), чтобы обойти изолированную среду исполнения - так называемую песочницу. Это позволило запускать пользовательские предварительные обработчики, или pre-receive hooks. Во-вторых, они внедрили собственное значение custom_hooks_dir, перенаправив базовый каталог, в котором сервер ищет скрипты-обработчики. В-третьих, они подставили определение repo_pre_receive_hooks с последовательностью обхода каталогов (path traversal), чтобы указать на произвольные выполняемые файлы в файловой системе.

После запуска код выполнялся с привилегиями внутреннего пользователя git. На GitHub Enterprise Server это приводит к полной компрометации сервера. Злоумышленник получает несанкционированный доступ ко всем размещённым репозиториям, внутренним конфигурационным данным и системным секретам. На облачной платформе GitHub.com ситуация усугубляется мультиарендной архитектурой. Успешная атака открывает широкий доступ к файловой системе общих узлов хранения, работающих от имени того же пользователя git. Теоретически это позволяет читать миллионы публичных и приватных репозиториев, принадлежащих разным организациям и пользователям, размещённым на одном узле.

Исследователи Wiz отметили, что ручной анализ огромного количества скомпилированных закрытых двоичных файлов, управляющих многокомпонентной архитектурой GitHub, крайне трудоёмок. Поэтому они применили автоматизированные инструменты обратной разработки на базе искусственного интеллекта, в частности среду IDA MCP. Это позволило систематически восстановить внутренние протоколы взаимодействия сервисов. Данный подход подчёркивает значительный сдвиг в индустрии: использование возможностей ИИ для выявления сложных межкомпонентных уязвимостей в закрытых платформах становится всё более востребованным.

GitHub оперативно устранил уязвимость на облачной платформе - в течение шести часов после получения отчёта. Для корпоративных установок ситуация иная. В средах, управляемых самими заказчиками (self-hosted), требуется немедленная установка обновлений. Атака является сетевой, не требует привилегированного доступа - достаточно права на отправку изменений в любой репозиторий. Поэтому администраторам GitHub Enterprise Server следует как можно скорее обновить систему до исправленных версий. Согласно данным Wiz, уязвимыми считаются версии 3.19.1 и более ранние. Исправления включены в релизы 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7 и 3.19.4.

Вместе с тем специалистам по безопасности стоит обратить внимание на методологию обнаружения таких проблем. Применение инструментов автоматического реверс-инжиниринга с ИИ-усилением открывает новые возможности для поиска уязвимостей, которые ранее оставались незамеченными при традиционном анализе закрытого кода. Для организаций, использующих GitHub Enterprise Server, хорошей практикой станет не только установка патчей, но и усиление мониторинга операций git push, а также внедрение дополнительных механизмов контроля за внутренними заголовками и метаданными. В облачной версии GitHub.com пользователи могут быть уверены, что платформа уже защищена, однако сам факт существования такой уязвимости напоминает о важности своевременного обновления любого инфраструктурного ПО.

Ссылки

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