باگ بحرانی اجرای کد از راه دور در گیتلب (CVE-2026-97229)؛ کدام نسخهها آسیبپذیرند و چطور وصله کنیم
در تاریخ ۱۲ مهرماه ۱۴۰۵ (۱۲ اکتبر ۲۰۲۶) تیم گیتلب یک نسخه وصله بحرانی (Critical Patch Release) منتشر کرد که یک آسیبپذیری با شناسه CVE-2026-97229 را برطرف میکند. این باگ در موتور پردازش عبارات باقاعده (regex) بخش تنظیمات CI/CD قرار دارد و به مهاجم اجازه میدهد بدون نیاز به لاگین، کد دلخواه را روی سرور گیتلب اجرا کند. از ۲۹ مهرماه (۲۹ اکتبر ۲۰۲۶) این آسیبپذیری رسما در فهرست آسیبپذیریهای مورد سوءاستفاده فعال (KEV) آژانس CISA آمریکا ثبت شده است.
چه اتفاقی افتاده است؟
بخش تنظیمات پایپلاین CI/CD گیتلب، عبارات باقاعدهای را که در قوانین پایپلاین (مثل rules:if) نوشته میشوند کامپایل میکند. در این کامپایلر یک باگ سرریز عدد صحیح (Integer Overflow، با شناسه CWE-190) وجود دارد. اگر یک عبارت باقاعده بهطور خاص ساختهشده در فایل .gitlab-ci.yml یک پروژه قرار بگیرد، میتواند یک شمارنده داخلی را سرریز کند و حافظه سرور را بهشکلی آسیب بزند که منجر به اجرای کد از راه دور بدون احراز هویت میشود.
نکته مهم این است که برای سوءاستفاده نه لاگین لازم است، نه توکن API و نه هیچ تعامل خاصی از سوی کاربر قربانی؛ کافی است فایل تنظیمات CI/CD آلوده به سرور برسد. این مسیر میتواند از طریق یک پروژه عمومی که مرجریکوئست میپذیرد، یا از طریق ایمپورت/میرور یک مخزن تحت کنترل مهاجم اتفاق بیفتد.
چه نسخههایی از گیتلب آسیبپذیر هستند؟
این باگ فقط نسخههای self-managed (نصبشده روی سرور خودتان) از GitLab CE و EE را تحت تأثیر قرار میدهد و فقط در سه شاخه اصلی زیر وجود دارد:
| نسخه گیتلب | وضعیت | نسخه وصلهشده |
|---|---|---|
| 19.2.x قبل از 19.2.8 | آسیبپذیر | 19.2.8 |
| 19.3.x قبل از 19.3.5 | آسیبپذیر | 19.3.5 |
| 19.4.x قبل از 19.4.2 | آسیبپذیر | 19.4.2 |
| نسخههای اصلی قبلتر از 19.2 | خارج از دامنه این آدوایزری | — |
طبق آدوایزری رسمی گیتلب، شاخههای اصلی قدیمیتر از 19.2 در این مشکل گزارش نشدهاند. GitLab.com و GitLab Dedicated (نسخههای ابری خود گیتلب) از قبل توسط شرکت گیتلب روی سرورهایشان وصله شدهاند و نیازی به اقدام از سوی کاربران آنها نیست. تنها نصبهای self-managed باید وصله را خودشان اعمال کنند.

