آسیب‌پذیری‌های بحرانی PHP2Shell در PHP

چون اشکال در هسته PHP و پردازش درخواست‌XNET قرار دارد، سالم‌بودن کد برنامه یا به‌روز بودن افزونه‌های سایت به‌تنهایی برای رفع این خطر کافی نیست.

تمام سرویس‌هایی که درخواست‌های نامطمئن وب را با PHP پردازش می‌کنند باید بررسی شوند؛ از جمله PHP-FPM، Apache mod_php، php-cgi، FrankenPHP و LiteSpeed. تیم PHP احتمال خطر را برای mod_php بیشتر دانسته و از نمونه بهره‌برداری پیش از اجرای کد برنامه خبر داده است. در مقابل، برخی پیکربندی‌های PHP-FPM ممکن است به‌دلیل خاتمه فرایند هنگام خطای اولیه، سوءاستفاده را دشوارتر کنند؛ این موضوع به معنای مصونیت قطعی آن‌ها نیست. Cloudflare نیز از مشاهده تلاش‌های مرتبط با این خانواده آسیب‌پذیری گزارش داده است، اما مشاهده تلاش حمله لزوماً به معنای موفقیت آن یا نفوذ به همه سرورهای هدف نیست.

تیم PHP در ۲۱ اکتبر ۲۰۲۶، انتشار وصله‌های اضطراری برای دو آسیب‌پذیری بحرانی موسوم به PHP2Shell را اعلام کرد. این دو نقص با شناسه‌های CVE‑2026‑109618 و CVE‑2026‑109619 و امتیاز ۹٫۲ در CVSS نسخه چهارم، در شرایط مناسب می‌توانند به اجرای کد از راه دور بدون احراز هویت منجر شوند.

در نقص نخست، CVE‑2026‑109618، زمانی که تخصیص حافظه هنگام پردازش درخواست با شکست روبه‌رو می‌شود، بخشی از داده‌های داخلی ممکن است ناقص مقداردهی شود. سپس مرحله پاک‌سازی درخواست می‌تواند با این داده‌های نامعتبر مانند ساختارهای معتبر رفتار کند و باعث خرابی حافظه شود.

نقص دوم، CVE‑2026‑109619، به باقی‌ماندن وضعیت سراسری یا اشاره‌گرهای مربوط به درخواست پیشین پس از آزادسازی حافظه مربوط است؛ بنابراین پردازش بعدی در همان فرایند ممکن است از حافظه‌ای استفاده کند که دیگر معتبر نیست. بهره‌برداری قابل‌اتکا به کنترل دقیق وضعیت حافظه و زمان‌بندی نیاز دارد، اما نتیجه موفق آن می‌تواند اجرای کد دلخواه باشد. نسخه‌های اصلاح‌شده رسمی PHP در تاریخ ۲۱ اکتبر شامل 8.5.12، 8.4.27، 8.3.36 و 8.2.35 بودند.

مدیران باید نسخه متناسب با شاخه‌ای را که واقعاً در وب‌سرور اجرا می‌شود نصب کنند و تنها به نسخه ابزار خط فرمان بسنده نکنند. برای PHP 8.1 و قدیمی‌تر، انتشار رسمی جدید از سوی پروژه اصلی انجام نمی‌شود، هرچند کد اصلاحی حداقلی برای شاخه‌های PHP 7.4، PHP 8.0 و PHP 8.1 و همچنین بسته‌های بک‌پورت برخی توزیع‌ها و فروشندگان LTS ارائه شده است. در چنین محیط‌هایی شماره نسخه ممکن است ثابت بماند و تاریخ ساخت یا اعلان امنیتی فروشنده ملاک درست‌تری برای تشخیص وصله باشد.

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

برای کاهش بخشی از مسیر حمله CVE‑2026‑109618، توصیه شده است مقدار memory_limit=-1 در تنظیمات مدیریتی غیرقابل‌تغییر توسط برنامه اعمال شود؛ برای نمونه از طریق php_admin_value در تنظیمات PHP-FPM یا Apache. این تغییر جلوی بعضی خطاهای قابل تحریک توسط محدودیت حافظه PHP را می‌گیرد، اما شکست واقعی تخصیص حافظه همچنان ممکن است رخ دهد و برداشتن محدودیت حافظه می‌تواند خطر کاهش دسترس‌پذیری ایجاد کند. به همین دلیل کنترل مصرف منابع با کانتینر یا cgroup و سیاست خاتمه فرایند آسیب‌دیده مهم است. محدودیت‌های RLIMIT_AS و RLIMIT_DATA جایگزین مناسبی نیستند و حتی ممکن است همان مسیر آسیب‌پذیر را تحریک کنند.

همچنین باید اندازه و پیچیدگی درخواست‌های ورودی را محدود کرد. برای برنامه‌هایی که بارگذاری فایل ندارند، مقدار نمونه post_max_size برابر 8M و برای برنامه‌های نیازمند بارگذاری، مقدار 32M پیشنهاد شده و upload_max_filesize باید کمتر از آن باشد. وب‌سرور یا پراکسی نیز بهتر است برای اندازه درخواست پس از رمزگشایی، تعداد فیلدها، بخش‌های multipart و سرآیندها محدودیت مناسب اعمال کند؛ از جمله برای درخواست‌هایی که Content-Length قابل استفاده ندارند. این تنظیمات باید با نیاز واقعی برنامه سازگار شوند و صرفاً احتمال تحریک برخی مسیرها را کاهش می‌دهند.

برای CVE‑2026‑109619 مهم‌ترین اقدام موقت، تنظیم session.upload_progress.enabled=0 پیش از شروع پردازش درخواست و راه‌اندازی مجدد همه پردازه‌های PHP است. این تنظیم باید در php.ini یا پیکربندی سطح سرور و مجموعه پردازه‌های PHP-FPM اعمال شود؛ تغییر آن با ini_set() یا فایل‌های دیرهنگام .user.ini تضمین لازم را ایجاد نمی‌کند. در PHP 8.5 غیرفعال‌کردن fatal_error_backtraces=0 نیز یکی از مسیرهای تأییدشده را محدود می‌کند. حذف تنظیمات نامعتبر که هنگام پردازش اولیه هشدار تولید می‌کنند و اصلاح خطاهای بحرانی قابل تحریک از راه دور هم مفید است، ولی این اقدامات تمام شکل‌های احتمالی سوءاستفاده را مسدود نمی‌کنند.

هشدار تکمیلی PHP در ۲۳ اکتبر، نقص مرتبط دیگری با شناسه CVE‑2026‑115560 را معرفی کرد که وصله‌های روز ۲۱ اکتبر آن را رفع نمی‌کنند. این مسیر به ترکیب غیرمعمولی نیاز دارد: برنامه از ابتدا session.serialize_handler را روی php_binary یا php_serialize تنظیم کرده باشد، سپس پیش از session_start() آن را در زمان اجرا به php تغییر دهد و قابلیت پیشرفت بارگذاری نشست نیز فعال بماند. به گفته تیم PHP احتمال وقوع این شرایط کم است؛ با این حال تا انتشار وصله در چرخه عادی، غیرفعال‌کردن session.upload_progress.enabled توصیه شده است. بنابراین حتی پس از نصب نسخه‌های اصلاح‌شده دو CVE اصلی، این تنظیم در محیط‌های مرتبط باید بررسی شود.

قوانین WAF و سرویس‌های CDN می‌توانند درخواست‌های شناخته‌شده مخرب را محدود کنند، ولی جایگزین نصب وصله نیستند؛ به‌ویژه وقتی یک نقص در مدیریت حافظه خود مفسر وجود دارد. پس از اعمال به‌روزرسانی یا تنظیمات موقت، همه فرایندهای PHP باید واقعاً از نو آغاز شوند و وضعیت نسخه‌ها در سرویس وب، بسته‌های نصب‌شده و کانتینرهای عملیاتی کنترل شود. بازبینی لاگ‌XNET‌سرور، رخدادهای خاتمه غیرعادی پردازه‌ها و دسترسی‌های مشکوک، در کنار بررسی نشانه‌های نفوذ و تغییر اعتبارنامه‌ها در صورت مشاهده شواهد، بخشی از پاسخ عملیاتی است. تأکید تیم PHP روشن است: راهکارهای موقت فقط ریسک را کاهش می‌دهند و برطرف‌کردن کامل دو آسیب‌پذیری اصلی به وصله معتبر نیاز دارد.