PHP2Shell؛ باگ بحرانی PHP که ۷۰٪ سایت‌ها را تهدید می‌کند و راه رفع آن

دیروز، ۲۹ مهر ۱۴۰۵ (۲۱ اکتبر ۲۰۲۶) ، تیم امنیت PHP دو آسیب‌پذیری بحرانی را وصله کرد که حالا همه با اسم PHP2Shell می‌شناسندشان. اسمش خودش داستان را می‌گوید: از PHP تا شِل (Shell) ، یعنی مهاجم بدون نام کاربری و رمز، فقط با یک درخواست دست‌کاری‌شده، می‌تواند روی سرور شما فرمان اجرا کند. PHP پشت حدود ۷۰ درصد سایت‌های دنیاست، از وردپرس و دروپال تا فروشگاه‌های مجنتو، پس این خبر تقریباً به همه‌مان مربوط است.

من خودم سال‌هاست با PHP و وردپرس کار می‌کنم و همین وبلاگ هم روی وردپرس است. برای همین از دیشب منابع رسمی را خواندم و در این نوشته به زبان ساده توضیح می‌دهم PHP2Shell دقیقاً چیست، چقدر خطرناک است، چه کسانی هشدار دادند و از همه مهم‌تر، چطور سرور یا هاست خودتان را امن کنید.

آسیب‌پذیری PHP2Shell چیست؟

PHP2Shell نام دو آسیب‌پذیری در هستهٔ خود PHP است، نه در یک افزونه یا یک فریم‌ورک خاص:

• CVE-2026-109618: خرابی حافظه هنگام خطای کمبود حافظه (Out of Memory) . مهاجم با یک درخواست multipart/form-data خاص، PHP را وسط پردازش درخواست به سقف حافظه می‌رساند؛ PHP کار را نیمه‌کاره رها می‌کند و بخشی از حافظه در وضعیت نامعتبر می‌ماند. همین وضعیت نامعتبر راه اجرای کد را باز می‌کند.
• CVE-2026-109619: استفاده پس از آزادسازی (Use-After-Free) در وضعیتی که بین درخواست‌ها باقی می‌ماند. یعنی درخواست بعدیِ همان پروسهٔ PHP ممکن است به حافظه‌ای دست بزند که درخواست قبلی آزادش کرده بود.

هر دو امتیاز 9.2 از 10 در استاندارد CVSS نسخهٔ ۴ گرفته‌اند و برچسب «بحرانی» (Critical) دارند. نکتهٔ ترسناک ماجرا این است که حمله پیش از اجرای کد برنامهٔ شما اتفاق می‌افتد. یعنی حتی اگر کد سایتتان بی‌نقص باشد، باز هم آسیب‌پذیرید، چون مشکل در خود زبان است.

چه سایت‌ها و نسخه‌هایی در خطرند؟

طبق اطلاعیهٔ رسمی php.net، همهٔ نصب‌های PHP که درخواست وب پاسخ می‌دهند در خطرند: PHP-FPM، آپاچی با mod_php، php-cgi، FrankenPHP و LiteSpeed. تیم PHP خطر را برای mod_php از همه بیشتر می‌داند، چون آنجا اکسپلویت حتی قبل از رسیدن درخواست به کد برنامه کار می‌کند.

از نظر نسخه هم، مسیر آسیب‌پذیر از PHP 5.4 (سال ۲۰۱۲) وجود داشته؛ یعنی حدود ۱۴ سال. محققان Calif اجرای کد از راه دور بدون احراز هویت را روی نسخه‌های تازهٔ این برنامه‌ها نشان داده‌اند: WordPress، Drupal، Joomla، Magento، MediaWiki، phpMyAdmin، Nextcloud، Roundcube، Laravel، Symfony و WHMCS. اگر سایت شما با یکی از این‌ها یا هر برنامهٔ PHP دیگری کار می‌کند، این نوشته برای شماست.

چه کسی PHP2Shell را پیدا کرد؟ هوش مصنوعی!

جالب‌ترین بخش ماجرا برای من همین‌جاست. این باگ را دو تیم مستقل پیدا کردند و هر دو از مدل‌های هوش مصنوعی کمک گرفتند:

• رایان آستین (Ryan Austin) از شرکت Calif، در قالب پروژه‌ای با OpenAI و با کمک مدل GPT-5.6 Sol. طبق گزارش Calif، باگ اول ۱۱ اوت گزارش شد و تیم PHP چهار روز بعد تأیید کرد که اکسپلویت کار می‌کند.
• تیم تحقیقاتی Wiz (که حالا بخشی از گوگل است) ، با ابزار داخلی خودش و مدل‌های Gemini 4 Argon و GPT-5.6 Sol.

جالب اینکه نشانه‌های اولیهٔ یکی از این مشکل‌ها در یک ممیزی امنیتی در سال ۲۰۲۴ دیده شده بود، اما چون کسی نتوانسته بود از آن سوءاستفاده کند، رها شد. این بار هوش مصنوعی کمک کرد که یک ایراد قدیمی و «نظری» به یک حملهٔ واقعی تبدیل شود. Wiz در گزارشش PHP2Shell را با Heartbleed و Log4Shell مقایسه کرده و نوشته ممکن است نقطهٔ عطف مشابهی برای دوران هوش مصنوعی باشد. Calif هم در گزارش کاملش داستان را از اولین باگ حافظهٔ PHP در سال ۲۰۰۴ روایت کرده است.

چه کسانی دربارهٔ PHP2Shell هشدار دادند؟

کمتر پیش می‌آید یک باگ زبان برنامه‌نویسی این‌قدر سروصدا کند. فهرست کسانی که هشدار دادند خودش نشان می‌دهد ماجرا چقدر جدی است:

• CISA، آژانس امنیت سایبری آمریکا، همان روز هشدار فوری داد: فوراً وصله کنید، اول سیستم‌هایی که رو به اینترنت هستند. اگر نمی‌توانید آپدیت کنید یا هنوز PHP 8.1 و قدیمی‌تر دارید، سیستم را تا زمان آپدیت از دسترس خارج کنید.
• NSA هم توصیه کرد اگر آپدیت فوری ممکن نیست، سایت را آفلاین کنید.
• NCSC بریتانیا و CERT-EU اتحادیهٔ اروپا هشدار اضطراری دادند و گفتند تا وصله نشده، سرویس‌های رو به اینترنت را از دسترس عموم خارج کنید.
• مرکز ملی امنیت سایبری ژاپن هم از همهٔ کاربران PHP خواست فوراً آپدیت کنند.
• Sansec، شرکت امنیتی متخصص فروشگاه‌های اینترنتی، پیش‌بینی کرده بود حمله‌های گسترده «ظرف ۱۵ دقیقه بعد از انتشار» شروع شود.
• کوین بومونت (Kevin Beaumont)، پژوهشگر امنیتی مشهور، ماجرا را از ساعت اول دنبال کرد و حتی قبل از انتشار رسمی، از روی بیلدهای آزمایشی حدس زد که نسخه‌های وصله‌شده کدام‌ها خواهند بود.

ماجرا حتی به وال‌استریت ژورنال و نیویورک تایمز هم کشید.

بعد از افشای PHP2Shell چه اتفاقی افتاد؟

قرار بود جزئیات تا روز انتشار وصله مخفی بماند، اما ۲۰ اکتبر شناسه‌های CVE در Hacker News لو رفت و تیم PHP انتشار را جلو انداخت. طبق گزارش‌ها، تیم اطلاعات تهدید آمازون یک تلاش برای سوءاستفاده را چهار روز قبل از افشا دیده بود و Cloudflare هم پیش از انتشار وصله، ترافیک حمله گزارش کرد و قانون‌های موقت فایروال گذاشت. در مقابل، CISA تا لحظهٔ انتشار هشدارش سوءاستفادهٔ فعالی ندیده بود.

واکنش‌ها هم بی‌سابقه بود. سرویس‌های عمومی دولت فنلاند، سایت‌های وزارت کشور فرانسه و پورتال دولت هلند موقتاً از دسترس خارج شدند، بنیاد ویکی‌مدیا بسیاری از سرویس‌های جانبی‌اش را خاموش کرد و Internet Archive هم مدت کوتاهی پایین آمد.

PHP2Shell چقدر خطرناک است؟

خلاصه بگویم: خیلی. سه چیز این باگ را از یک آسیب‌پذیری معمولی جدا می‌کند:

1. از راه دور است: مهاجم لازم نیست به سرور دسترسی داشته باشد؛ همان درخواست HTTP که هر مرورگری می‌فرستد کافی است.
2. احراز هویت نمی‌خواهد: نه نام کاربری لازم است، نه رمز.
3. اطلاعات حساس لو می‌رود: طبق گزارش Sansec، باگ اول می‌تواند بخشی از حافظهٔ سرور را هم لو بدهد؛ حافظه‌ای که ممکن است رمزها، توکن‌های نشست، کلیدهای API و حتی کلید خصوصی TLS داشته باشد.

برای انصاف این را هم بگویم: Sansec بعداً نوشت حملهٔ گسترده کمتر از انتظار اولیه محتمل است، چون اکسپلویت‌های عمومی روی هر پیکربندی کار نمی‌کنند و به شرایط خاصی نیاز دارند. اما وقتی کدهای اثبات مفهوم (PoC) بیرون آمده و همه دارند رویشان کار می‌کنند، «احتمالش کمتر است» دلیل خوبی برای صبر کردن نیست.

چطور PHP2Shell را رفع کنیم؟ قدم‌به‌قدم

تنها راه کامل، آپدیت خود PHP است. آپدیت وردپرس، افزونه‌ها یا کد سایت این مشکل را حل نمی‌کند.

قدم ۱: نسخهٔ PHP را بررسی کنید

php -v

اگر هاست اشتراکی دارید و به ترمینال دسترسی ندارید، نسخه را در کنترل پنل (cPanel، DirectAdmin یا Plesk) یا در وردپرس از مسیر «ابزارها ← سلامت سایت ← اطلاعات» ببینید. توجه کنید که نسخهٔ خط فرمان و نسخه‌ای که وب‌سرور استفاده می‌کند گاهی فرق دارند.

قدم ۲: به یکی از نسخه‌های امن آپدیت کنید

روی دبیان و اوبونتو (اگر با سیستم apt آشنا نیستید، قسمت سوم مجموعهٔ دبیان را ببینید):

sudo apt update
sudo apt upgrade
php -v

روی RHEL، AlmaLinux و Rocky Linux:

sudo dnf upgrade 'php*'

اگر از ایمیج رسمی Docker استفاده می‌کنید، ایمیج را دوباره pull و کانتینرها را دوباره بسازید.

قدم ۳: PHP-FPM یا آپاچی را ری‌استارت کنید

این قدم را خیلی‌ها فراموش می‌کنند. تا پروسه‌های قدیمی در حال اجرا باشند، کد آسیب‌پذیر هنوز در حافظه است:

sudo systemctl restart php8.3-fpm   # نسخهٔ خودتان را بگذارید
sudo systemctl restart apache2       # اگر mod_php دارید

قدم ۴: نسخهٔ قدیمی‌تر از 8.2 دارید؟

PHP 8.1 و قبل‌تر دیگر نسخهٔ رسمی جدید نمی‌گیرند. تیم PHP فقط وصلهٔ کد منبع برای 7.4، 8.0 و 8.1 داده و توزیع‌ها پکیج آماده کرده‌اند. در این حالت یا به 8.2 به بالا ارتقا دهید، یا پکیج وصله‌شدهٔ توزیعتان را نصب کنید. در دبیان و اوبونتو مخزن ppa:ondrej/php هم پکیج وصله‌شده دارد. نکته: در این پکیج‌ها شمارهٔ نسخه عوض نمی‌شود، پس changelog را چک کنید:

zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gz

قدم ۵: هاست اشتراکی و وردپرس

اگر سایتتان روی هاست اشتراکی است، احتمالاً خودتان نمی‌توانید PHP را آپدیت کنید. همین امروز به پشتیبانی هاستینگ پیام بدهید و بپرسید PHP به نسخه‌ای که PHP2Shell را رفع می‌کند آپدیت شده یا نه. اگر کنترل پنل اجازهٔ انتخاب نسخهٔ PHP می‌دهد، جدیدترین نسخهٔ پشتیبانی‌شده را انتخاب کنید. اگر هم افزونه‌ای مثل نگارش یا هر افزونهٔ دیگری نصب دارید، زیاد نگران سازگاری نباشید؛ آپدیت داخل یک شاخه (مثلاً از 8.3.30 به 8.3.36) فقط وصلهٔ امنیتی و رفع باگ است و معمولاً چیزی را خراب نمی‌کند.

قدم ۶: راه‌حل موقت، فقط تا زمان آپدیت

اگر واقعاً نمی‌توانید همین الان آپدیت کنید، این تنظیمات خطر را کم می‌کنند، اما رفعش نمی‌کنند:

; php.ini or the FPM pool (not .user.ini / ini_set)
session.upload_progress.enabled = 0

بعد از تغییر، پروسه‌های PHP را ری‌استارت کنید. Sansec توصیه می‌کند درخواست‌های multipart/form-data را هم در وب‌سرور ببندید، چون همهٔ مسیرهای شناخته‌شدهٔ حمله از آن استفاده می‌کنند؛ این کار آپلود فایل را خراب می‌کند و بعد از آپدیت باید برش دارید. Cloudflare و چند سرویس CDN دیگر هم قانون موقت فایروال گذاشته‌اند. تأکید می‌کنم: همهٔ این‌ها موقتی است و جای آپدیت را نمی‌گیرد.

قدم ۷: نشانه‌های نفوذ را بررسی کنید

اگر سرورتان مدتی آسیب‌پذیر بوده، لاگ‌ها را نگاه کنید: درخواست‌های multipart عجیب که بعدشان خطای کمبود حافظه آمده، خطاهای ۵۰۰ تکراری، کوکی‌های PHPSESSID غیرعادی و بزرگ، و مهم‌تر از همه پروسه‌های PHP که شِل یا ابزار دانلود اجرا کرده‌اند. CISA هم دقیقاً همین آخری را توصیه کرده است.

جمع‌بندی

PHP2Shell از آن باگ‌هایی است که سال‌ها از آن حرف می‌زنیم: باگی ۱۴ ساله در زبانی که بیشتر وب را می‌چرخاند، که با کمک هوش مصنوعی پیدا شد و قبل از انتشار وصله هم لو رفت. خبر خوب این است که رفعش ساده است: php -v، آپدیت، ری‌استارت. اگر سایت دارید، همین امروز انجامش بدهید؛ اگر سایت ندارید، این نوشته را برای کسی بفرستید که دارد.

من در ابزارهایی که خودم با PHP ساخته‌ام، مثل دایرکتوری لینک‌های مفید آرما و پلاگین جدول لیگ، کدی برای تغییر لازم نیست؛ مشکل در خود PHP است و با آپدیت سرور حل می‌شود. اگر سؤالی دربارهٔ آپدیت سرور یا هاستتان دارید، در بخش نظرات بپرسید.