Что если одна точка с запятой в команде git push могла бы открыть полный доступ к внутренним сервисам крупнейшей платформы для кода?
В начале марта 2026 года исследователи из компании Wiz отправили в программу bug bounty GitHub сообщение о критической уязвимости, получившей идентификатор CVE‑2026‑3854. В течение menos чем два часа команда GitHub воспроизвела проблему, развернула исправление на публичном сайте github.com и одновременно закрыла уязвимость во всех облачных предложениях – GitHub Enterprise Cloud, включая варианты с Data Residency и Enterprise Managed Users. Для само‑хостингового продукта GitHub Enterprise Server (GHES) патч стал доступен только к концу апреля, когда были опубликованы свежие релизы всех поддерживаемых веток.
Как устроена обработка push‑опций в GitHub
Функция git push --push-option=key=value существует в Git с версии 2.10 (сентябрь 2016 года) и позволяет клиенту передавать произвольные пары ключ‑значение на сервер. На стороне GitHub эти данные попадают в служебный межсервисный протокол, где они собираются в одну строку, разделённую точкой с запятой (;). Каждая часть строки интерпретируется downstream‑сервисом как доверенное поле метаданных, например, идентификатор репозитория, тип окружения или флаг для CI‑pipeline.
Именно в этом месте кроется уязвимость: если пользователь сумеет внести в значение push‑опции символ ;, он сможет добавить дополнительное поле в строку метаданных. При парсинге downstream‑сервис воспринимает это поле как легитимное, что позволяет переопределить переменные окружения, обойти песочницу, ограничивающую выполнение хуков, и ultimately выполнить произвольные команды на узле, обрабатывающем push.
Для эксплуатации достаточно иметь push‑доступ к любому репозиторию, даже к recién созданному приватному. Attacker формирует команду вида git push --push-option=foo=bar;INJECTED=value, после чего внутренний сервер формирует строку ...;foo=bar;INJECTED=value;... и downstream‑сервис, видя незнакомое поле INJECTED, рассматривает его как доверенное, подставляя его в контекст выполнения хука. Таким образом цепочка приводит к RCE с уровнем привилегий процесса, отвечающего за обработку push‑запросов.
Практические рекомендации для администраторов GHES
Если вы управляете экземпляром GitHub Enterprise Server, первым шагом является обновление до одной из следующих версий (или новее) в вашей мажорной ветке:
- GitHub Enterprise Server 3.14.25
- GitHub Enterprise Server 3.15.20
- GitHub Enterprise Server 3.16.16
- GitHub Enterprise Server 3.17.13
- GitHub Enterprise Server 3.18.7
- GitHub Enterprise Server 3.19.4
- GitHub Enterprise Server 3.20.0
После применения патча рекомендуется проверить журнал аудита на наличие подозрительных push‑операций. Команда для быстрого поиска:
grep ';' /var/log/github-audit.log | grep push-optionЕсли такие записи обнаружены, следует изучить связанную учётную запись, время, репозиторий и вывод выполненных хуков. Absence of matches указывает на то, что exploitation не происходило, но регулярный мониторинг остаётся хорошей практикой.
Выводы
Инцидент CVE‑2026‑3854 демонстрирует, насколько важно рассматривать каждый кодовый путь как потенциальную поверхность атаки, даже если он, по задумке architects, никогда не должен использоваться в продакшене. Из‑за изменения модели деплоя ранее исключённый код остался в файловой системе рядом с обработчиком push‑запросов, создав второй слой защиты, которого фактически не было. GitHub впоследствии удалил лишний код из окружений, усилив принцип «defense in depth».
Для пользователей публичного github.com никаких действий не требуется – уязвимость была закрыта в день сообщения, а форензический анализ логов не показал следов эксплуатации помимо тестов исследователей. Тем не менее, событие служит напоминанием о том, что даже seemingly безобидные функции, такие как push‑опции, могут стать вектором атаки, если их обработка недостаточно строго валидируется. Ожидается, что в будущих версиях GitHub будет усилена валидация полей межсервисного протокола и расширен аудит потенциально опасных символов в пользовательском вводе.
