PHP2Shell: دو آسیب‌پذیری بحرانی در PHP با امکان اجرای کد از راه دور
دو آسیب‌پذیری امنیتی بحرانی در PHP با شناسه‌های CVE-2026-109618 و CVE-2026-109619 شناسایی شده‌اند که با نام PHP2Shell شناخته می‌شوند. این آسیب‌پذیری‌ها می‌توانند در شرایط خاص، امکان اجرای کد از راه دور (Remote Code Execution یا RCE) را بدون نیاز به احراز هویت فراهم کنند.
شدت هر دو آسیب‌پذیری برابر با ۹.۲ از ۱۰ اعلام شده است. از آنجا که نقص‌ها در خود PHP قرار دارند، دامنه تأثیر آن‌ها به یک فریم‌ورک یا سیستم مدیریت محتوا محدود نیست و می‌تواند طیف گسترده‌ای از وب‌سایت‌ها و سرویس‌های مبتنی بر PHP را درگیر کند.
۱. PHP2Shell دقیقاً چه خطری ایجاد می‌کند؟
هر دو آسیب‌پذیری به مشکلات مدیریت حافظه و وضعیت داخلی PHP هنگام پردازش درخواست‌ها مربوط هستند، اما سازوکار آن‌ها یکسان نیست:
CVE-2026-109618: مدیریت نامناسب خطای کمبود حافظه (Out-of-Memory) می‌تواند باعث شود PHP هنگام پاک‌سازی وضعیت درخواست، با داده‌های داخلی ناقص یا نامعتبر کار کند.
CVE-2026-109619: باقی ماندن وضعیت داخلی مربوط به یک درخواست پس از آزاد شدن حافظه می‌تواند باعث استفاده مجدد از داده‌های نامعتبر در درخواست‌های بعدی شود.
در صورت بهره‌برداری موفق، مهاجم می‌تواند به اجرای کد دلخواه از راه دور دست پیدا کند و بسته به سطح دسترسی پردازش PHP، به داده‌ها یا منابع سرور دسترسی داشته باشد.
۲. چه وب‌سایت‌ها و سرورهایی در معرض خطر هستند؟
از آنجا که آسیب‌پذیری در runtime زبان PHP قرار دارد، بررسی امنیتی نباید فقط به WordPress یا یک CMS خاص محدود شود. هر محیطی که PHP را برای پردازش درخواست‌های وب اجرا می‌کند، باید از نظر نسخه و وضعیت وصله بررسی شود.
این بررسی شامل وب‌سایت‌های مبتنی بر WordPress، Drupal، Joomla و Magento، پروژه‌های اختصاصی، سرورهای هاستینگ و محیط‌های کانتینری نیز می‌شود. پیکربندی‌های مختلف اجرا، از جمله PHP-FPM، Apache با mod_php، php-cgi، FrankenPHP و LiteSpeed، در دامنه بررسی قرار می‌گیرند.
طبق هشدارهای امنیتی منتشرشده، تمام نصب‌های PHP که درخواست‌های وب را پردازش می‌کنند باید بررسی شوند. سرورهایی که مستقیماً از طریق اینترنت در دسترس‌اند، به‌دلیل سطح دسترسی عمومی، باید در اولویت قرار بگیرند.
۳. کدام نسخه‌های PHP وصله شده‌اند؟
تیم 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 8.2 تا 8.5 استفاده می‌کنید، نسخه نصب‌شده را با نسخه اصلاح‌شده همان شاخه مقایسه کنید. به‌روزرسانی PHP باید متناسب با محیط اجرا و روش مدیریت بسته‌های سرور انجام شود.
۴. وضعیت PHP 8.1 و نسخه‌های قدیمی‌تر
موضوع برای نسخه‌های قدیمی پیچیده‌تر است. شاخه‌هایی مانند PHP 8.1، 8.0 و 7.4 به پایان پشتیبانی عادی رسیده‌اند؛ با این حال، برخی ارائه‌دهندگان وصله‌های امنیتی را به‌صورت Backport در بسته‌های خود منتشر کرده‌اند.
برای مثال، طبق اطلاعیه Plesk، اصلاحیه‌هایی برای برخی Buildهای شاخه‌های قدیمی منتشر شده‌اند که ممکن است شماره نسخه آن‌ها تغییر نکرده باشد. بنابراین، صرف مشاهده شماره نسخه برای تشخیص آسیب‌پذیری کافی نیست؛ تاریخ ساخت بسته و اطلاعیه امنیتی ارائه‌دهنده نیز باید بررسی شود.
اگر نسخه مورد استفاده شما دیگر پشتیبانی نمی‌شود و وصله معتبر و قابل اتکایی برای آن وجود ندارد، مهاجرت به یک شاخه پشتیبانی‌شده باید در اولویت قرار گیرد.
۵. مدیران سرور چه اقداماتی باید انجام دهند؟
شناسایی تمام محیط‌های PHP: سرورهای اصلی، محیط‌های آزمایشی، کانتینرها، سرویس‌های هاستینگ و پروژه‌هایی را که ممکن است نسخه جداگانه‌ای از PHP اجرا کنند، فهرست کنید.
اولویت‌بندی سرورهای عمومی: سیستم‌هایی را که مستقیماً از اینترنت قابل دسترسی‌اند، پیش از محیط‌های داخلی بررسی کنید.
نصب وصله امنیتی: نسخه اصلاح‌شده متناسب با شاخه PHP یا بسته ارائه‌شده توسط توزیع لینوکس و سرویس میزبانی را نصب کنید.
بررسی نسخه واقعی runtime: دستور
php -vنسخه CLI را نمایش می‌دهد و لزوماً با نسخه PHP مورد استفاده وب‌سرور یکسان نیست. نسخه PHP-FPM یا ماژول وب‌سرور را نیز بررسی کنید.تأیید نصب موفق: پس از به‌روزرسانی، سرویس‌ها و Workerهای مربوط به PHP را طبق دستورالعمل محیط راه‌اندازی مجدد کنید و مطمئن شوید پردازش‌های فعال از نسخه اصلاح‌شده استفاده می‌کنند.
۶. بررسی نشانه‌های احتمالی بهره‌برداری
در کنار نصب وصله، بررسی لاگ‌ها و رفتار پردازش‌های سرور نیز اهمیت دارد. اجرای غیرمنتظره ابزارهایی مانند bash، sh، curl، wget یا python توسط پردازش‌هایی مانند php-fpm و php-cgi می‌تواند نشانه‌ای برای بررسی بیشتر باشد.
البته مشاهده چنین پردازش‌هایی به‌تنهایی به معنای وقوع حمله نیست. باید زمان رخداد، درخواست‌های وب، لاگ‌های سیستم و شواهد دیگر را در کنار یکدیگر تحلیل کرد.
غیرفعال کردن برخی قابلیت‌های آسیب‌پذیر یا محدود کردن دسترسی پردازش‌های PHP ممکن است در شرایط مشخص به کاهش ریسک کمک کند، اما جایگزین کامل نصب وصله امنیتی نیست.
جمع‌بندی
PHP2Shell نمونه‌ای از آسیب‌پذیری‌هایی است که مستقیماً لایه اجرای برنامه را هدف قرار می‌دهند. حتی اگر CMS و کتابخانه‌های پروژه به‌روز باشند، قدیمی بودن runtime می‌تواند همچنان خطرناک باشد.
اگر زیرساخت شما از PHP استفاده می‌کند، نسخه واقعی runtime را بررسی کنید، وصله مناسب را نصب کنید و وضعیت سرورهای متصل به اینترنت را در اولویت قرار دهید. برای نسخه‌های قدیمی نیز به‌جای اتکا به شماره نسخه، وضعیت اصلاحیه و اطلاعات ارائه‌دهنده را بررسی کنید.