چرا CVE-2026-97229 یک نقص بحرانی است؟
آسیب‌پذیری CVE-2026-97229 در GitLab Community Edition و Enterprise Edition به وضعیتی مربوط است که یک عبارت منظم خاص در پیکربندی CI/CD می‌تواند به اجرای کد دلخواه روی سرور GitLab منجر شود. رکورد رسمی GitLab برای این ضعف امتیاز CVSS نسخه ۳٫۱ برابر ۱۰٫۰، یعنی Critical، ثبت کرده است. اهمیت خطر فقط به خطای یک Job مربوط نیست؛ توضیح CNA امکان اجرای کد روی خود سرور را در شرایط مشخص مطرح می‌کند. این سطح اثر می‌تواند محرمانگی مخزن‌ها، داده احراز هویت و دسترس‌پذیری سرویس را تحت تأثیر قرار دهد. با این حال نباید بدون بررسی محیط و شواهد نتیجه گرفت همه نمونه‌های GitLab مورد حمله قرار گرفته‌اند. گام نخست تعیین نسخه دقیق و رفع نقص از مسیر رسمی است.
توصیف معتبر نقص از چه منبعی می‌آید؟
GitLab به‌عنوان مرجع اختصاص‌دهنده شناسه CVE توضیح داده که ناکافی بودن اعتبارسنجی Regular Expression در پیکربندی CI/CD، در بعضی شرایط می‌تواند مسیر اجرای کد از راه دور را ایجاد کند. در رکورد CVE، طبقه ضعف CWE-190 یعنی Integer Overflow or Wraparound ذکر شده است. این عبارت یک دسته‌بندی فنی از نحوه شکست کنترل محاسباتی را نشان می‌دهد، ولی تمام جزئیات مسیر بهره‌برداری را توضیح نمی‌دهد. اطلاعیه رسمی شامل شناسه، دامنه نسخه‌های آسیب‌پذیر و نسخه‌های اصلاحی است. برای گزارش مدیریتی بهتر است همین داده‌های مستقیم مبنا قرار گیرد، نه بازنشر ادعاهای شبکه اجتماعی. ممکن است تحلیل‌گرهای مستقل بعداً جزئیات بیشتری منتشر کنند، اما هر یافته باید از نظر تاریخ و سازگاری با نسخه بررسی شود.
نسخه‌های تحت تأثیر دقیقاً کدام‌اند؟
بر اساس رکورد منتشرشده GitLab، شاخه ۱۹٫۲ از آغاز تا پیش از ۱۹٫۲٫۸، شاخه ۱۹٫۳ تا پیش از ۱۹٫۳٫۵ و شاخه ۱۹٫۴ تا پیش از ۱۹٫۴٫۲ تحت تأثیر قرار دارند. نسخه‌های اصلاحی اعلام‌شده به‌ترتیب 19.2.8، 19.3.5 و 19.4.2 هستند. مدیر نباید فقط رقم اصلی ۱۹ را ببیند و تصمیم بگیرد سامانه امن است؛ شماره Minor و Patch برای این نقص تعیین‌کننده‌اند. همچنین نصب بسته با برچسب سفارشی یا ساخت بسته توزیع ممکن است روی روش نمایش نسخه اثر داشته باشد. اطلاعات واقعی از صفحه مدیریت و مدیر بسته گرفته و با اطلاعیه GitLab تطبیق داده شود. اگر چند Instance یا Runner متصل وجود دارد، باید مشخص شود کدام ماشین واقعاً سرویس GitLab را اجرا می‌کند.
CVSS 10 چه معنایی دارد؟
بردار اعلام‌شده CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H نشان می‌دهد حمله از شبکه قابل طرح است، پیچیدگی پایین ارزیابی شده، نیاز به مجوز اولیه یا تعامل کاربر در مدل پایه ثبت نشده و اثر بالقوه بر محرمانگی، یکپارچگی و دسترس‌پذیری بالا است. این امتیاز از ارزیابی فنی مستقل آسیب‌پذیری به دست می‌آید و جایگزین تحلیل اختصاصی دارایی نیست. GitLab عمومی که مخزن‌های خصوصی و Tokenهای CI/CD حساس دارد ممکن است پیامد بسیار سنگینی از رخداد ببیند. در مقابل، سامانه آزمایشی جدا با داده غیرحساس و بدون دسترسی شبکه گسترده ممکن است سطح مواجهه متفاوتی داشته باشد. در هر حالت وجود وصله رسمی به معنی مناسب بودن تأخیر در اصلاح نیست؛ اولویت باید بالا باشد.
CISA KEV و شواهد بهره‌برداری
CISA در ۲۹ اکتبر ۲۰۲۶ این شناسه را به فهرست Known Exploited Vulnerabilities اضافه کرده و مهلت اقدام اول نوامبر ۲۰۲۶ را برای مخاطبان مشمول ثبت کرده است. حضور در KEV با صرف انتشار یک PoC تفاوت دارد؛ این فهرست بر شواهد معتبر بهره‌برداری واقعی تمرکز می‌کند. با این حال ثبت در KEV به معنی آلوده بودن همه نصب‌ها یا دانستن هویت مهاجم در تک‌تک رخدادها نیست. برای مدیر امنیت، ترکیب CVSS بحرانی و KEV یک علامت روشن برای اولویت‌بندی فوری محسوب می‌شود. اگر مهلت مربوط به سازمانی الزام قانونی ندارد، باز هم می‌توان آن را مبنای تصمیم عملیاتی قرار داد. بررسی رخداد و اصلاح نسخه باید هم‌زمان برنامه‌ریزی شوند.
CI/CD چگونه به سطح حمله مرتبط می‌شود؟
GitLab تنها ابزار نمایش کد نیست؛ سامانه CI/CD آن دستور ساخت، آزمون و انتشار نرم‌افزار را مدیریت می‌کند. بسیاری از Pipelineها به متغیرهای محیطی، اعتبارنامه Registry، دسترسی به Runner و سرویس‌های جانبی متصل‌اند. نقصی که از مسیر پیکربندی CI/CD به اجرای کد روی سرویس اصلی برسد، از نظر معماری حساس است، زیرا مرز میان داده پیکربندی پروژه و اختیار پردازش سرور باید سخت‌گیرانه باشد. نباید فرض کرد محدود بودن دستورهای Job عادی حتماً این نقص را خنثی می‌کند؛ توصیف CVE دقیقاً به رفتار GitLab Server اشاره دارد. برای تحلیل دفاعی، فهرست پروژه‌های قابل دسترسی، سیاست ایجاد Pipeline و سطح دسترسی شبکه سرور را جدا بررسی کنید. مسیرهای دسترسی مدیر و سرویس‌های وابسته نیز اهمیت دارند.
تفاوت GitLab Server و Runner
Runnerها وظیفه اجرای Jobهای CI/CD را بر عهده دارند و ممکن است روی ماشین‌های جداگانه یا کانتینر اجرا شوند. GitLab Server مدیریت پروژه، کاربران و فرایند Pipeline را انجام می‌دهد. وقتی یک CVE درباره اجرای کد روی GitLab Server صحبت می‌کند، نباید اصلاح آن را تنها با به‌روزرسانی Runner تمام‌شده دانست. هر مؤلفه نسخه و مدل تهدید خاص خود را دارد. برای رسیدگی باید محل اجرای سرویس اصلی، نوع نصب Omnibus یا Container، نسخه GitLab و مسیر داده شناسایی شود. سپس وضعیت Runnerهای متصل برای بررسی اثر جانبی و اعتبارنامه‌های در دسترس مرور گردد. آسیب‌پذیری سرور می‌تواند در رخداد واقعی بر اجزای پیرامونی اثر بگذارد، ولی چنین اثری باید با شواهد مشخص اثبات شود نه حدس درباره معماری پروژه.
به‌روزرسانی از مسیر رسمی GitLab
اولین اقدام فنی مطالعه اطلاعیه Patch Release رسمی GitLab و انتخاب نسخه اصلاح‌شده متناسب با شاخه است. مدیر باید قبل از ارتقا از پایگاه داده، مخزن‌ها، پیکربندی و اسرار مورد نیاز پشتیبان معتبر تهیه کند و روش بازیابی را آزموده باشد. اگر نصب در محیطی با دسترس‌پذیری بالا انجام شده، توالی به‌روزرسانی گره‌ها باید طبق راهنمای همان معماری انتخاب شود. به‌روزرسانی بدون توجه به سازگاری PostgreSQL، Redis و اجزای جانبی ممکن است اختلال ایجاد کند. بعد از نصب، نسخه فعال واقعی و سلامت ورود، مشاهده پروژه، اجرای Pipeline و دسترسی Registry تأیید شود. صرف خروجی موفق مدیر بسته کافی نیست؛ سرویس باید در وضعیت عملیاتی درست قرار بگیرد و گزارش Patch در سامانه دارایی ثبت شود.
کنترل دسترسی عمومی تا زمان اصلاح
اگر نمونه GitLab از اینترنت قابل دسترسی است و امکان ارتقای فوری وجود ندارد، سازمان باید با توجه به راهنمای فروشنده و نیاز کسب‌وکار، محدودسازی موقت سطح مواجهه را بررسی کند. برای مثال محدود کردن دسترسی به شبکه مدیریت یا مسیر VPN ممکن است در بعضی محیط‌ها مناسب باشد، ولی چنین تغییری می‌تواند اتصال Webhook و همکاری تیم‌های دورکار را تحت تأثیر قرار دهد. پیش از اعمال Rule فایروال باید وابستگی‌های واقعی شناسایی شوند. کنترل موقت به معنی رفع نقص نیست و نباید برای مدت نامحدود جایگزین وصله شود. همچنین خاموش کردن ثبت رویداد یا کاهش امنیت ورود به بهانه رفع سریع اختلال منطقی نیست. مدیریت ریسک باید مسئول و موعد مشخص داشته باشد و پس از ارتقا کنترل‌های موقت دوباره بررسی شوند.
تعیین اینکه آیا نمونه مورد حمله قرار گرفته است
برای بررسی رخداد احتمالی، تیم امنیت باید گزارش‌های ورود، تغییرات مدیریتی، Jobهای نامعمول، خطاهای سرویس و دسترسی شبکه را با بازه زمانی مشخص بررسی کند. وجود یک Pipeline ناموفق به‌تنهایی مدرک بهره‌برداری از CVE نیست؛ در مقابل نبود هشدار شناخته‌شده نیز سلامت کامل را ثابت نمی‌کند. اگر سرور نشانه‌های غیرمعمول دارد، بهتر است پیش از پاک‌سازی و نصب مجدد، شواهد لازم با روش جرم‌یابی مناسب حفظ شوند. زمان سیستم، نسخه نرم‌افزار و مسیر ذخیره لاگ‌ها باید مستند شود. تیم نباید روی محیط تولید آزمایش بهره‌برداری فعال انجام دهد، چون ممکن است سرویس را مختل یا شواهد را تغییر دهد. نتیجه بررسی باید سطح اطمینان و محدودیت داده موجود را شفاف بیان کند.
بازبینی Token و Secretهای CI/CD
در سامانه‌های GitLab، Pipelineها ممکن است از کلید دسترسی Cloud، Token انتشار بسته یا اعتبارنامه Registry استفاده کنند. اگر شواهدی از نفوذ به سرور وجود داشته باشد، دامنه ارزیابی باید شامل این اعتبارنامه‌ها نیز شود. برای کاهش خطر، بهتر است Secretها با اصل حداقل مجوز ایجاد شوند، زمان اعتبار معقول داشته باشند و تنها در Jobهای مناسب در دسترس قرار گیرند. همچنین متغیرهای Protected و Masked باید مطابق سیاست پروژه بررسی شوند. پس از حادثه تأییدشده، چرخش کلیدها باید با برنامه انجام شود تا سرویس‌های وابسته بی‌دلیل قطع نشوند. حذف تصادفی همه اعتبارنامه‌ها بدون موجودی ممکن است آثار عملیاتی سنگینی داشته باشد، در حالی که چرخش هدفمند با ثبت تاریخ و مالکیت قابل مدیریت‌تر است.
ایزوله‌سازی مسیر ساخت و انتشار
یکی از درس‌های این نقص، اهمیت جدا کردن محیط اجرای ساخت از سرویس مدیریتی و داده‌های حیاتی است. Runner نباید بدون ضرورت به پایگاه داده تولید، کلیدهای مدیریت یا شبکه داخلی حساس دسترسی داشته باشد. در عین حال GitLab Server نیز باید فقط ارتباط‌های لازم به سامانه‌های پیرامونی را برقرار کند. طراحی Segmentation و حساب‌های خدماتی محدود می‌تواند اثر رخداد را کاهش دهد، هرچند نقص نرم‌افزاری اصلی همچنان نیازمند وصله است. برای یک پروژه بزرگ بهتر است Runnerهای قابل اعتماد و Runnerهای اجرای کد مشارکت‌کنندگان خارجی از هم جدا باشند. مسیر انتشار Artifact نیز باید با امضای مناسب و کنترل هویت انجام شود. امنیت CI/CD به یک کنترل محدود نمی‌شود؛ زنجیره‌ای از مرزهای اعتماد است.
چک‌لیست عملیاتی فوری
تمام Instanceهای GitLab CE و EE را در فهرست دارایی پیدا کنید؛ تنها سامانه اصلی کافی نیست و نسخه‌های آزمایشی یا قدیمی نیز اهمیت دارند. شماره دقیق نسخه و شاخه هر نصب را ثبت و با 19.2.8، 19.3.5 یا 19.4.2 مقایسه کنید. برای نسخه‌های آسیب‌پذیر پنجره اصلاح اضطراری تعیین کنید و قبل از تغییر، پشتیبان قابل بازیابی تهیه نمایید. پس از ارتقا، سرویس و Pipelineهای حیاتی را آزمون و نسخه نهایی را ثبت کنید. در کنار آن، گزارش رویداد و تغییرات غیرعادی را بررسی نمایید و اگر نشانه نفوذ یافت شد، فرایند پاسخ به رخداد را فعال کنید. وضعیت Secretهای حساس و حساب‌های مدیریتی هم در ارزیابی قرار گیرند. سرانجام نتیجه اصلاح برای مدیریت و تیم امنیت گزارش شود.
چرا اسکن نسخه به تنهایی کافی نیست؟
اسکنر آسیب‌پذیری ممکن است از روی بنر HTTP یا داده پکیج نتیجه بگیرد نسخه GitLab قدیمی است. این نشانه مفید است، اما باید با نسخه واقعی سرویس در حال اجرا تطبیق داده شود. بعضی سازمان‌ها از Image سفارشی، بسته Backportشده یا استقرار چندگانه استفاده می‌کنند که نتیجه اسکن را پیچیده می‌کند. همچنین وجود یک Patch در فایل سیستم تضمین نمی‌کند سرویس فعال با همان نسخه بالا آمده باشد. برای ارزیابی دقیق، شناسه Image یا بسته، نسخه نمایش‌داده‌شده توسط GitLab و وضعیت Restart بررسی شود. گزارش باید میان «آسیب‌پذیر»، «وصله اعمال شده»، «نیازمند بررسی» و «دارایی یافت نشد» تمایز قائل شود. این روش به تیم کمک می‌کند اولویت را بر اساس داده معتبر تعیین کند، نه فقط خروجی یک ابزار.
اثر بالقوه بر زنجیره تأمین نرم‌افزار
GitLab در بسیاری از سازمان‌ها محل نگهداری کد، Pipeline، Artifact و تنظیمات استقرار است. اگر مهاجم به اختیار غیرمجاز روی این سامانه برسد، ممکن است محرمانگی پروژه‌ها یا یکپارچگی خروجی ساخت تحت تأثیر قرار گیرد. این پیامد از جنس ریسک معماری است و نباید بدون شواهد به عنوان نتیجه قطعی بهره‌برداری از هر نمونه گزارش شود. برای دفاع در عمق بهتر است امضای Artifact، محافظت از شاخه اصلی، بازبینی اجباری تغییر Pipeline و تفکیک اعتبارنامه‌های انتشار وجود داشته باشد. همچنین تولید نرم‌افزار نباید به یک حساب مشترک بدون گزارش وابسته باشد. اگر نقصی با دسترسی روی سرور رفع شده است، تیم می‌تواند از آن فرصت برای بازبینی زنجیره اعتماد از کد تا محیط تولید استفاده کند.
اطلاع‌رسانی به تیم‌ها و مشتریان
در رخداد امنیتی، پیام‌رسانی دقیق اهمیت زیادی دارد. مدیر باید ابتدا وضعیت نسخه‌ها و اقدام اصلاحی را به تیم‌های توسعه و عملیات اعلام کند، سپس در صورت وجود شواهد دسترسی غیرمجاز، مسئول حقوقی و مدیریت حادثه را در جریان قرار دهد. نباید صرف دیدن خبر CVE به مشتریان اعلام کرد داده آن‌ها افشا شده است، زیرا این نتیجه نیازمند بررسی واقعی است. از سوی دیگر پنهان کردن وجود نقصی که به‌شدت در معرض بهره‌برداری قرار دارد می‌تواند اعتماد را از بین ببرد. گزارش مناسب شامل شناسه نقص، تاریخ کشف در سازمان، دارایی‌های تحت تأثیر، زمان نصب وصله و وضعیت بررسی شواهد است. اگر داده ناقص است، باید محدودیت آن با عبارت روشن بیان شود و حدس به عنوان واقعیت مطرح نشود.
پرسش‌های رایج درباره CVE-2026-97229
آیا نقص به GitLab CE محدود است؟ خیر، رکورد CNA هر دو نسخه CE و EE را نام می‌برد. آیا اجرای کد بدون احراز هویت مطرح شده است؟ بله، در توصیف رسمی در شرایط مشخص چنین امکانی ذکر شده است. آیا هر Pipeline مخرب به معنای سوءاستفاده از این شناسه است؟ خیر، باید مسیر و شرایط خاص با شواهد تأیید شوند. آیا نسخه 19.4.2 برای همه شاخه‌ها انتخاب درست است؟ نسخه اصلاحی باید با مسیر ارتقای شاخه نصب‌شده هماهنگ شود. آیا حضور در KEV یعنی سازمان حتماً آسیب دیده است؟ خیر، تنها نشان‌دهنده شواهد بهره‌برداری واقعی از نقص است. آیا تعویض Runner کافی است؟ خیر، نسخه سرویس GitLab باید طبق اطلاعیه فروشنده اصلاح شود. این تمایزها از توصیه‌های نادرست جلوگیری می‌کنند.
جمع‌بندی و منابع اصلی
CVE-2026-97229 نمونه‌ای بحرانی از خطر اعتبارسنجی ناکافی پیکربندی در سامانه مدیریت چرخه نرم‌افزار است. امتیاز CVSS 10، امکان اجرای کد بدون احراز هویت در توضیح GitLab و ورود به فهرست CISA KEV، اصلاح فوری را توجیه می‌کنند. راه‌حل اعلام‌شده ارتقا به نسخه‌های اصلاحی متناسب با شاخه است؛ در کنار آن، بررسی شواهد رخداد و کنترل Secretهای CI/CD باید با توجه به وضعیت هر سازمان انجام شود. هیچ گزارش عمومی نباید جای دستورالعمل رسمی فروشنده یا تحلیل محیط واقعی را بگیرد. منابع قابل اتکا عبارت‌اند از رکورد CVE ثبت‌شده توسط GitLab، صفحه Patch Release و فهرست رسمی CISA. آزمایش تهاجمی روی سرور دیگران یا تولید بدون مجوز بخشی از راهنمای دفاعی نیست.
