آسیبپذیری بحرانی گیتهاب: یه git push کافی بود!
هوش مصنوعیخلاصهٔ کاملتر
تیم تحقیقاتی Wiz یه آسیبپذیری خیلی جدی با شناسه CVE-2026-3854 توی زیرساخت داخلی گیت توی گیتهاب کشف کرده که میتونست هم GitHub.com و هم GitHub Enterprise Server رو تحت تأثیر قرار بده. این باگ به هر کاربر احراز هویتشدهای اجازه میداد با یه دستور ساده git push و بدون هیچ ابزار خاصی، کد دلخواهش رو روی سرورهای بکاند گیتهاب اجرا کنه.
نکته جالب ماجرا اینه که این آسیبپذیری با کمک ابزارهای هوش مصنوعی — بهخصوص مهندسی معکوس خودکار با IDA MCP — توی بایناریهای کامپایلشده و بستهی گیتهاب پیدا شده. این یکی از اولین موارد کشف باگ بحرانی توی کدهای closed-source با کمک هوش مصنوعیه و نشون میده این رویکرد داره چقدر جدی میشه.
ریشهی مشکل توی یه پروتکل داخلی به اسم X-Stat هدر هست که اطلاعات امنیتی رو بین سرویسهای مختلف جابجا میکنه. وقتی کاربر یه git push میزنه، درخواست از چند سرویس داخلی رد میشه: babeld که پروکسی گیت و نقطه ورود اصلیه، gitauth که احراز هویت میکنه و پالیسیهای امنیتی رو برمیگردونه، و gitrpcd که درخواست رو پردازش میکنه و کاملاً به هدرهای babeld اعتماد میکنه.
مشکل اینجاست که babeld مقدار push option هایی که کاربر با git push -o میفرسته رو بدون sanitize کردن مستقیم توی X-Stat هدر میذاره. این هدر فیلدهاش با سمیکالن (;) از هم جدا میشن. پس اگه کاربر یه سمیکالن توی مقدار push option بذاره، میتونه فیلدهای جدید و کاملاً دلخواه به هدر تزریق کنه:
X-Stat: ...; large_blob_rejection_enabled=bool:true; ...;
push_option_0=x;large_blob_rejection_enabled=bool:false;
push_option_count=1; ...
از اونجایی که پارسر این هدر از منطق last-write-wins استفاده میکنه (یعنی اگه یه کلید دو بار بیاد، مقدار دومی برندهست)، مقدار تزریقشده توسط مهاجم روی مقدار اصلی غالب میشه. این یعنی میشه فیلدهایی مثل rails_env، custom_hooks_dir و repo_pre_receive_hooks رو دستکاری کرد که مستقیماً نحوه اجرای hook ها و مسیر اسکریپتها رو کنترل میکنن — و این در نهایت منجر به اجرای کد دلخواه میشه.
روی GitHub.com این باگ امکان RCE روی نودهای shared storage رو میداد و تأیید شده که میلیونها ریپازیتوری عمومی و خصوصی متعلق به کاربران و سازمانهای مختلف روی این نودها در معرض دسترسی بودن. روی GitHub Enterprise Server هم اوضاع بدتره و با این باگ میشه کل سرور رو کامپرومایز کرد، از جمله همه ریپازیتوریها و secret های داخلی.
گیتهاب بعد از دریافت گزارش، در GitHub.com مشکل رو ظرف ۶ ساعت برطرف کرد و پچهایی هم برای GitHub Enterprise Server منتشر کرد. نسخههای آسیبپذیر GHES همه نسخههای ۳.۱۹.۱ و پایینترن و نسخههای پچشده از 3.14.24 به بعد هستن. اما در زمان انتشار این گزارش، ۸۸٪ از نمونههای GHES هنوز آپدیت نشدن. اگه از GitHub Enterprise Server استفاده میکنید، فوری باید به نسخه 3.19.3 یا بالاتر آپگرید کنید.
این باگ همچنین جایزهی Bug Bounty بسیار بالایی از گیتهاب به خودش اختصاص داد و Alexis Wales، CISO گیتهاب، این تحقیق رو بهعنوان نمونهای از بهترین همکاریهای امنیتی توصیف کرد.
نکات کلیدی:
- آسیبپذیری CVE-2026-3854 توی زیرساخت داخلی گیت گیتهاب کشف شد
- با یه git push ساده و بدون ابزار خاص، اجرای کد دلخواه روی سرور ممکن بود
- ریشه مشکل: تزریق فیلد به X-Stat هدر از طریق push option های sanitizeنشده
- روی GitHub.com: دسترسی به میلیونها ریپازیتوری عمومی و خصوصی
- روی GHES: کامپرومایز کامل سرور شامل همه ریپازیتوریها و secret ها
- GitHub.com ظرف ۶ ساعت پچ شد؛ کاربران GHES باید فوری به نسخه 3.19.3+ آپگرید کنن
- ۸۸٪ از نمونههای GHES هنوز آسیبپذیرن
- یکی از اولین باگهای بحرانی کشفشده در بایناریهای closed-source با کمک هوش مصنوعی
