اگر از نسخه‌های شخصی‌ساز GitLab برای مدیریت جریان‌های هوش مصنوعی استفاده می‌کنید، احتمالاً همین حالا یک درِ باز به روی مهاجمان در شبکه داخلی خود دارید. یک نقص امنیتی با امتیاز شدت ۹.۹ (بسیار بحرانی) در درگاه هوش مصنوعی (AI Gateway) این شرکت کشف شده است که می‌تواند تمام حریم خصوصی و یکپارچگی داده‌های شما را به خطر اندازد. این آسیب‌پذیری که با کد CVE-2026-90970 شناسایی شده، به مهاجم اجازه می‌دهد از محدوده امنیتی تعیین‌شده فرار کند. در واقع، اثر این حمله فراتر از یک بخش کوچک است و به کل سیستم میزبان سرایت می‌کند. شدت این موضوع با تغییر در «دامنه» (Scope) بردار CVSS تشدید شده است؛ به این معنا که تأثیر حمله از مرزهای authority امنیتیِ خودِ جزء آسیب‌پذیر فرار کرده و به محیط بیرونی نفوذ می‌کند، به جای آنکه در داخل همان جزء محصور بماند.
بسیاری از سازمان‌ها برای مدیریت ارتباط بین محیط توسعه و ارائه‌دهندگان مدل زبانی بزرگ (LLM) — که شبیه کتابخانه‌داری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — از درگاه‌های هوش مصنوعی استفاده می‌کنند. برای کسانی که استقرار شخصی (Self-hosted) را انتخاب کرده‌اند، این درگاه تنها سد دفاعی و مرز امنیتی اصلی است که تضمین می‌کند کدهای حساس و پرامپت‌ها هرگز از شبکه داخلی خارج نشوند. وقتی این مرز می‌شکند، کل مسیر استنتاج (Inference) — یعنی همان لحظه تولید جواب توسط مدل، شبیه به خودِ آشپزی نه دوره آموزش آشپز — به یک ورودی باز برای مهاجمان تبدیل می‌شود.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، لایه‌های واسط معمولاً ضعیف‌ترین حلقه زنجیره هستند.
سازوکار نفوذ
به نقل از یادداشت انتشار وصله GitLab در ۱۱ اکتبر ۲۰۲۶، این اکسپلویت پلتفرم Duo Agent را هدف قرار می‌دهد. یک کاربر احراز هویت شده که به این پلتفرم دسترسی دارد، می‌تواند با ایجاد یک پیکربندی خاص و دست‌کاری‌شده در جریان کاری (Flow Configuration)، سیستم را فریب دهد تا از قالب پرامپت (Prompt Template) خارج شود. این قالب‌ها در حالت عادی باید جریان‌های تعریف‌شده را در یک محیط ایزوله یا سندباکس (Sandbox) نگه دارند تا از دسترسی به سیستم‌عامل میزبان جلوگیری شود. این نوع دست‌کاری در ورودی‌ها یادآور آسیب‌پذیری‌های تزریق پرامپت در عامل‌های هوش مصنوعی است که پیش‌تر نشان داد چگونه ورودی‌های مهندسی‌شده می‌توانند منطق عملیاتی AI را دور بزنند.
در پلتفرم Duo Agent، توسعه‌دهندگان انتظار دارند که قالب‌های پرامپت و جریان‌های چندمرحله‌ای را به عنوان بخشی از محتوای عادی کاربر-محور طراحی کنند. سندباکس در اینجا کنترل اصلی است که این جریان‌های طراحی‌شده را در داخل فرآیند مورد نظرشان نگه می‌دارد. نقص موجود در CVE-2026-90970 اجازه می‌دهد یک پیکربندی مهندسی‌شده، این سندباکس را به‌طور کامل ترک کند و از محیط ایزوله خارج شود.
پس از شکست سندباکس، مهاجم توانایی اجرای دستورات دلخواه (Arbitrary Commands) را مستقیماً روی درگاه هوش مصنوعی به دست می‌آورد. از آنجا که این درگاه در مرکز خط لوله هوش مصنوعی قرار دارد، دایره تخریب (Blast Radius) بسیار گسترده است؛ زیرا این درگاه تمام اعتبارنامه‌های API برای هر ارائه‌دهنده مدلی که پلتفرم به آن متصل است را در اختیار دارد و هر پرامپت و پاسخی را که از سیستم عبور می‌کند، مشاهده می‌کند. این آسیب‌پذیری توسط یک پژوهشگر از طریق پلتفرم HackerOne کشف و گزارش شده است.
نسخه‌های آسیب‌پذیر و راهکارها
بر اساس مستندات GitLab، نسخه‌های خاصی از AI Gateway آسیب‌پذیر شناسایی شده‌اند. بسیار مهم است که توجه کنید این شماره نسخه‌ها راستی به خودِ «درگاه» اشاره دارد و نه برنامه اصلی GitLab:
- نسخه‌های ۱۸.۱.۶ تا ۱۹.۲.۳
- نسخه‌های ۱۹.۳.۰ تا ۱۹.۳.۱
- نسخه‌های ۱۹.۴.۰ و بالاتر
برای رفع این خطر، مدیران باید بسته به شاخه (Branch) فعلی خود، به نسخه‌های اصلاح‌شده ۱۹.۲.۴، ۱۹.۳.۲ یا ۱۹.۴.۱ ارتقا دهند. GitLab توصیه می‌کند مشتریانی که از استقرار شخصی (Self-managed) برای نصب AI Gateway استفاده می‌کنند، این به‌روزرسانی‌ها را فوراً انجام دهند.
تله موجودی دارایی‌ها
یک نکته عملیاتی بحرانی این است که AI Gateway روی یک خط نسخه (Version Line) مجزا از برنامه اصلی GitLab اجرا می‌شود. به‌روزرسانی نسخه اصلی GitLab به‌طور خودکار درگاه را به‌روز نمی‌کند. این موضوع یک نقطه کور خطرناک برای تیم‌های امنیتی ایجاد می‌کند که در لیست دارایی‌های (Asset Inventory) خود، «GitLab» را به عنوان یک آیتم واحد ثبت کرده‌اند.
اگر درگاه به عنوان یک کانتینر یا سرویس مجزا اجرا شود، نیاز به ردیابی نسخه و مسئول به‌روزرسانی جداگانه دارد. ممکن است تیمی تصور کند چون نسخه اصلی GitLab به‌روز است، ایمن هستند، در حالی که AI Gateway همچنان بدون وصله و آسیب‌پذیر باقی مانده است. موجودی دارایی‌هایی که «GitLab» را به عنوان یک مورد واحد لیست می‌کنند، دقیقاً همان جزئی را پنهان می‌کنند که در اینجا اهمیت حیاتی دارد.
توپولوژی‌های استقرار
مستندات GitLab (در تاریخ ۴ اکتبر ۲۰۲۶) سه روش اصلی استقرار درگاه را شرح می‌دهد که هر کدام بار نگهداری متفاوتی دارند:
- GitLab.com / Dedicated: این حالت کاملاً توسط GitLab مدیریت می‌شود. این نسخه‌ها پیش از اعلام عمومی وصله شدند، بنابراین کاربرانی که از GitLab.com، GitLab Dedicated یا نمونه‌های Self-managed که از درگاه میزبانی‌شده توسط GitLab استفاده می‌کنند، نیازی به هیچ اقدامی ندارند.
- Hybrid: ترکیبی از درگاه‌های شخصی و مدل‌های مدیریت‌شده توسط GitLab بر اساس هر ویژگی. در این حالت، برخی ویژگی‌ها از مدل‌های مدیریت‌شده استفاده می‌کنند و کاملاً خارج از درگاه مشتری قرار دارند.
- Self-Hosted: درگاه و مدل‌ها کاملاً در زیرساخت مشتری اجرا می‌شوند. این روش کنترل کاملی بر مسیر هوش مصنوعی فراهم می‌کند و تضمین می‌کند هیچ پرامپت یا پاسخی از شبکه مشتری خارج نشود.
تنها در حالت‌های ترکیبی (Hybrid) و شخصی (Self-hosted)، مدیریت نسخه درگاه تحت کنترل تغییرات مشتری است. برای این کاربران، GitLab ارتقای فوری را توصیه می‌کند. از آنجا که با مشتریان Self-managed پیش از انتشار یادداشت عمومی تماس گرفته شده بود، تیم‌هایی که اعلان‌های فروشنده را دنبال می‌کنند ممکن است از پیش از اصلاحیه آگاه باشند.
گام‌های اصلاحی برای درگاه‌های شخصی
برای تیم‌هایی که درگاه خود را مدیریت می‌کنند، فرآیند اصلاح باید طبق ترتیبی خاص پیش برود تا هیچ نقطه کوری باقی نماند:
- شناسایی: یافتن تمام نمونه‌هایی که در آن‌ها یک AI Gateway شخصی در حال اجرا است. ثبت نسخه هر کدام و بررسی اینکه آیا برخی ویژگی‌ها از طریق حالت ترکیبی به درگاه میزبانی‌شده GitLab متصل می‌شوند یا خیر.
- ارتقا: انتقال درگاه‌های آسیب‌پذیر به نسخه‌های اصلاح‌شده (۱۹.۲.۴، ۱۹.۳.۲ یا ۱۹.۴.۱) در شاخه‌ای که با استقرار فعلی مطابقت دارد.
- چرخش اعتبارنامه‌ها: در صورتی که نمی‌توانید اطمینان حاصل کنید ارتقا به‌موقع انجام شده است، تمام اعتبارنامه‌های ارائه‌دهندگان (Provider Credentials) را که درگاه در اختیار دارد، تغییر دهید.
- پایش: لاگ‌های درگاه را در جایی قرار دهید که ابزارهای مانیتورینگ به آن‌ها دسترسی داشته باشند و یک بررسی نسخه (Version Check) را به گزارش‌های موجودی ماهانه اضافه کنید.
گسترش سطح حمله در عصر هوش مصنوعی
این حادثه یک الگوی رو به رشد در زنجیره تأمین هوش مصنوعی را برجسته می‌کند. همان‌طور که پلتفرم‌ها ویژگی‌های AI را جذب می‌کنند، اجزای جدیدی مانند درگاه‌های استنتاج، ذخیره‌سازهای برداری (Vector Stores)، شاخص‌های بازیابی (Retrieval Indices) و محیط‌های اجرای عامل (Agent Runtimes) را معرفی می‌کنند. این اجزا اغلب جدیدتر هستند و نسبت به برنامه‌های قدیمی که آن‌ها را احاطه کرده‌اند، کمتر در میدان نبرد تست شده‌اند.
از آنجا که این ابزارها اعتبارنامه‌های با سطح دسترسی بالا و جریان‌های داده خام را مدیریت می‌کنند، به اهداف اصلی مهاجمان تبدیل می‌شوند. برخورد با یک درگاه هوش مصنوعی به عنوان یک «ویژگی» (Feature) به جای یک «زیرساخت مستقل»، دقیقاً منجر به شکست‌های وصله‌گذاری می‌شود که در CVE-2026-90970 دیدیم.
یک مورد فرضی را در نظر بگیرید: یک تیم محصول ۳۰ نفره، Duo را به دلیل الزامات اقامت داده‌ها (Data Residency) به یک AI Gateway شخصی منتقل می‌کند تا مطمئن شود کدها و پرامپت‌ها در زیرساخت‌های داخل اتحادیه اروپا می‌مانند. در حالی که استقرار درست است، اما موجودی دارایی‌ها تغییر کرده است. سرویسی که یک سال پیش در تقویم وصله‌گذاری آن‌ها وجود نداشت، اکنون در مسیر هر پیشنهاد کد قرار دارد و اعتبارنامه‌های بک‌اند را نگه می‌دارد. اگر این جزء به خطر بیفتد، تضمین اقامت داده‌ها باطل شده و شبکه داخلی در معرض خطر قرار می‌گیرد.
تیم‌های امنیتی اکنون باید با AI Gateway به عنوان یک جزء دارای امتیاز ویژه (Privileged Component) برخورد کنند. این به معنای افزودن آن به گزارش‌های ماهانه نسخه، پایش لاگ‌های آن با هشارهای زبان ساده و اطمینان از داشتن یک ورودی اختصاصی در موجودی امنیتی است. درگاهی که در هیچ موجودی دارایی ظاهر نشود، وصله به وصله، بررسی‌های نسخه را در سکوت رد خواهد کرد و آسیب‌پذیر باقی می‌ماند.
گام بعدی شما
- بررسی فوری نسخه AI Gateway در زیرساخت‌های خود (جدا از نسخه هسته GitLab).
- به‌روزرسانی به نسخه‌های ۱۹.۲.۴، ۱۹.۳.۲ یا ۱۹.۴.۱.
- افزودن درگاه هوش مصنوعی به عنوان یک دارایی امنیتی مجزا در لیست موجودی (Inventory) سازمان.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو