آسیب‌پذیری بحرانی GitHub (CVE-2026-3854): اجرای کد از راه دور با git push

محققان امنیت سایبری جزئیات یک آسیب‌پذیری بسیار مهم را در GitHub.com و GitHub Enterprise Server منتشر کرده‌اند که می‌تواند به یک کاربر احراز هویت‌شده اجازه دهد تنها با اجرای یک دستور ساده git push به اجرای کد از راه دور (RCE) دست پیدا کند.

جزئیات آسیب‌پذیری

این ضعف امنیتی با شناسه CVE-2026-3854  و امتیاز  8.7 (CVSS)  ردیابی شده و در دسته آسیب‌پذیری‌های Command Injection قرار می‌گیرد.
بر اساس گزارش‌ها، مهاجمی که به یک repository دسترسی push (write access) داشته باشد، می‌تواند از این نقص برای اجرای کد روی سرور استفاده کند.

طبق بیانیه GitHub در حین عملیات git push، مقادیر ورودی کاربر (push options) به‌درستی sanitize نشده و مستقیماً در هدرهای داخلی سرویس استفاده شده‌اند.

مشکل اصلی از اینجا ناشی می‌شود که ساختار هدر داخلی از یک کاراکتر جداکننده (delimiter) استفاده می‌کند که همان کاراکتر می‌تواند در ورودی کاربر نیز وجود داشته باشد. این موضوع امکان تزریق متادیتای اضافی را برای مهاجم فراهم می‌کند.

نحوه کشف و رفع آسیب‌پذیری

این آسیب‌پذیری توسط شرکت امنیت ابری (Wiz) متعلق به (Google) در تاریخ ۴ مارس ۲۰۲۶ کشف و گزارش شد.
GitHub  نیز در مدت زمان کمتر از دو ساعت پس از تأیید، اصلاحیه (patch) را برای GitHub.com منتشر کرد.

همچنین این مشکل در نسخه‌های زیر از GitHub Enterprise Server برطرف شده است:

• 3.14.25
• 3.15.20
• 3.16.16
• 3.17.13
• 3.18.8
• 3.19.4
• 3.20.0 و نسخه‌های جدیدتر

طبق اعلام رسمی، هیچ شواهدی مبنی بر سوءاستفاده مخرب از این آسیب‌پذیری گزارش نشده است.

ریشه فنی آسیب‌پذیری

هسته اصلی مشکل به عدم اعتبارسنجی صحیح مقادیر git push options بازمی‌گردد. این مقادیر بدون پاک‌سازی مناسب وارد هدر داخلی X-Stat می‌شوند.

از آنجا که این هدر از semicolon (;) به‌عنوان جداکننده استفاده می‌کند و همین کاراکتر می‌تواند در ورودی کاربر نیز وجود داشته باشد، مهاجم قادر است:

• داده‌های مخرب تزریق کند
• ساختار متادیتا را دستکاری کند
• در نهایت اجرای کد را به‌دست بگیرد 

زنجیره اکسپلویت (Exploit Chain)

محققان Wiz نشان داده‌اند که این حمله از طریق ترکیب چند تزریق (Injection) انجام می‌شود:

• تزریق مقدار rails_env غیر production برای دور زدن sandbox
• تزریق custom_hooks_dir برای کنترل مسیر اجرای hookها
• تزریق repo_pre_receive_hooks برای اجرای کد مخرب از طریق path traversal

در نتیجه این زنجیره:

• sandbox امنیتی دور زده می‌شود
• کد دلخواه روی سرور اجرا می‌شود
• مهاجم به سطح دسترسی کاربر git می‌رسد

پیامدهای امنیتی

طبق گفته محققان:

با اجرای کد خارج از sandbox به‌عنوان کاربر git، کنترل کامل روی instance به‌دست آمد.

این دسترسی شامل موارد زیر است:

• خواندن و نوشتن روی فایل‌سیستم
• دسترسی به تنظیمات داخلی سرویس
• کنترل کامل محیط اجرایی

وضعیت GitHub.com و ریسک Multi-Tenant

در GitHub.com، فلگی به نام enterprise mode به‌صورت پیش‌فرض روی مقدار false تنظیم شده و همین موضوع باعث می‌شود مسیر اجرای custom hooks به‌طور عادی غیرفعال باشد.

با این حال، از آنجا که این فلگ نیز از طریق همان هدر داخلی (X-Stat) منتقل می‌شود، یک مهاجم می‌تواند با تزریق مقدار دلخواه، آن را تغییر داده و شرایط لازم برای سوءاستفاده را فراهم کند.

با توجه به معماری multi-tenant و زیرساخت اشتراکی GitHub، این موضوع پیامدهای مهمی دارد:

• اجرای کد روی یک نود (shared storage node)
• امکان گسترش دسترسی به سایر tenantها (cross-tenant exposure)

در چنین سناریویی، مهاجم بالقوه می‌تواند:

• به داده‌های تعداد زیادی repository روی همان زیرساخت دسترسی پیدا کند
• اطلاعات مربوط به سایر سازمان‌ها یا کاربران را مشاهده کند

میزان گستردگی آسیب‌پذیری

طبق گزارش Wiz، در زمان افشای عمومی:

• حدود ٪۸۸ ازinstanceها آسیب‌پذیر بوده‌اند
• اکسپلویت این نقص «به‌طرز قابل‌توجهی ساده» توصیف شده است

توصیه‌های امنیتی

GitHub به کاربران توصیه کرده است:

• سریعاً سیستم‌ها را به‌روزرسانی کنند
• دسترسی‌های repository را بازبینی کنند
• جریان داده‌های ورودی در سرویس‌های داخلی را audit کنند

جمع‌بندی

این آسیب‌پذیری نشان می‌دهد که:

• حتی پروتکل‌های داخلی نیز می‌توانند به سطح حمله تبدیل شوند
• عدم هماهنگی در اعتبارسنجی داده بین سرویس‌ها یک ریسک جدی است
• معماری‌های multi-service نیازمند بررسی دقیق جریان داده‌های ورودی هستند

به گفته Wiz وقتی چندین سرویس با زبان‌ها و فرضیات مختلف از یک پروتکل مشترک استفاده می‌کنند، همان فرضیات به یک سطح حمله حیاتی تبدیل می‌شوند.

نکته کلیدی برای تیم‌های فنی

اگر روی معماری‌های distributed یا microservices کار می‌کنید:

• مسیر حرکت داده‌های کنترل‌شده توسط کاربر را بررسی کنید
• به‌ویژه در جاهایی که داده وارد پروتکل‌های داخلی می‌شود
• و جایی که تصمیمات امنیتی بر اساس همین داده‌ها گرفته می‌شود