دو حفرهٔ LiteLLM کلیدهای AI را می‌دزدید؛ نسخهٔ 1.83.9 مرز امن است

در تحلیل فنی منتشرشده در ۱۳ اکتبر ۲۰۲۶، Check Point Research دو نقص در دروازهٔ LiteLLM با شناسه‌های CVE-2026-35029 و CVE-2026-59823 را شرح داد و نسخهٔ 1.83.9 را مرز رفع هر دو دانست. حسابی با دسترسی محدود می‌توانست تنظیمات مدیریتی را تغییر دهد؛ مسیر جداگانه‌ای نیز اجازه می‌داد کلید API ارائه‌دهنده همراه درخواست به سروری خارج از مقصد معمول برسد. پژوهشگران این پیامدها را در محیط کنترل‌شده نشان دادند.

گزارش ۱۵ اکتبر ۲۰۲۶ ITPro پیامدهای احتمالی را تصرف حساب مدیر، اجرای کد و افشای کلیدهای ارائه‌دهندگان مدل توصیف کرد. انتشار یافته‌های پژوهشی به‌تنهایی نشان نمی‌دهد که کلید یک سازمان مشخص بیرون رفته باشد. تصمیم فوری برای هر نصب به نسخهٔ فعال دروازه، نوع دسترسی حساب‌ها و شواهد باقی‌مانده از درخواست‌ها بستگی دارد.

چگونه دسترسی محدود به تنظیمات مدیر می‌رسید؟

نقص کنترل دسترسی در مسیر POST /config/update قرار داشت؛ مسیری که پیکربندی در حال اجرای دروازه، از جمله متغیرهای محیطی و فهرست مدل‌ها را تغییر می‌دهد. ورود به رابط LiteLLM برای کاربر یک کلید موقت مرتبط با رابط می‌ساخت. بررسی مجوز، مسیرهایی را که با /config آغاز می‌شدند برای این نوع کلید مجاز می‌شمرد و خود تابع تغییر پیکربندی نیز نقش مدیر را دوباره بررسی نمی‌کرد. بنابراین کاربر دارای نشست معتبر، حتی با نقش محدود، به عملی می‌رسید که برای مدیر در نظر گرفته شده بود.

تغییر متغیرهای محیطی چند پیامد جدا داشت. با تغییر UI_LOGO_PATH، مسیر فایل خوانده‌شده از سوی /get_image قابل جابه‌جایی بود؛ آنچه خوانده می‌شد به مجوزهای فرایند LiteLLM وابسته می‌ماند. تغییر UI_USERNAME و UI_PASSWORD می‌توانست اعتبارنامهٔ حساب مدیر داخلی را عوض کند و به ورود با نقش PROXY_ADMIN برسد. این زنجیره توضیح می‌دهد چرا اشکالی در مجوز یک مسیر پیکربندی، به تصرف دروازه تبدیل می‌شد.

راه دیگر از قابلیت گذردهی درخواست‌ها می‌گذشت. پیکربندی مسیر گذردهی می‌توانست به ماژول پایتون در فضای ذخیره‌سازی بیرونی اشاره کند و دروازه هنگام راه‌اندازی آن مسیر، ماژول را بارگیری و اجرا کند. آزمایش پژوهشگران برای نشان دادن اجرای کد، یک پوشهٔ نشانه‌گذار ساخت؛ این نتیجه امکان اجرای کد روی میزبان را نشان می‌دهد، نه شمار سرورهایی را که در عمل تصرف شده‌اند. برای ارزیابی یک نصب قدیمی، تغییرات پیکربندی و دسترسی حساب‌های کم‌امتیاز باید در کنار هم دیده شوند.

مسیر جداگانهٔ افشای کلید چه بود؟

در نقص دوم، درخواست کاربری با کلید مجازی معتبر می‌توانست پارامتر user_config را در بدنه داشته باشد. LiteLLM برای این پارامتر مسیریاب تازه‌ای می‌ساخت، در حالی که بررسی ایمنی، api_base و base_url را در سطح اصلی درخواست محدود می‌کرد و مقدار تودرتوی api_base را نمی‌گرفت. به این ترتیب، مقصد خروجی درخواست از نشانی ارائه‌دهنده به نشانی انتخابی درخواست‌کننده تغییر می‌کرد.

در آزمایش، یک درخواست تولید پاسخ به‌جای سرویس مدل به سروری تحت کنترل آزمایشگر رسید و کلید API اصلی ارائه‌دهنده در سرآیندهای آن دیده شد. پیش‌شرط این سناریو داشتن کلید مجازی معتبر برای استفاده از دروازه بود؛ صرف آگاهی از نشانی عمومی دروازه کافی نبود. این مسیر به حساب مدیر احتیاج نداشت، پس اصلاح نقص مدیریت به‌تنهایی خطر انحراف درخواست را برطرف نمی‌کرد.