این باگ چقدر خطرناک است؟
گیتلب شدت این آسیبپذیری را با امتیاز CVSS 4.0 برابر ۱۰ از ۱۰ (بحرانی، بالاترین سطح ممکن) رتبهبندی کرده است. این امتیاز بالا از ترکیب چند عامل میآید: مهاجم به احراز هویت نیاز ندارد، میتواند هر کدی را روی سرور اجرا کند، و این دسترسی محدود به یک پروژه نمیماند، کل سرور گیتلب را در بر میگیرد. هر کسی که از گیتلب self-managed نسخه 19.2 تا 19.4 برای مدیریت کد یا CI/CD استفاده میکند، در معرض نفوذ کامل به سرور قرار دارد، فراتر از سوءاستفاده از یک پایپلاین.
آیا این باگ در دنیای واقعی مورد سوءاستفاده قرار گرفته است؟
بله. علاوه بر یک اکسپلویت اثبات مفهوم (PoC) منتشرشده توسط پژوهشگر Jonah Burgess، تیم تحقیقاتی Rapid7 نیز این آسیبپذیری را روی یک نمونه آزمایشی GitLab CE نسخه 19.4.1 (وصلهنشده) بازسازی کرده است. مهمتر از همه، CISA این CVE را در تاریخ ۲۹ اکتبر ۲۰۲۶ به فهرست آسیبپذیریهای مورد سوءاستفاده فعال (KEV) اضافه کرده و مهلت رفع آن را ۱ نوامبر ۲۰۲۶ تعیین کرده است. ورود به فهرست KEV یعنی CISA این سوءاستفاده را در دنیای واقعی و در حال وقوع تأیید کرده، نه یک احتمال تئوری محض.
سرور گیتلب چیست و چرا این باگ اینقدر اهمیت دارد؟
سرور گیتلب معمولا مرکز مدیریت کد منبع، مرجریکوئستها و پایپلاینهای CI/CD یک تیم توسعه است؛ هم کد منبع پروژهها را نگه میدارد، هم کلیدها و متغیرهای محرمانه مورد استفاده در build و deploy را. خیلی از تیمها همین سرور گیتلب را خودشان نصب و اجرا میکنند و یک یا چند GitLab Runner خودمیزبان هم به آن وصل میکنند تا پایپلاینهای CI/CD را اجرا کنند. به همین دلیل نفوذ به سرور گیتلب فراتر از لو رفتن کد است؛ میتواند به سرقت سکرتهای CI/CD، دسترسی به سرورهای دیگر زیرساخت از طریق همان سکرتها، و حتی تزریق کد مخرب به محصول نهایی از طریق پایپلاین build بینجامد. برای همین، یک باگ RCE بدون احراز هویت در خود موتور CI/CD، یکی از جدیترین نوع آسیبپذیریهایی است که یک سرور گیتلب میتواند با آن مواجه شود.
چطور بفهمیم سرور ما آسیبپذیر است؟
برای تشخیص نسخه گیتلب نصبشده روی سرورتان، یکی از روشهای زیر را امتحان کنید:
از طریق رابط وب: وارد گیتلب شوید، از منوی کاربری گزینه Help و سپس صفحه About GitLab را باز کنید؛ نسخه دقیق همانجا نوشته شده است.
از طریق API (اگر توکن دارید):
curl --header "PRIVATE-TOKEN: <توکن-شما>" "https://gitlab.example.com/api/v4/version"
از طریق SSH به سرور، برای نصبهای Omnibus:
sudo gitlab-rake gitlab:env:info | grep -i version
یا مستقیم از فایل نسخه:
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
برای نصب از طریق پکیج روی Debian/Ubuntu:
apt list --installed | grep gitlab
برای نصب داکری:
docker exec gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
اگر نسخه شما 19.2.x زیر 19.2.8، یا 19.3.x زیر 19.3.5، یا 19.4.x زیر 19.4.2 است، سرورتان آسیبپذیر است و باید فورا اقدام کنید. در کنار این بررسی، یک دور چکلیست امنیت سرور لینوکس هم خالی از لطف نیست.
چطور وصله کنیم؟
طبق آدوایزری رسمی گیتلب، هیچ راهحل موقت (workaround) رسمی بهجای آپگرید وجود ندارد؛ یعنی تنها راه رفع قطعی مشکل، ارتقا به یکی از نسخههای 19.2.8، 19.3.5 یا 19.4.2 (یا بالاتر) است. چند نکته عملی برای آپگرید:
- برای نصبهای تکنود (single-node)، در زمان آپگرید به دلیل migrationها احتمال قطعی کوتاه سرویس وجود دارد؛ آپگرید را در یک پنجره کمترافیک انجام دهید.
- نسخه 19.3.5 شامل migrationهای post-deploy هم است؛ قبل از آپگرید از دیتابیس و دایرکتوری داده گیتلب یک بکاپ/اسنپشات تازه بگیرید.
- برای نصبهای multi-node، از رویه رسمی zero-downtime upgrade گیتلب استفاده کنید تا سرویس در طول ارتقا قطع نشود.
- تا زمانی که وصله را اعمال نکردهاید، میتوانید سطح ریسک را با محدود کردن افرادی که اجازه push یا merge تنظیمات CI/CD را دارند، و غیرفعال کردن اجرای پایپلاین برای مرجریکوئستهای فورکشده/خارجی، کاهش دهید. تنظیم درست فایروال سرور برای محدود کردن دسترسی به پورتهای مدیریتی و روشن کردن لاگ تغییرات فایلها با Auditd هم تشخیص زودهنگام تلاش برای سوءاستفاده را راحتتر میکند؛ این اقدامات جایگزین وصله نیستند، فقط پنجره ریسک را کوچکتر میکنند.
اگر گیتلب خودتان را روی سرور خودتان اجرا میکنید، یکی از راههای ساده شروع، اپ یککلیکی GitLab CE آریانت روی سرور ابری OVH آلمان است؛ سرور حدود ۱۵ تا ۲۵ دقیقه بعد از سفارش آماده میشود، با کاربر root وارد میشوید و از همانجا مسئول آپدیت و وصلهکردن گیتلب خودتان هستید، دقیقا همان کاری که در این مقاله بررسی کردیم. محدود کردن دسترسی به پورتهای مدیریتی را هم از همان پنل فایروال سرور انجام میدهید. برای شروع: اپ یککلیکی GitLab CE روی سرور ابری آریانت.
سؤالات متداول
آیا نسخههای قدیمیتر از 19.2 هم در خطرند؟ طبق آدوایزری رسمی گیتلب، شاخههای اصلی قدیمیتر از 19.2 در دامنه این گزارش نیستند؛ فقط 19.2 قبل از 19.2.8، 19.3 قبل از 19.3.5 و 19.4 قبل از 19.4.2 آسیبپذیر اعلام شدهاند.
آیا کاربران GitLab.com هم باید کاری انجام دهند؟ خیر. GitLab.com و GitLab Dedicated از قبل توسط خود شرکت گیتلب روی سرورهایشان وصله شدهاند؛ این موضوع فقط نصبهای self-managed را درگیر میکند.
آیا راهحل موقتی بهجای آپگرید وجود دارد؟ گیتلب هیچ workaround رسمی اعلام نکرده است. تنها راه رفع کامل، ارتقا به 19.2.8، 19.3.5 یا 19.4.2 است؛ محدود کردن دسترسی به تنظیمات CI/CD فقط ریسک را کم میکند، نه حذف میکند.
چطور بفهمم این باگ علیه سرورهای دیگر هم استفاده شده؟ این آسیبپذیری در تاریخ ۲۹ اکتبر ۲۰۲۶ به فهرست KEV آژانس CISA اضافه شده؛ این فهرست فقط برای آسیبپذیریهایی است که سوءاستفاده واقعی و تأییدشده از آنها در دنیای واقعی دیده شده، نه برای حدسهای تئوری.




