GitHub RCE через git push: как сломался доверенный pipeline

GitHub RCE через git push — редкий случай, когда платформа масштаба GitHub сама подробно разбирает почти худший сценарий для dev infrastructure. 4 марта 2026 года Wiz отправила отчёт о том, что обычный git push с вредной push option позволяет выполнить код на сервере, а 28 апреля GitHub раскрыла детали и заявила, что следов эксплуатации не нашла.

История важна не только из-за самого CVE-2026-3854. Она показывает, как одна неверно проведённая граница доверия внутри многошагового pipeline превращает штатную функцию Git в проблему уровня платформы. Для GitHub.com это означало потенциальный доступ к shared storage nodes. Для GitHub Enterprise Server — риск полного захвата инстанса у любого, кто уже умеет пушить в репозиторий.

По состоянию на 29 апреля 2026 года корректный способ читать эту новость такой: это не подтверждённый «взлом GitHub», а прозрачный postmortem о критической уязвимости, которую GitHub закрыла в день отчёта Wiz и позже вынесла в публичный разбор. Для технической аудитории здесь ценен не только сам баг, но и то, что именно сломалось: внутренний протокол, доверие между сервисами и старый кодовый путь, который вообще не должен был лежать в production-образе.

Как обычный git push превратился в RCE

Суть уязвимости неприятно приземлённая. GitHub и Wiz описывают pipeline, где пользовательский push проходит через несколько внутренних сервисов: babeld, gitauth, gitrpcd и pre-receive hook. Между ними ходит внутренний заголовок X-Stat с метаданными о push-операции. Проблема возникла в точке, где babeld переносил пользовательские push options в этот заголовок без нормальной санитаризации.

Push options сами по себе не экзотика, а штатная функция Git. Пользователь может передавать их через git push -o .... Но GitHub использовала внутри X-Stat разделитель ;, который мог появиться и в пользовательском вводе. Дальше включился знакомый кошмар распределённых систем: downstream-сервис разбирал заголовок как набор key=value полей и применял модель last write wins. Если ключ появлялся дважды, побеждало более позднее значение.

Это и дало атакующему рычаг. Через подставленную push option можно было инжектить новые поля, переопределять внутренние флаги, менять среду исполнения и обходить sandbox, который должен был ограничивать хуки. Wiz в своём разборе показывает, что цепочка доходила до выполнения произвольных команд от имени сервисного пользователя git.

Полезный редакционный вывод здесь такой: баг не выглядит как «кто-то забыл экранировать строку» в одиночном скрипте. Он живёт на стыке нескольких допущений. Один сервис решил, что пользовательский ввод можно безопасно встроить во внутренний заголовок. Другой решил, что все поля в этом заголовке уже доверенные. Третий держал рядом кодовый путь, который в production вообще не должен был существовать. По отдельности эти решения кажутся терпимыми. Вместе они дали RCE.

Почему GitHub.com и GHES — разные истории

Снаружи всё выглядит как один CVE, но риск у двух контуров разный. Для GitHub.com и GitHub Enterprise Cloud GitHub пишет, что фикс был выкачен 4 марта 2026 года и никаких действий от пользователей не требуется. Компания также отдельно утверждает, что по телеметрии аномальный кодовый путь срабатывал только во время тестов Wiz, а данных клиентов не читали, не меняли и не выкачивали.

При этом потенциальный blast radius у GitHub.com выглядел особенно неприятно. Wiz утверждает, что на GitHub.com выполнение кода происходило на shared storage nodes, где сервисный пользователь git имел доступ к репозиториям разных арендаторов. Исследователи подчёркивают, что не читали чужой код и проверяли воздействие только на своих тестовых аккаунтах, но сама модель риска для multi-tenant платформы здесь предельно понятна.

С GHES картина другая. GitHub прямо пишет: для эксплуатации на GitHub Enterprise Server нужен аутентифицированный пользователь с правом push на конкретном инстансе. Это сужает поверхность атаки по сравнению с публичным облаком, но в обмен повышает цену ошибки для администраторов. На self-hosted контуре такой баг уже не про соседние tenant-границы, а про полный захват вашего собственного сервера и его секретов.

Именно поэтому GitHub рекомендует GHES-администраторам не только обновиться, но и проверить /var/log/github-audit.log на push-операции с символом ; внутри push options. Для облачных пользователей это просто интересный security-case. Для владельцев GHES это ещё и конкретный operational checklist.

Откуда взялась путаница с версиями патчей

Здесь GitHub невольно подложила администраторам маленькую мину. В таймлайне и ранних формулировках Wiz фигурируют мартовские версии вроде 3.19.3, 3.18.6 и 3.14.24. Но в публичном посте GitHub от 28 апреля список рекомендованных веток уже другой: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4 и 3.20.0 или новее.

Причина не в том, что кто-то «неправильно понял CVE». Release notes GitHub показывают более тонкую картину: часть ранних patch-релизов потом была unpublished по операционным причинам, а пользователям рекомендовали перейти на следующие доступные патчи. Для 3.19 это особенно видно: на странице релизов GitHub отдельно предупреждает, что 3.19.3 была снята и вместо неё нужно использовать более свежую 3.19.4. То же касается и других веток, где мартовский security-fix потом пережил дополнительную перепаковку.