LiteLLM میان برنامه و خدماتی مانند OpenAI و Anthropic قرار می‌گیرد؛ کلید ارائه‌دهنده در این نقطه برای احراز هویت فراخوانی مدل استفاده می‌شود. اگر آن کلید به مقصد بیرونی برسد، دارندهٔ آن ممکن است با اعتبار همان سازمان درخواست بفرستد و برای سازمان هزینه ایجاد کند. ثبت مقصدهای خروجی و مصرف حساب نزد ارائه‌دهنده از این جهت مهم‌اند که نشانهٔ عملی افشا را از صرف وجود نسخهٔ آسیب‌پذیر جدا می‌کنند.

مرز نسخه‌ها برای هر نقص کجاست؟

اطلاعیهٔ امنیتی مخزن LiteLLM که در ۳ آوریل ۲۰۲۶ منتشر شد، نسخه‌های پیش از 1.83.0 را برای نقص دسترسی مدیریتی آسیب‌پذیر و 1.83.0 را نسخهٔ رفع آن ثبت می‌کند. بنابراین تاریخ انتشار تحلیل اکتبر، تاریخ ساخته شدن این وصله نیست. مرز 1.83.9 به این معناست که آن نسخه و نسخه‌های بعدی، اصلاح هر دو نقص مورد بحث را با هم دارند.

• اگر نسخهٔ در حال اجرا پیش از 1.83.0 باشد، هر دو مسیر در ارزیابی خطر مطرح‌اند: تغییر غیرمجاز تنظیمات مدیریتی و انحراف درخواست‌های حامل کلید.
• اگر نسخه از 1.83.0 تا پیش از 1.83.9 باشد، نقص دسترسی مدیریتی رفع شده، اما مسیر افشای کلید هنوز باید در نظر گرفته شود.
• از 1.83.9 به بعد، هر دو اصلاح حاضرند؛ این وضعیت دربارهٔ افشای احتمالی پیش از ارتقا حکمی نمی‌دهد.

ملاک، نسخهٔ فرایندی است که اکنون ترافیک را می‌گیرد، نه فقط عدد نوشته‌شده در فایل وابستگی یا تصویر آمادهٔ استقرار. اگر چند نمونه یا محیط وجود دارد، هر یک باید جداگانه دیده شود؛ یک نمونهٔ قدیمی می‌تواند همچنان درخواست دریافت کند. LiteLLM ممکن است در ابزار داخلی یا پلتفرم بزرگ‌تری تعبیه شده باشد، بنابراین بررسی تنها فهرست سرویس‌های مستقل همهٔ نصب‌ها را پوشش نمی‌دهد.

چه زمانی کلیدهای ارائه‌دهنده باید عوض شوند؟

ارتقا جلوی استفادهٔ تازه از این دو مسیر را می‌گیرد، اما اعتبار کلیدی را که پیش‌تر بیرون رفته باشد از بین نمی‌برد. اگر حساب ناشناس به دروازه دسترسی داشته، حساب محدود پیکربندی را تغییر داده، یا درخواستی به مقصد غیرمنتظره رفته است، تعویض کلیدهای ارائه‌دهندهٔ فعال در همان بازه اقدام احتیاطی موجهی است. پس از تصرف احتمالی حساب مدیر، تغییرهای پیکربندی و اعتبارنامه‌های مدیریتی نیز باید بررسی شوند، چون عوض کردن فقط کلید ارائه‌دهنده اثر آن تغییرها را حذف نمی‌کند.

برای تعیین دامنه، زمان اجرای نسخهٔ آسیب‌پذیر و فهرست حساب‌ها یا کلیدهای مجازی دارای دسترسی به آن را کنار هم بگذارید. سپس، اگر ثبت رویداد فعال بوده، درخواست‌های POST /config/update، تغییر متغیرهای محیطی، مسیرهای گذردهی و مقصدهای خروجی را در همان بازه بررسی کنید. مصرف و صورت‌حساب نزد ارائه‌دهنده می‌تواند درخواست نامعمول را آشکار کند؛ افزایش مصرف به‌تنهایی اثبات سرقت کلید نیست، ولی همراه با مقصد ناشناس یا تغییر بدون مجوز، اولویت تعویض کلید را بالا می‌برد.

نبودِ رویداد در گزارشی که آن نوع درخواست را ثبت نمی‌کرده، نشانهٔ سالم بودن نصب نیست. در چنین وضعی تصمیم دربارهٔ تعویض کلید به مدت قرار گرفتن نسخهٔ آسیب‌پذیر در دسترس حساب‌های معتبر و حساسیت کلیدهای ذخیره‌شده بستگی دارد. پس از تعویض، کلید قدیمی باید نزد ارائه‌دهنده باطل شود تا اگر نسخه‌ای از آن قبلاً بیرون رفته باشد، دیگر به حساب سازمان دسترسی ندهد.

بیشتر بخوانید:

• Docker یا Podman؛ سرعت تقریباً برابر است، مدل دسترسی تصمیم را عوض می‌کند
• حفرهٔ SharePoint فعالانه سوءاستفاده می‌شود؛ نصب وصله پایان بررسی نیست
• Google گزارش‌های آسیب‌پذیری متن‌باز را بست؛ سیل گزارش‌های خودکار مقصر است