فرض کنید یک سایتِ کوچکِ فروشِ اشتراک دارید. سایت روی وردپرس است، صورتحسابها را با WHMCS صادر میکنید و برای پشتیبانی هم یک چتباتِ هوش مصنوعی راه انداختهاید. ۲۱ اکتبر ۲۰۲۶ برای چنین کسی روزِ خوبی نبود، چون هر سه لایهٔ کارش همزمان خبرِ بد داشت. TechCrunch همان روز نوشت که اینترنت «روزِ امنیتیِ خیلی بدی» را میگذراند. دلیلش باگهای PHP بود که با کمکِ هوش مصنوعی پیدا شده بودند، بهعلاوهٔ نقصهایی در Node.js و در ابزارِ پرکاربردِ LiteLLM. در این نوشته هر سه را جدا باز میکنیم و میگوییم آسیبپذیری PHP2Shell و ماجرای LiteLLM به کارِ شما چه ربطی دارد.
در یک نگاه
در ۲۱ اکتبر ۲۰۲۶ دو آسیبپذیریِ بحرانیِ PHP با نامِ PHP2Shell (امتیازِ ۹٫۲) افشا و وصله شد. همان روز Node.js هم وصلههای امنیتی داد و نسخهٔ آلودهٔ LiteLLM 1.107.0 حدودِ ۲ ساعت روی PyPI ماند. صاحبانِ سایت باید PHP را به نسخهٔ وصلهشدهٔ شاخهٔ خود برسانند. کاربرانِ LiteLLM هم باید وضعیتِ نصب و کلیدهایشان را با متخصصِ امنیت بررسی کنند.
- آسیبپذیری PHP2Shell دو باگ با شناسههای CVE-2026-109618 و CVE-2026-109619 در PHP نسخهٔ ۵.۴ تا ۸.۵ است که اجرای کد از راه دور و بدون ورود به حساب را ممکن میکند.
- نسخههای وصلهشدهٔ PHP که ۲۱ اکتبر ۲۰۲۶ منتشر شدند 8.5.12، 8.4.27، 8.3.36 و 8.2.35 هستند و هر شاخه باید به نسخهٔ وصلهشدهٔ خودش برسد.
- پژوهشگران در کشفِ PHP2Shell از مدلهای هوش مصنوعی مثلِ GPT-5.6 Sol و Gemini 4 Argon کمک گرفتند.
- نسخهٔ آلودهٔ LiteLLM 1.107.0 در ۲۱ اکتبر ۲۰۲۶ روی PyPI و ایمیجهای Docker پروژه منتشر شد و حدودِ ۲ ساعت روی PyPI ماند.
- به گزارشِ Chainguard، مهاجمِ LiteLLM احتمالاً با توکنهای سرقتشدهٔ GitHub CLI به خطِ انتشارِ پروژه راه پیدا کرده است.
در ۲۱ اکتبر ۲۰۲۶ دقیقاً چه اتفاقی افتاد؟
سه خطرِ جدا در یک روز رخ داد: باگِ بحرانی در PHP، وصلههای امنیتیِ Node.js و انتشارِ نسخهٔ آلودهٔ LiteLLM. این سه رخدادِ جدا بودند و هر کدام به گروهِ متفاوتی از سایتها و ابزارها مربوط میشود.
PHP زبانی است که سمتِ سرور کار میکند و پشتِ وردپرس و خیلی از فروشگاههای اینترنتی است. Node.js محیطی برای اجرای جاوااسکریپت روی سرور است. LiteLLM هم درگاهی متنباز است، یعنی یک دروازهٔ واحد که برنامه از آن به چند مدلِ زبانیِ مختلف وصل میشود.
جدولِ زیر خلاصهٔ هر سه را نشان میدهد تا ببینید کدام به شما مربوط است.
- مورد: PHP2Shell · چه شد؟: دو آسیبپذیریِ اجرای کد از راه دور در PHP نسخهٔ ۵.۴ تا ۸.۵؛ وصله در ۲۱ اکتبر ۲۰۲۶ · چه کسی باید نگران باشد؟: صاحبانِ سایتهای وردپرس، فروشگاهها و پنلهای هاستینگ
- مورد: Node.js · چه شد؟: وصلهٔ چند آسیبپذیری، از جمله باگِ اجرای کد در رمزگشای Brotli · چه کسی باید نگران باشد؟: توسعهدهندگان و سرویسهایی که روی Node.js کار میکنند
- مورد: LiteLLM · چه شد؟: انتشارِ نسخهٔ آلودهٔ 1.107.0 روی PyPI و Docker · چه کسی باید نگران باشد؟: تیمهایی که برای اتصال به مدلهای زبانی از LiteLLM استفاده میکنند
آسیبپذیری PHP2Shell چیست و چرا اینقدر جدی است؟
PHP2Shell نامِ دو آسیبپذیری با شناسههای CVE-2026-109618 و CVE-2026-109619 است. با آنها میشود از راه دور روی سرور کد اجرا کرد. به این نوع باگ RCE میگویند، یعنی مهاجم بیآنکه به سرور دسترسیِ فیزیکی داشته باشد، کدِ خودش را رویش اجرا میکند. اینکه بعد از آن دقیقاً چه کاری از دستش برمیآید، به سطحِ دسترسیِ برنامه و تنظیماتِ سرور بستگی دارد.

