اگر امروز از کتابخانه‌های پایتون برای مدیریت مدل‌های زبانی استفاده می‌کنید، احتمالاً متوجه نیستید که یک دستور ساده‌ی pip install می‌تواند تمام کلیدهای امنیتی زیرساخت شما را در کمتر از ۱۵ دقیقه تخلیه کند. این اتفاق دقیقاً برای هزاران توسعه‌دهنده در ۲۴ مارس ۲۰۲۶ رخ داد.
یک شکاف زمانی ۱۳ دقیقه‌ای بین دو انتشار مخرب در PyPI، تقریباً تمام دسترسی‌های حساس سیستم‌های عامل‌های هوش مصنوعی را به گروه هکری TeamPCP تقدیم کرد. طبق گزارش‌های منتشر شده، دو نسخه آلوده از LiteLLM (نسخه‌های ۱.۸۲.۷ و ۱.۸۲.۸) در فهرست بسته‌های پایتون (PyPI) آپلود شدند. این کتابخانه که ماهانه بیش از ۹۵ میلیون بار دانلود می‌شود، تبدیل به یک اسب تروجان برای هر سیستمی شد که از وابستگی‌های بدون نسخه (Unpinned Dependencies) استفاده می‌کرد و اکثر تیم‌هایی که استک‌های عامل‌محور (Agent Stacks) را اجرا می‌کردند، هیچ فرآیندی برای شناسایی این نفوذ نداشتند.
این حادثه ضعف ساختاری در استقرار زیرساخت‌های هوش مصنوعی را برملا می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی خطرات سرورهای MCP و افشای داده‌های CRM اشاره کردیم، اکنون ثابت شده که «درِ ورودی» یا همان گیت‌وی (Gateway) سیستم‌های عامل‌محور، هدف اصلی حملات زنجیره تأمین است. این سرعت بالای نفوذ در زیرساخت‌های هوش مصنوعی، یادآور گزارشات اخیر است که نشان می‌دهد زمان نفوذ به شبکه‌ها از دو هفته به تنها ۱۰ ساعت کاهش یافته است و مهاجمان اکنون با سرعت بسیار بیشتری به اهداف خود می‌رسند. برای اکثر برنامه‌نویسان، تنها سد دفاعی بین یک محیط امن و نشت کامل اعتبارنامه‌ها، یک دستور نصب ساده است. من ابزارهای امنیتی برای عامل‌های هوش مصنوعی می‌سازم، از جمله mcpscan برای شناسایی الگوهای خطرناک، secops-toolkit-mcp برای جریان‌های کاری عامل‌ها و agent-memory-protocol برای حافظه‌های قابل بازرسی. بیشتر زمان من صرف یک سؤال می‌شود: چه کسی کنترل درِ ورودی یک سیستم عامل‌محور را در دست دارد؟ این حادثه دقیقاً همان داستانی است که من مدام درباره‌اش هشدار می‌دادم.
کالبدشکافی رخنه
به نقل از هشدار سایبری NHS England، بسته‌های مخرب از ساعت ۱۰:۳۹ UTC فعال بودند تا اینکه در ساعت ۱۳:۳۸ همان روز قرنطینه شدند. اگرچه وبلاگ رسمی LiteLLM بازه زمانی کوتاه‌تری (۴۰ دقیقه) را گزارش کرده است، اما این اختلاف نشان‌دهنده عدم قطعیت در ردیابی خط زمانی حملات زنجیره تأمین است. در هر صورت، این پنجره زمانی برای اجرای یک دستور نصب و سرقت کلیدهای SSH، توکن‌های ابری و اسرار کوبرنتیز (Kubernetes secrets) کاملاً کافی بود.
مهاجمان به کد اصلی LiteLLM نفوذ نکردند؛ بلکه اعتبارنامه‌های انتشار در PyPI را از طریق یک اکشن GitHub compromised در ابزار Trivy سرقت کردند که در خط لوله CI قرار داشت. طنز تلخ ماجرا اینجاست که Trivy یک اسکنر آسیب‌پذیری است؛ یعنی یک ابزار امنیتی، نقطه ورود مهاجمان شد. LiteLLM بعدها تأیید کرد که نفوذ به Trivy مهار شده و نسخه‌های آلوده حذف شده‌اند.
دو مرحله عفونی
حمله در دو نسخه به‌سرعت تکامل یافت:
- نسخه ۱.۸۲.۷ (۱۰:۳۹ UTC): کد مخرب در فایل
proxy_server.pyتزریق شد. این محموله (Payload) به‌طور خاص زمانی فعال می‌شد که ماژول پروکسی LiteLLM توسط کاربر Import می‌شد. - نسخه ۱.۸۲.۸ (۱۰:۵۲ UTC): این نسخه تزریق قبلی را حفظ کرد اما فایلی به نام
litellm_init.pthرا به بسته اضافه کرد.
از آنجا که فایل‌های .pth در هر بار شروع مفسر پایتون در آن محیط اجرا می‌شوند، بدافزار دیگر منتظر فراخوانی کتابخانه توسط کاربر نمی‌ماند. به محض نصب، هر پردازش پایتون در آن سرور، کد مخرب را به‌طور خودکار اجرا می‌کرد.
دامنه تخریب و محموله مخرب
بر اساس مستندات Sonatype (هشدار sonatype-2026-001357) و پایگاه داده آسیب‌پذیری‌های پایتون (PYSEC-2026-2)، این بدافزار در سه مرحله برای استخراج موارد زیر طراحی شده بود:
- کلیدهای SSH و توکن‌های ارائه‌دهندگان ابری
- اسرار کوبرنتیز (Kubernetes secrets) و حساب‌های سرویس (Service Accounts)
- اعتبارنامه‌های پایگاه داده و کیف پول‌های کریپتو
- تمامی کلیدهای API مدل‌های زبانی (LLM) که توسط گیت‌وی مدیریت می‌شدند
این بدافزار همچنین مکانیزم‌های پایداری (Persistence) را نصب کرد تا پس از ری‌بوت سیستم نیز فعال بماند. طبق گزارش JFrog، در نهایت PyPI برای توقف گسترش، کل پروژه litellm را از جمله تمام نسخه‌های آن قرنطینه کرد.
چرا گیت‌وی‌ها هدف‌های ارزشمندی هستند؟
یک گیت‌وی مدل زبانی، شبیه به یک گلوگاه ساختاری است. برخلاف یک کتابخانه معمولی، گیت‌وی کلیدهای API تمام ارائه‌دهندگان در جدول مسیریابی یک مستاجر، به علاوه آدرس‌های URL پایگاه داده برای لاگ‌ها و محدودیت نرخ (Rate Limiting) را در اختیار دارد. اگر گیت‌وی سقوط کند، مهاجم به کل مستاجر (Tenant) دسترسی پیدا می‌کند، نه فقط یک قابلیت خاص.
در سیستم‌های عامل‌محور (Agentic)، این ریسک به دلایل زیر چند برابر می‌شود:
۱. پردازش‌های طولانی‌مدت: عامل‌ها معمولاً به صورت پردازش‌هایی اجرا می‌شوند که طبق برنامه خودشان ری‌استارت می‌شوند.
۲. محرک‌های خودکار: ترفند فایل .pth باعث می‌شود بدافزار نیازی به فراخوانی یک تابع خاص نداشته باشد؛ یک ری‌استارت شبانه تبدیل به ماشه استخراج داده‌ها می‌شود.
۳. دامنه تخریب گسترده: اعتبارنامه‌های درگیر، فقط کلیدهای چت نیستند، بلکه ریشه زیرساخت یعنی توکن‌های ابری و حساب‌های سرویس کوبرنتیز هستند.
شکست وابستگی‌های بدون نسخه
بسیاری از پروژه‌های عامل‌محور از فایل‌های requirements بدون ذکر نسخه استفاده می‌کنند (مثلاً فقط نوشتن litellm و openai و anthropic بدون شماره نسخه). این یعنی سیستم در زمان بیلد، جدیدترین نسخه را می‌گیرد. در این حادثه، خط لوله‌های CI به‌طور خودکار «سم» را در لحظه انتشار در PyPI دریافت کردند. وابستگی‌های بدون نسخه، سرعت حذف بسته توسط PyPI را بی‌اثر می‌کنند، چون بیلد بعدی شما دوباره نسخه آلوده را برایتان می‌کشد.
برای جلوگیری از این اتفاق، متخصصان امنیتی توصیه می‌کنند نسخه‌ها را دقیقاً قفل کنید (مثلاً litellm==1.82.6) یا در حالت ایده‌آل، از Hash Pinning از طریق pip-compile (از ابزار pip-tools) در حالت هش استفاده کنید. با فعال کردن require-hashes در هنگام نصب، بیلد هر بسته‌ای را که با امضای رمزنگاری ثبت‌شده مطابقت نداشته باشد، رد می‌کند. این مهم‌ترین تغییری است که تیم‌های فعال در حوزه عامل‌های هوش مصنوعی باید اعمال کنند.
بازیابی و کاهش اثرات
اگر مشکوک به نفوذ هستید، اولین قدم یک بررسی حداقلی است: دستور pip show litellm را اجرا کنید. اگر نسخه ۱.۸۲.۷ یا ۱.۸۲.۸ است و در تاریخ ۲۴ مارس یا بعد از آن نصب شده، ماشین را آلوده فرض کنید.
برای کسانی که تحت تأثیر قرار گرفته‌اند، توصیه می‌شود محیط را کاملاً بازسازی کنند:
- جداسازی: ماشین را فوراً از شبکه جدا کنید.
- چرخش کلیدها (Rotate): هر اعتبارنامه‌ای که ماشین به آن دسترسی داشته را تغییر دهید: کلیدهای LLM، توکن‌های ابری، کلیدهای SSH، اسرار کوبرنتیز و رمزهای دیتابیس.
- بازسازی: سعی نکنید سیستم را در جای خود پاک‌سازی کنید. چون مکانیزم‌های پایداری بدافزار پس از ری‌بوت باقی می‌مانند، محیط باید از صفر بازسازی شود.
- ممیزی: لاگ‌های خروجی (Egress logs) را از ۲۴ مارس به بعد برای شناسایی فعالیت‌های مشکوک بررسی کنید.
کسانی که از ایمیج رسمی LiteLLM Proxy Docker استفاده می‌کردند، تا حد زیادی محافظت شدند زیرا این ایمیج وابستگی‌های خود را به‌طور داخلی قفل کرده و یک آرتیفکت تغییرناپذیر (Immutable) ایجاد می‌کند. اگر گیت‌وی شما اهمیت دارد، آن را به صورت یک ایمیج ساخته شده عرضه کنید، نه به صورت یک pip install روی یک ماشین مجازی فراموش‌شده.
الگوی گسترده‌تر
این کمپین تنها به یک کتابخانه محدود نبود. گزارش‌ها گروه TeamPCP را به تلاش‌های مشابه علیه خودِ Trivy، Checkmarx KICS، TanStack و Telnyx SDK مرتبط می‌کنند. درس این است که ابزارهای امنیتی و زیرساخت‌های هوش مصنوعی اکنون سطح حمله با امتیازات بالای یکسانی دارند، زیرا با همان دسترسی‌ها روی همان ماشین‌ها اجرا می‌شوند.
ما باید با گیت‌وی‌های LLM مانند زیرساخت‌های تولیدی (Production) و با یک فرآیند تغییر رسمی برخورد کنیم. اجازه ندهید CI درباره نسخه گیت‌وی شما تصمیم بگیرد. نسخه‌ها را قفل کنید، هش کنید و با بررسی انسانیِ لیست تغییرات (Changelog)، آن‌ها را به‌روز کنید. مهاجم در عرض ۱۳ دقیقه روی یک بسته با ۹۵ میلیون دانلود تغییرات ایجاد کرد؛ دفاع شما نمی‌تواند این باشد که «من متوجه می‌شوم». دفاع شما باید این باشد که «بیلد من کد ناشناخته را نمی‌پذیرد».
گام بعدی شما
- دستور
pip show litellmرا اجرا کنید؛ اگر نسخه ۱.۸۲.۷ یا ۱.۸۲.۸ است و بعد از ۲۴ مارس نصب شده، سیستم را آلوده فرض کنید. - در صورت آلودگی، محیط را کاملاً تخریب و بازسازی کنید؛ پاک‌سازی دستی به‌دلیل مکانیزم‌های پایداری بدافزار کافی نیست.
- تمام کلیدهای API، توکن‌های ابری و رمزهای دیتابیس را فوراً تغییر دهید (Rotate).
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو