باگ اجرای کد از راه دور PHP2Shell در PHP (CVE-2026-109618 و CVE-2026-109619)؛ کدام نسخه‌ها آسیب‌پذیرند و چطور وصله کنیم
دو باگ بحرانی در هسته PHP پیدا شده که به مهاجم اجازه می‌دهد بدون هیچ نام کاربری و رمز عبوری، کد دلخواه روی سرور اجرا کند. این باگ‌ها CVE-2026-109618 و CVE-2026-109619 نام گرفته‌اند و در میان محقق‌ها به PHP2Shell معروف شده‌اند. تیم PHP در 22 اکتبر 2026 (30 مهر 1405) نسخه‌های وصله‌شده را منتشر کرد و از 26 اکتبر، CISA این دو را در فهرست آسیب‌پذیری‌های با سوءاستفاده فعال (KEV) ثبت کرده است.
اگر روی سرور خودتان وردپرس، لاراول، مجنتو یا هر برنامه دیگری با PHP اجرا می‌کنید، این مطلب را تا انتها بخوانید؛ نسخه‌های دقیق آسیب‌پذیر، میزان خطر و دستورهای لازم برای چک کردن و وصله سرورتان را اینجا آورده‌ایم.
چه اتفاقی افتاده
هر دو باگ در بخش پردازش درخواست‌های HTTP توسط خود PHP هستند، نه در یک افزونه یا فریم‌ورک خاص. یعنی هر برنامه‌ای که پشت Apache با mod_php یا پشت PHP-FPM اجرا می‌شود، در معرض آن است.
- CVE-2026-109618: یک باگ خرابی حافظه (memory corruption) است که هنگام مواجهه PHP با کمبود حافظه (OOM) در میانه پردازش درخواست یا داده‌های multipart رخ می‌دهد؛ مثلا درخواستی بدون content-length یا با هدرهای multipart نامحدود. PHP وضعیت داخلی را «آماده» علامت می‌زند پیش از آن‌که همه تخصیص‌های حافظه تمام شوند، و اگر دقیقا همان لحظه OOM پیش بیاید، کد پایان‌دهنده درخواست به ساختار خراب‌شده اعتماد می‌کند.
- CVE-2026-109619: یک باگ use-after-free است. بعضی داده‌های سراسری مرتبط با یک درخواست (مثل backtrace خطای fatal یا session.upload_progress) می‌توانند بعد از پایان آن درخواست هم زنده بمانند، در حالی که حافظه‌ای که به آن اشاره می‌کنند آزاد شده. درخواست بعدی که همان پردازه worker آن را پردازش کند، همین حافظهٔ آزادشده را می‌خواند یا در آن می‌نویسد.
نتیجه هر دو مسیر یکسان است: اجرای کد از راه دور با همان سطح دسترسی پردازه وب‌سرور، بدون نیاز به ورود یا هیچ تعامل خاصی از کاربر.
کدام نسخه‌های PHP آسیب‌پذیرند
هر چهار شاخه فعلی PHP قبل از نسخه‌های اصلاح‌شده 22 اکتبر آسیب‌پذیرند. تحقیق‌های اولیه از PHP 5.4 به‌عنوان نسخه‌ای که این کد را دارد نام برده بودند، اما آن فقط اشاره به قدمت کد دارد؛ محدوده رسمی و وصله‌شده توسط تیم PHP فقط همین چهار شاخه زیر است:
| شاخه PHP | نسخه آسیب‌پذیر | نسخه اصلاح‌شده |
|---|---|---|
| 8.2 | قبل از 8.2.35 | 8.2.35 |
| 8.3 | قبل از 8.3.36 | 8.3.36 |
| 8.4 | قبل از 8.4.27 | 8.4.27 |
| 8.5 | قبل از 8.5.12 | 8.5.12 |
اگر نسخه شما قدیمی‌تر از 8.2 است (مثل 7.4 یا 8.0)، دیگر تحت پشتیبانی رسمی نیست و این وصله برای آن منتشر نمی‌شود؛ تنها راه، ارتقا به یکی از همین چهار شاخه پشتیبانی‌شده است.
این باگ چقدر خطرناک است
امتیاز CVSS 4.0 هر دو CVE برابر 9.2 از 10 است، یعنی رتبه بحرانی. Red Hat بسته‌های خودش روی RHEL را «Important» رتبه‌بندی کرده (RHSB-2026-013)؛ این تفاوت در عدد به خاطر نحوه بسته‌بندی هر توزیع است، نه تضاد در ارزیابی خطر.
نکته مهم‌تر این است که سوءاستفاده از این دو باگ فعال است، نه فقط تئوری. CISA در 26 اکتبر آن‌ها را به فهرست KEV اضافه کرد (با مهلت رفع تا 29 اکتبر برای سازمان‌های فدرال آمریکا)، و طبق گزارش Rapid7 چند PoC عمومی هم‌اکنون در گردش است؛ قابلیت اجرای این PoCها بسته به سیستم‌عامل، نسخه دقیق PHP و نوع وب‌سرور فرق می‌کند، پس نبودن یک اکسپلویت آماده برای پیکربندی شما به معنی امن بودن نیست.
یک تفاوت عملی هم هست: سرورهایی که PHP را با Apache mod_php اجرا می‌کنند، عملا در خطر بیشتری هستند نسبت به PHP-FPM؛ چون در PHP-FPM پردازه‌های worker بیشتر وقت‌ها قبل از رسیدن به ساختار داده خراب‌شده، خودشان خارج می‌شوند (طبق تحلیل Red Hat). این یعنی مهم‌تر بودن سرعت وصله برای سرورهای cPanel/Plesk قدیمی که هنوز mod_php دارند.
نسخه PHP سرور خودتان را چطور چک کنید
قبل از هر کاری، نسخه فعلی PHP روی سرور را دقیق مشخص کنید:
php -v
روی سرورهای اوبونتو یا دبیان، همه بسته‌های PHP نصب‌شده را هم ببینید:
apt list --installed | grep php
روی CentOS/AlmaLinux/Rocky:
rpm -qa | grep php
اگر چند نسخه PHP روی یک سرور نصب است (مثلا برای سایت‌های مختلف)، هر کدام را جدا چک کنید؛ php -v فقط نسخه پیش‌فرض CLI را نشان می‌دهد، نه نسخه‌ای که یک وب‌سایت خاص پشت PHP-FPM استفاده می‌کند.
برای وردپرس، از پیشخان بروید به «ابزارها > سلامت سایت» و نسخه PHP را در بخش اطلاعات سرور ببینید. در لاراول کافی است در ریشه پروژه php artisan --version را اجرا کنید تا نسخه PHP زیرساخت هم چاپ شود. اگر از هاست اشتراکی یا پنل مدیریتی مثل cPanel/Plesk استفاده می‌کنید، نسخه PHP معمولا در بخش «Select PHP Version» یا «PHP Settings» همان پنل قابل مشاهده و تغییر است.
راه وصله و مقابله
تنها راه واقعی رفع این مشکل، ارتقای PHP به یکی از این نسخه‌ها یا بالاتر است: 8.2.35، 8.3.36، 8.4.27 یا 8.5.12. روی سرورهای مبتنی بر پکیج‌منیجر:
sudo apt update && sudo apt install --only-upgrade php-common
# یا برای PHP-FPM
sudo systemctl restart php-fpm
sudo systemctl restart apache2 # یا nginx
روی RHEL/AlmaLinux/Rocky، دستور معادل dnf upgrade است. بعد از آپدیت، PHP-FPM یا Apache را ری‌استارت کنید؛ وگرنه پردازه‌های قدیمی همچنان در حافظه فعال می‌مانند و وصله روی آن‌ها اثر نمی‌کند.
اگر به هر دلیلی ارتقای فوری ممکن نیست (مثلا سازگاری یک اپلیکیشن قدیمی)، دو اقدام موقت وجود دارد — هیچ‌کدام جایگزین وصله نیستند، فقط سطح ریسک را کمی پایین می‌آورند:
- در
php.ini، مقدارsession.upload_progress.enabledرا روی0بگذارید تا مسیر گزنده CVE-2026-109619 بسته شود. - مقدارهای
memory_limitوpost_max_sizeرا بازبینی کنید تا شرایط OOM کمتر از طریق اندازه درخواست‌های کنترل‌شده توسط مهاجم قابل دسترس باشد.
روی سرور مجازی خودتان، این‌کارها دست خودتان است: می‌توانید قبل از وصله یک اسنپ‌شات بگیرید تا اگر ارتقا به مشکلی خورد سریع برگردید، و با یک فایروال ساده دسترسی به پورت‌های غیرضروری را ببندید تا سطح حمله کمتر شود. اگر هنوز روی یک سرور مجازی با کنترل کامل روی نسخه PHP و زمان‌بندی وصله‌ها کار نمی‌کنید، این دقیقا همان نوع حادثه است که نشان می‌دهد چرا این کنترل مهم است.
سؤالات متداول
آیا این باگ فقط وردپرس را تحت تاثیر قرار می‌دهد؟ نه. این باگ در هسته PHP است، پس هر برنامه‌ای که روی PHP اجرا شود (وردپرس، لاراول، مجنتو، یا کد اختصاصی) در معرض آن است، به شرط این‌که نسخه PHP زیرساخت در محدوده آسیب‌پذیر باشد.
نسخه PHP من 8.1 است، باید چیکار کنم؟ 8.1 دیگر تحت پشتیبانی رسمی PHP نیست و این وصله برای آن منتشر نشده. باید به یکی از نسخه‌های پشتیبانی‌شده (8.2.35 به بالا) ارتقا دهید.
آیا فقط تغییر یک تنظیم در php.ini کافی است؟
نه برای هر دو CVE. غیرفعال کردن session.upload_progress فقط مسیر CVE-2026-109619 را می‌بندد و CVE-2026-109618 را تحت تاثیر قرار نمی‌دهد. ارتقای نسخه PHP تنها راه رفع کامل هر دو است.
چرا PHP-FPM کمی امن‌تر از mod_php توصیف شده؟ چون پردازه‌های worker در PHP-FPM بیشتر مواقع قبل از رسیدن به ساختار داده خراب‌شده خودشان متوقف می‌شوند، طبق تحلیل Red Hat. این یک کاهش ریسک نسبی است، نه یک وصله؛ هر دو پیکربندی باید ارتقا پیدا کنند.