شدتِ هر دو در مقیاسِ CVSS v4.0 برابرِ ۹٫۲ از ۱۰ اعلام شده است. CVSS معیاری استاندارد برای نمرهدادن به خطرناکیِ باگهاست. چیزی که خطر را بیشتر میکند این است که مهاجم برای سوءاستفاده لازم نیست وارد هیچ حسابی شود.
دامنهٔ ماجرا هم بزرگ است. به گفتهٔ Wiz Research، حدودِ ۷۰٪ وبسایتهای دنیا با PHP کار میکنند. این عدد برآوردِ خودِ Wiz است. همین شرکت میگوید همهٔ نسخههای دههٔ اخیر تا نسخهٔ ۵.۴ دستکم به یکی از این دو باگ آلودهاند.
پژوهشگران نشان دادند که از این راه میشود روی برنامههای آشنایی کد اجرا کرد: WordPress، Drupal، Joomla، Magento، phpMyAdmin، Nextcloud، Laravel و WHMCS. نامِ WHMCS برای ما مهم است، چون خیلی از سایتهای فروشِ اشتراک و هاستینگ با آن صورتحساب و حسابهای مشتری را مدیریت میکنند.
اگر سایتِ PHP دارید، الان باید سراغِ چه بروید؟
پاسخِ کوتاه این است که PHP باید به نسخهٔ وصلهشده برسد. وصله یعنی بهروزرسانیای که فقط همان سوراخِ امنیتی را میبندد. نسخههای وصلهشده ۲۱ اکتبر ۲۰۲۶ منتشر شدند و هر شاخه باید به نسخهٔ وصلهشدهٔ خودش برسد:
- شاخهٔ 8.5 → نسخهٔ 8.5.12
- شاخهٔ 8.4 → نسخهٔ 8.4.27
- شاخهٔ 8.3 → نسخهٔ 8.3.36
- شاخهٔ 8.2 → نسخهٔ 8.2.35
آیا فایروالِ کلادفلر یا خاموشکردنِ سایت کافی است؟
فایروال کمک میکند، اما جای وصله را نمیگیرد. فایروالِ برنامهٔ وب (WAF) لایهای است که درخواستهای مشکوک را پیش از رسیدن به سایت میگیرد. WAFِ کلادفلر از ساعتِ ۳:۰۲ بامدادِ ۲۱ اکتبر ۲۰۲۶ به وقتِ UTC تلاشها برای سوءاستفاده از PHP2Shell را مسدود کرد. این حدودِ ۹ ساعت پیش از افشای عمومی بود و پلنِ رایگان را هم پوشش میداد.
این خبرِ خوبی است، اما فایروال فقط الگوهای حملهٔ شناختهشده را میگیرد. اگر مهاجم راهِ تازهای برای رسیدن به همان باگ پیدا کند، سرورِ وصلهنشده هنوز باز است. پس فایروال را لایهٔ دوم بدانید و وصله را لایهٔ اول.
بعضیها راهِ محتاطانهتری رفتند. برخی وبسایتها، از جمله سایتهای دولتی در چند کشورِ اروپایی، موقتاً از دسترس خارج شدند. این تصمیم برای سرویسی که مشتریِ پولی دارد هزینه دارد. اینکه سایتِ شما هم باید چنین کند یا نه، تصمیمی است که باید با مدیرِ سرور یا متخصصِ امنیت بگیرید.
اگر هنوز شاخهای قدیمیتر از 8.2 دارید، در منابعِ ما نسخهٔ وصلهشدهای برایش فهرست نشده است. برنامهٔ ارتقا و آزمودنِ سازگاریِ افزونهها کارِ متخصص است. اگر هاستِ اشتراکی دارید، اول از شرکتِ هاستینگ بپرسید که PHP را وصله کرده یا نه.
هوش مصنوعی چطور به کشفِ PHP2Shell کمک کرد؟
این باگها را آدمها با کمکِ مدلهای هوش مصنوعی پیدا کردند. ریان آستین، پژوهشگرِ شرکتِ امنیتیِ Calif، این آسیبپذیری را در اوتِ ۲۰۲۶ مستقلاً پیدا کرد. او در چارچوبِ پروژهٔ «Patch the Planet» شرکتِ OpenAI کار میکرد و از مدلِ GPT-5.6 Sol کمک گرفت. تیمهای OpenAI و Wiz هم در کشف نقش داشتند.
طرفِ دیگرِ ماجرا Google است. به گفتهٔ Google Cloud، تیمِ Wiz Research در کشف و رفعِ این باگها از چند مدل استفاده کرد. مدلِ Gemini 4 Argon در کشفِ آسیبپذیری، ساختِ اکسپلویت، تشخیصِ حمله و اعتبارسنجیِ وصله نقش داشت. اکسپلویت یعنی کدِ آزمایشیای که نشان میدهد باگ واقعاً قابلِ سوءاستفاده است.
برداشتِ ما این است که این خبر شمشیرِ دولبه است. اگر مدافعان با هوش مصنوعی در کدی به این قدمت باگِ بحرانی پیدا میکنند، مهاجمان هم میتوانند همین ابزارها را به کار بگیرند. نتیجهٔ عملیاش برای صاحبِ سایت ساده است: فاصلهٔ افشای باگ تا حمله احتمالاً کوتاهتر میشود، پس وصلهکردن را نباید عقب انداخت.
در Node.js کدام آسیبپذیریها وصله شدند؟
Node.js هم در همین روز وصلههای امنیتی داد. جدیترینِ آنها CVE-2026-111497 است: یک «نوشتنِ خارج از محدوده» در رمزگشای Brotli که اجرای کد از راه دور را ممکن میکند.