Это полезный урок сам по себе. Когда вы читаете уязвимость такого масштаба, недостаточно один раз увидеть CVE и сохранить в голове первую попавшуюся версию. Нужны свежие release notes по вашей ветке. В этой истории разница между «фикс существует» и «какой патч реально надо ставить сегодня» оказалась не косметической, а практической.

Почему этот postmortem важен даже тем, кто не использует GHES

Самый сильный слой этой истории лежит шире конкретного GitHub. Баг вырос из доверия к внутреннему протоколу между сервисами, написанными на разных языках и живущими в одном pipeline. Это тот же класс проблем, который постоянно всплывает в современной инфраструктуре: пользовательский ввод формально проходит через «внутренний» слой и внезапно начинает выглядеть как системная команда.

Если смотреть на соседние инциденты, рисунок повторяется. В истории про взлом Vercel через AI-инструмент слабым местом стал вспомогательный слой доступа и доверия вокруг OAuth. Во взломе LiteLLM на PyPI проблема жила в цепочке поставки пакетов. Случай GitHub интересен тем, что показывает третий тип риска: атака не через внешнюю библиотеку и не через украденный токен, а через несовпадающие предположения внутри собственного pipeline платформы.

Есть и ещё один неприятный сигнал для индустрии. Wiz прямо пишет, что использовала AI-augmented reverse engineering и IDA MCP, чтобы быстрее разбирать закрытые бинарники GitHub и восстанавливать внутренние протоколы. Это не делает баг «AI-уязвимостью», но меняет экономику исследования. Закрытый код всё хуже защищает сам по себе, если анализ многошаговых binary-only систем становится быстрее и дешевле.

Наконец, GitHub сама подчёркивает второй слой защиты: кроме санитаризации ввода, компания убрала из production-окружений лишний кодовый путь, который не должен был лежать в контейнерном образе. Это хороший пример того, почему hardening нельзя сводить к одному фиксу на входе. Если ненужная ветка исполнения существует на диске, она рано или поздно может стать частью чьей-то exploit chain.

Что проверить командам прямо сейчас

• Если у вас GitHub Enterprise Server, ориентируйтесь на текущие release notes своей ветки, а не на ранние пересказы CVE. Для этой истории GitHub рекомендует ветки 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4 и 3.20.0 или новее.
• Проверьте аудит push-операций на символ ; внутри push options. GitHub прямо советует смотреть /var/log/github-audit.log.
• Разберите свои внутренние протоколы между сервисами. Если пользовательский ввод сериализуется в «доверенный» внутренний формат, это уже поверхность атаки, а не просто транспортный слой.
• Не держите в production-образах кодовые пути, которые там не используются. GitHub сама показывает, что «лишний» код на диске превращает локальный баг во что-то гораздо хуже.
• Не путайте sandbox с полноценной защитой. Если удаётся подменить среду исполнения или внутренние флаги, песочница может оказаться декоративной. Этот же урок стоит держать в голове, когда вы даёте агентам больше прав, о чём мы недавно писали в материале LinuxArena: как контролировать AI-агентов в production.

Итог у этой истории довольно жёсткий. CVE-2026-3854 важна не только потому, что один git push мог привести к RCE. Она важна потому, что GitHub публично показала тип сбоя, который легко недооценить внутри сложной инфраструктуры: доверенный внутренний протокол, к которому случайно дотянулся пользовательский ввод. Такие вещи редко выглядят драматично в код-ревью, зато прекрасно складываются в критические инциденты.

Для Toolarium это хороший материал не в жанре «ещё одна страшная CVE», а в жанре инженерного разбора. Здесь есть чёткие даты, понятная цепочка ошибки, прозрачный response window и редкая для большой платформы готовность рассказать, что именно сломалось. Именно такие postmortem полезнее всего читать командам, которые строят свои CI/CD, внутренние прокси, агентные контуры и сервисные pipeline.

Читайте также

• Взлом Vercel: AI-инструмент стал входом в инфраструктуру
• Взлом LiteLLM на PyPI: как хакеры превратили ИИ-библиотеку в кражу паролей
• LinuxArena: как контролировать AI-агентов в production

Источники и дата проверки

Факты и версии патчей проверены 29 апреля 2026 года. Для GitHub Enterprise Server ориентироваться стоит на актуальные release notes, а не на ранние мартовские патч-номера из вторичных пересказов.

• GitHub Blog: Securing the git push pipeline, опубликовано 28 апреля 2026 года.
• Wiz Research: GitHub RCE Vulnerability: CVE-2026-3854 Breakdown, опубликовано 28 апреля 2026 года.
• GitHub Docs: GHES 3.19 release notes, проверено 29 апреля 2026 года.
• GitHub Docs: GHES 3.18 release notes, проверено 29 апреля 2026 года.
• GitHub Docs: GHES 3.14 release notes, проверено 29 апреля 2026 года.
• Git documentation: git push --push-option, проверено 29 апреля 2026 года.