Исследователи из компании Wiz, принадлежащей Google, обнаружили критическую уязвимость в инфраструктуре GitHub, которой присвоен идентификатор CVE-2026-3854 с оценкой по шкале CVSS 8.7. Суть проблемы проста до неловкости: обычная команда
Уязвимость нашёл исследователь безопасности Сажи Цадик 4 марта 2026 года. GitHub получил отчёт и задеплоил исправление на в течение двух часов — это, пожалуй, один из самых быстрых патчей для уязвимости такого масштаба. При публичном раскрытии информации около 88% инстансов по-прежнему оставались уязвимыми. Данных о реальной эксплуатации в дикой природе нет, но это скорее удача, чем закономерность.
Техническая причина кроется в обработке параметров
Цепочка эксплойта, по словам самих исследователей из Wiz, оказалась «поразительно простой» и состояла из трёх последовательных инъекций. Первая — подмена значения
Отдельного внимания заслуживает то, как эту же цепочку удалось применить к , где хуки по умолчанию отключены флагом enterprise mode со значением «false». Проблема в том, что сам этот флаг передаётся через тот же уязвимый заголовок
Результат выполнения такого кода — полный контроль над инстансом GHES: несандбоксированное выполнение команд от имени
GitHub использует мультитенантную архитектуру с общей бэкенд-инфраструктурой. Выполнение кода на одном узле открывало доступ к общим хранилищам, где лежат репозитории совершенно разных организаций и пользователей. Миллионы репозиториев — без каких-либо организационных или пользовательских границ. Один взломанный узел, и вся логика изоляции тенантов становится бесполезной.
Алексис Уэлс, директор по информационной безопасности GitHub, подтвердила уязвимость. Затронутые платформы: , GitHub Enterprise Cloud, GitHub Enterprise Cloud with Data Residency, GitHub Enterprise Cloud with Enterprise Managed Users и GitHub Enterprise Server. Для последнего выпущены патчи — пользователи должны обновиться до версий 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4 или 3.20.0.
Wiz описали системную проблему, которая стоит за этой уязвимостью: «Когда несколько сервисов, написанных на разных языках, передают данные через общий внутренний протокол, допущения каждого сервиса относительно этих данных становятся критической поверхностью атаки». Иными словами, каждый сервис в цепочке молча предполагает, что данные уже провалидированы кем-то другим — и именно в этих промежутках живут подобные баги.
Командам, строящим мультисервисные архитектуры, стоит заново пройтись по тому, как пользовательский ввод движется через внутренние протоколы. Особенно там, где безопасность-критичные конфигурации опираются на общие форматы данных с символами-разделителями — запятыми, точками с запятой, амперсандами. Это не новая класса уязвимостей, но случай с GitHub наглядно показывает, какой может быть цена неправильных предположений о доверенности данных внутри собственной инфраструктуры.
git push с заранее подготовленными параметрами позволяла аутентифицированному пользователю выполнить произвольный код на сервере. Никакого специального доступа, никаких эксплойтов нулевого дня — достаточно было иметь права на запись в любой репозиторий. Изображение носит иллюстративный характер
Уязвимость нашёл исследователь безопасности Сажи Цадик 4 марта 2026 года. GitHub получил отчёт и задеплоил исправление на в течение двух часов — это, пожалуй, один из самых быстрых патчей для уязвимости такого масштаба. При публичном раскрытии информации около 88% инстансов по-прежнему оставались уязвимыми. Данных о реальной эксплуатации в дикой природе нет, но это скорее удача, чем закономерность.
Техническая причина кроется в обработке параметров
git push во внутренней сервисной инфраструктуре GitHub. Пользовательские опции перед передачей в заголовок X-Stat внутренних запросов не проходили нормальную санитизацию. Формат этого заголовка использует точку с запятой как разделитель полей метаданных — и этого оказалось достаточно. Подставив точку с запятой в строку параметров, атакующий мог дописать произвольные поля в заголовок и изменить поведение внутренних сервисов. Цепочка эксплойта, по словам самих исследователей из Wiz, оказалась «поразительно простой» и состояла из трёх последовательных инъекций. Первая — подмена значения
rails_env на нестандартное, что отключало sandbox-защиту. Вторая — инъекция custom_hooks_dir для перенаправления директории хуков под контроль атакующего. Третья — подстановка repo_pre_receive_hooks с crafted-записью, которая через path traversal запускала произвольные команды от имени пользователя git. Отдельного внимания заслуживает то, как эту же цепочку удалось применить к , где хуки по умолчанию отключены флагом enterprise mode со значением «false». Проблема в том, что сам этот флаг передаётся через тот же уязвимый заголовок
X-Stat. Атакующий просто добавлял в инъекцию переключение флага на «true» — и вся конструкция работала точно так же, как на корпоративном сервере. Результат выполнения такого кода — полный контроль над инстансом GHES: несандбоксированное выполнение команд от имени
git, чтение и запись на файловой системе, доступ к конфигурациям внутренних сервисов. Это плохо. Но самое опасное в этой истории — другое. GitHub использует мультитенантную архитектуру с общей бэкенд-инфраструктурой. Выполнение кода на одном узле открывало доступ к общим хранилищам, где лежат репозитории совершенно разных организаций и пользователей. Миллионы репозиториев — без каких-либо организационных или пользовательских границ. Один взломанный узел, и вся логика изоляции тенантов становится бесполезной.
Алексис Уэлс, директор по информационной безопасности GitHub, подтвердила уязвимость. Затронутые платформы: , GitHub Enterprise Cloud, GitHub Enterprise Cloud with Data Residency, GitHub Enterprise Cloud with Enterprise Managed Users и GitHub Enterprise Server. Для последнего выпущены патчи — пользователи должны обновиться до версий 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4 или 3.20.0.
Wiz описали системную проблему, которая стоит за этой уязвимостью: «Когда несколько сервисов, написанных на разных языках, передают данные через общий внутренний протокол, допущения каждого сервиса относительно этих данных становятся критической поверхностью атаки». Иными словами, каждый сервис в цепочке молча предполагает, что данные уже провалидированы кем-то другим — и именно в этих промежутках живут подобные баги.
Командам, строящим мультисервисные архитектуры, стоит заново пройтись по тому, как пользовательский ввод движется через внутренние протоколы. Особенно там, где безопасность-критичные конфигурации опираются на общие форматы данных с символами-разделителями — запятыми, точками с запятой, амперсандами. Это не новая класса уязвимостей, но случай с GitHub наглядно показывает, какой может быть цена неправильных предположений о доверенности данных внутри собственной инфраструктуры.