Brotli روشی برای فشردهسازیِ داده است که سایتها برای سریعترکردنِ بارگذاری به کار میبرند. «نوشتنِ خارج از محدوده» یعنی برنامه داده را بیرون از فضای حافظهای که برایش کنار گذاشته شده مینویسد. مهاجم گاهی از همین بینظمی برای اجرای کدِ خودش استفاده میکند.
سه آسیبپذیری با شدتِ بالا هم در بررسیِ نامِ میزبان در گواهیِ TLS و در پردازشِ نامهای DNS پیدا شد. گواهیِ TLS همان چیزی است که قفلِ کنارِ نشانیِ سایت را نشان میدهد. اگر سرویس یا رباتتان روی Node.js است، بهروزرسانی را به توسعهدهنده بسپارید و پیگیرش باشید.
ماجرای LiteLLM: وقتی خودِ ابزارِ هوش مصنوعی هدف میشود
LiteLLM قربانیِ حملهٔ زنجیرهٔ تأمین شد. در این نوع حمله، نسخهٔ دستکاریشدهای از بستهٔ نرمافزاری از همان کانالهایی منتشر میشود که کاربران به آنها اعتماد دارند. خطرش این است که کاربر بیخبر نسخهٔ آلوده را به جای نسخهٔ سالم نصب کند.
در ۲۱ اکتبر ۲۰۲۶ نسخهٔ آلودهٔ LiteLLM 1.107.0 روی PyPI و برچسبهای ایمیجِ Docker خودِ پروژه منتشر شد. PyPI مخزنِ رسمیِ بستههای پایتون است. پروژه رخداد را رسماً تأیید کرد و بستهها را از PyPI، Docker Hub و GHCR حذف کرد.
نسخهٔ آلوده از ۱۱:۳۹ تا ۱۳:۲۳ به وقتِ UTC روی PyPI بود، یعنی حدودِ ۲ ساعت. بعد PyPI آن را قرنطینه کرد. دو ساعت کوتاه به نظر میرسد، اما سیستمهایی که خودکار آخرین نسخه را نصب میکنند، ممکن بود در همین فاصله آن را بگیرند.
راهِ ورودِ مهاجم هم آموزنده است. به گزارشِ Chainguard، به نظر میرسد او با توکنهای OAuthِ سرقتشدهٔ GitHub CLI متعلق به توسعهدهندگان به خطِ انتشارِ پروژه رسیده است. توکن نوعی کلیدِ دیجیتال است که به برنامه اجازه میدهد بدونِ وارد کردنِ رمز، از طرفِ شما کار کند.
این اولین گرفتاریِ امنیتیِ LiteLLM در ۲۰۲۶ هم نبود. CISA، نهادِ امنیتِ سایبریِ آمریکا، آسیبپذیریِ تزریقِ فرمانِ CVE-2026-42271 با امتیازِ CVSS برابرِ ۸٫۷ را در فهرستِ KEV گذاشته بود. KEV فهرستِ باگهایی است که در عمل از آنها سوءاستفاده شده است. آن باگ نسخههای 1.74.2 تا 1.83.6 را درگیر میکرد. این فهرست برای نهادهای آمریکایی اهمیتِ اجرایی دارد و مقرراتِ لازمالاجرا در ایران نیست، اما نشانهٔ خوبی از جدیبودنِ خطر است.
اگر کلید API یا LiteLLM دارید، قدمِ بعدی چیست؟
اول بفهمید آیا نسخهٔ 1.107.0 در سیستمتان نصب شده یا نه. کلیدِ API رمزی است که برنامه با آن از یک سرویس استفاده میکند و هزینهاش به حسابِ شما نوشته میشود. در شواهدی که ما دیدیم نیامده که در این رخداد کلیدی دزدیده یا افشا شده باشد.
با این حال، اگر نسخهٔ آلوده روی سیستمی نصب بوده که کلیدهای API در آن تعریف شدهاند، احتیاط حکم میکند تعویضِ آن کلیدها را جدی بررسی کنید. «احتمالِ دسترسی» با «افشای قطعی» یکی نیست، و تشخیصِ اینکه وضعِ شما کدام است کارِ متخصص است.
بررسیِ سیستم، تعویضِ کلیدها و پاکسازی کارِ فنیِ حساسی است. ترتیبِ درستش به معماریِ سرویسِ شما بستگی دارد. تصمیم و اجرا را به متخصصِ امنیتِ دارای صلاحیت بسپارید و اطلاعیهٔ رسمیِ LiteLLM را مرجعِ اصلی بدانید.
برای کاربرِ عادی هم درسی در این ماجرا هست. حمله از توکنهای دزدیدهشدهٔ توسعهدهندگان شروع شد، نه از یک باگِ پیچیده. سه عادتِ ساده جلوی بخشِ بزرگی از چنین اتفاقهایی را میگیرد: رمزِ قوی و جدا برای هر حساب، روشنکردنِ ورودِ دومرحلهای، و شککردن به ایمیلها و پیامهایی که شما را به صفحهٔ ورود میبرند. صفحهٔ ورودِ جعلی، یا همان فیشینگ، هنوز یکی از سادهترین راههای سرقتِ حساب است.
پرسشهای پرتکرار
من فقط از سایتها استفاده میکنم. آیا آسیبپذیری PHP2Shell به من مربوط است؟
مستقیماً نه. این باگها روی سرورِ سایتها هستند و وصلهکردنشان کارِ مدیرِ سایت است. کارِ شما مراقبت از حسابهایتان است: رمزِ قوی، ورودِ دومرحلهای و دوری از لینکهای مشکوک.
سایتم وردپرسی است. آیا در خطر است؟
وردپرس در فهرستِ برنامههایی بود که پژوهشگران روی آنها اجرای کد را نشان دادند. باید PHP سرورتان به نسخهٔ وصلهشدهٔ شاخهٔ خودش برسد: 8.5.12، 8.4.27، 8.3.36 یا 8.2.35. از هاستینگ یا متخصصِ فنی بخواهید وضعیت را بررسی کند.
اگر از کلادفلر استفاده میکنم، دیگر لازم نیست PHP را بهروز کنم؟
لازم است. WAFِ کلادفلر از ۲۱ اکتبر ۲۰۲۶ حملههای شناختهشدهٔ PHP2Shell را حتی در پلنِ رایگان مسدود کرد، اما فایروال جای وصله را نمیگیرد.
LiteLLM نصب کردهام. از کجا بفهمم نسخهٔ آلوده را گرفتهام؟
نسخهٔ آلوده 1.107.0 بود و ۲۱ اکتبر ۲۰۲۶ حدودِ ۲ ساعت روی PyPI و همچنین روی ایمیجهای Docker پروژه در دسترس بود. بررسیِ نسخهٔ نصبشده و اقدامهای بعدی را با متخصصِ امنیت و بر پایهٔ اطلاعیهٔ رسمیِ LiteLLM انجام دهید.
جمعبندی
۲۱ اکتبر ۲۰۲۶ دو تصویرِ همزمان از هوش مصنوعی نشان داد. از یک طرف، مدلهایی مثلِ GPT-5.6 Sol و Gemini 4 Argon به پژوهشگران کمک کردند تا در PHP باگی پیدا کنند که سالها پنهان مانده بود. از طرفِ دیگر، LiteLLM که ابزاری برای اتصال به همین مدلهاست، خودش راهِ ورودِ مهاجم شد. اگر سایتِ PHP دارید، وصله را عقب نیندازید. اگر کلیدِ API در ابزارهای هوش مصنوعی دارید، وضعیتش را با یک متخصص بررسی کنید. و اگر فقط کاربرید، همان سه عادتِ همیشگی را جدی بگیرید: رمزِ قوی، ورودِ دومرحلهای و چشمِ باز در برابرِ فیشینگ.





نظرها
هنوز نظری ثبت نشده. اولین نفری باشید که نظر میدهد.
نظر شما