دو آسیب‌پذیری CVE-2026-109618 و CVE-2026-109619 در هسته‌ی PHP می‌توانند به اجرای کد از راه دور بدون احراز هویت منجر شوند. نسخه‌های اصلاح‌شده منتشر شده است.
در ۲۹ مهر ۱۴۰۵ (۲۱ اکتبر ۲۰۲۶)، تیم PHP یک به‌روزرسانی امنیتی اضطراری برای دو آسیب‌پذیری بحرانی منتشر کرد. این دو آسیب‌پذیری با شناسه‌های CVE-2026-109618 و CVE-2026-109619 ثبت شده‌اند و در رسانه‌ها با نام «PHP2Shell» هم شناخته می‌شوند.
موضوع چیست؟
هر دو آسیب‌پذیری در خودِ موتور PHP قرار دارند، نه در یک اپلیکیشن یا افزونه‌ی خاص؛ یعنی حتی اگر کد برنامه‌ی شما سالم باشد، سرور می‌تواند در معرض خطر باشد. شدت هر دو طبق CVSS v4 برابر ۹٫۲ از ۱۰ (بحرانی) است و مهاجم می‌تواند بدون نیاز به ورود به سیستم، کد دلخواه خود را با دسترسی پردازش وب اجرا کند.
- CVE-2026-109618: مشکل در مدیریت کمبود حافظه (OOM)؛ PHP ممکن است پردازش درخواست را وسط راه رها کند و داده‌ی نیمه‌آماده را معتبر فرض کند.
- CVE-2026-109619: وضعیت داخلی درخواست پس از آزادسازی حافظه باقی می‌ماند و درخواست بعدی همان Worker از آن استفاده می‌کند.
چه کسانی در معرض خطرند؟
هر سرور یا سرویسی که PHP را برای پاسخ‌گویی به درخواست‌های وب اجرا می‌کند، از جمله Apache با mod_php، PHP-FPM، php-cgi، FrankenPHP و LiteSpeed. سایت‌های وردپرس، فروشگاه‌های ووکامرس و Magento و هر اپلیکیشن مبتنی بر PHP هم از این قاعده مستثنا نیستند. طبق توصیه‌نامه‌ی رسمی، خطر در mod_php مستقیم‌تر است؛ PHP-FPM هم در شرایطی مستعد است و نباید آن را ایمن فرض کرد.
گزارش‌هایی از تلاش برای سوءاستفاده از این آسیب‌پذیری‌ها منتشر شده است. به همین دلیل زمان برای به‌روزرسانی محدود است.
چه کار باید کنید؟
- نسخه‌ی PHP را بررسی کنید. روی سرور، کانتینر و هاست‌ها دستور php -v (و برای FPM، php-fpm -v) را اجرا کنید.
- به نسخه‌ی اصلاح‌شده ارتقا دهید (جدول زیر).
- سرویس‌ها را راه‌اندازی مجدد کنید. پس از به‌روزرسانی، PHP-FPM یا Apache را ری‌استارت کنید تا Workerها با نسخه‌ی جدید بالا بیایند. برای کانتینرها، ایمیج را دوباره بسازید و دوباره مستقر (Redeploy) کنید.
- اگر از PHP 8.1 یا قدیمی‌تر استفاده می‌کنید، پروژه‌ی PHP برای این نسخه‌ها اصلاحیه‌ی رسمی منتظم ارائه نمی‌کند. یا به یک شاخه‌ی پشتیبانی‌شده مهاجرت کنید یا از توزیع/فروشنده‌ی خود بپرسید که اصلاحیه‌ی بک‌پورت‌شده دارد یا نه.
| شاخه‌ی PHP | نسخه‌ی اصلاح‌شده |
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
اگر همین الان نمی‌توانید ارتقا دهید
PHP تأکید کرده که ارتقا تنها راه‌حل کامل است و هیچ تنظیمی جایگزین آن نمی‌شود. با این حال، تا زمان ارتقا می‌توانید ریسک را کاهش دهید:
- مقدار upload_progress.enabled=0 را در php.ini یا تنظیمات pool اعمال کنید.
- روی PHP 8.5 مقدار fatal_error_backtraces=0 را تنظیم کنید.
- اگر اپلیکیشن شما فرم‌های multipart نمی‌پذیرد، این نوع درخواست‌ها را در لایه‌ی جلویی (وب‌سرور یا WAF) مسدود کنید و post_max_size را محدود نگه دارید.
- پس از هر تغییر، همه‌ی Workerهای PHP را ری‌استارت کنید.
این اقدامات فقط بخشی از مسیرهای حمله را می‌بندند و موقتی‌اند.
اگر نیاز به راهنمایی دارید، می‌توانید با پشتیبانی کلود دات آی‌آر به شماره ۹۰۰۰۵۵۵۵ تماس بگیرید.
