آسیبپذیری SSRF تو MLflow؛ حملهها از روز اول شروع شده
هوش مصنوعیخلاصهٔ کاملتر
تیم امنیتی watchTowr یه آسیبپذیری جدی به اسم SSRF (یعنی وقتی سرور رو مجبور میکنی به جای خودت به یه آدرس دیگه درخواست بزنه) تو MLflow پیدا کرده که به مهاجمهای بدون احراز هویت اجازه میده به منابع داخلی شبکه یا سرویسهای متادیتای ابری دسترسی پیدا کنن. این آسیبپذیری با شناسه CVE-2026-64849 ثبت شده و همه نسخههای قبل از 3.15.0 رو شامل میشه.
ریشه مشکل تو تابع _validate_webhook_url ـه که از نسخه 3.10.0 اضافه شده بود تا جلوی SSRF رو بگیره. این گارد آدرس رو یه بار چک میکنه که عمومی باشه، ولی وقتی سرور یه ریدایرکت HTTP (مثلاً کد 302) میگیره، دیگه آدرس مقصد جدید رو دوباره بررسی نمیکنه. یعنی یه مهاجم میتونه یه آدرس عمومی معتبر بسازه که گارد رو رد کنه و بعد سرور رو به آدرسهای داخلی مثل 127.0.0.1 یا سرویس متادیتای ابری هدایت کنه.
چون endpoint تست webhook محتوای پاسخ رو مستقیم برمیگردونه، سرور MLflow عملاً نقش یه پراکسی رو بازی میکنه و اطلاعات داخلی رو به مهاجم لو میده. به گفته watchTowr، با ریدایرکتهای 307 و 308 که متد و بدنه درخواست اصلی رو حفظ میکنن، حتی میشه درخواستهای نوشتنی هم به سرویسهای داخلی مثل Docker daemon یا Spring Boot Actuator فرستاد.
نویسنده مقاله میگه چون API مربوط به webhookهای model registry تو خیلی از نصبهای پیشفرض MLflow فعال و بدون نیاز به احراز هویته، این مشکل خیلی خطرناکتر از یه SSRF معمولی حساب میشه. تیم watchTowr از طریق شبکه هانیپات جهانیشون به اسم Attacker Eye دیده که همین چند ساعت بعد از ثبت CVE، مهاجمها شروع به هدف قرار دادن سرورهای ابری MLflow برای سرقت credential و اطلاعات محرمانه کردن.
نگهدارندههای MLflow این مشکل رو تو نسخه 3.15.0 رفع کردن و به همه توصیه میکنن هر چه زودتر آپدیت کنن، لاگها رو برای نشونههای نفوذ چک کنن و ببینن آیا credential حساسی لو رفته یا نه.
نکات کلیدی:
- شناسه آسیبپذیری: CVE-2026-64849، یه SSRF بدون نیاز به احراز هویت
- همه نسخههای MLflow قبل از 3.15.0 آسیبپذیرن
- مشکل از عدم بررسی دوباره آدرس بعد از ریدایرکت HTTP میاد
- ریدایرکتهای 307/308 حتی امکان نوشتن (blind write) رو هم میدن
- مهاجمها همون چند ساعت اول بعد از ثبت CVE شروع به سوءاستفاده کردن
- راهحل: آپدیت فوری به نسخه 3.15.0
