حفرهٔ امنیتی PHP2Shell: چیست، چه کسانی آسیب می‌بینند و چطور وردپرس را امن کنیم

در ۲۱ اکتبر ۲۰۲۶ پروژهٔ PHP دو آسیب‌پذیری بحرانی را با شناسه‌های CVE-2026-109618 و CVE-2026-109619 برطرف کرد. این خانوادهٔ باگ‌ها که در رسانه‌ها با نام PHP2Shell شناخته می‌شود، می‌تواند بدون احراز هویت روی سرورهای PHP اجرای کد از راه دور (RCE) یا افشای حافظهٔ فرایند را ممکن کند. امتیاز CVSS هر دو مورد حدود ۹٫۲ است و تقریباً هر نصب PHP که درخواست وب را سرو می‌کند در معرض خطر قرار دارد؛ از جمله WordPress، Drupal، Joomla، Laravel و هاستینگ اشتراکی.

نکتهٔ کلیدی برای صاحبان سایت: به‌روز کردن وردپرس، قالب یا افزونه این مشکل را حل نمی‌کند. باید خودِ ران‌تایم PHP را به نسخهٔ وصله‌شده برسانید و workerها را ری‌استارت کنید. این مقاله خلاصهٔ وضعیت، نسخه‌های آسیب‌پذیر و گام‌های عملی رفع برای وردپرس و اپ‌های مشابه PHP است.

PHP2Shell چیست؟

هر دو CVE ریشه در مدیریت حافظه و مدیریت خطای fatal در هستهٔ PHP دارند، نه در کد یک CMS خاص:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): فساد حافظه هنگام برخورد با memory_limit (Out-of-Memory). اگر درخواست دقیقاً در لحظهٔ نامناسب به سقف حافظه برسد، PHP ممکن است دادهٔ نیمه‌آماده‌شده را در cleanup به‌عنوان دادهٔ معتبر آزاد کند و مهاجم بتواند مسیر را تا اجرای کد پیش ببرد. روی Apache با mod_php حتی قبل از اجرای کد اپلیکیشن هم نشان داده شده است.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): وضعیت سراسری کهنه (stale global state) بین درخواست‌ها. بعد از fatal error، وضعیت داخلی ممکن است به حافظه‌ای اشاره کند که آزاد شده؛ درخواست بعدی همان worker می‌تواند از آن سوءاستفاده کند (use-after-free).

محققان Wiz، Calif و OpenAI Codex Security این مسائل را گزارش کردند. به گفتهٔ Wiz، PHP حدود ۷۰٪ وبسایت‌ها را قدرت می‌دهد و RCE بدون لاگین روی ایمیج‌های WordPress، Drupal و Joomla نشان داده شد. AWS گزارش داده تلاش‌های بهره‌برداری از حدود ۱۷ اکتبر ۲۰۲۶ — چند روز قبل از افشای عمومی — دیده شده و بعد از انتشار وصله، بهره‌برداری گسترده‌تر شده است.

چه کسانی آسیب‌پذیرند؟

• نسخه‌های آسیب‌پذیر: PHP 8.5 قبل از 8.5.12، 8.4 قبل از 8.4.27، 8.3 قبل از 8.3.36، 8.2 قبل از 8.2.35.
• نسخه‌های رفع‌شده: 8.5.12، 8.4.27، 8.3.36، 8.2.35.
• PHP 8.1 و قدیمی‌تر: EOL هستند؛ آپ‌استریم fix کامل برای همهٔ شاخه‌های قدیمی ندارد. برخی توزیع‌ها backport منتشر کرده‌اند، ولی توصیهٔ CISA، NCSC بریتانیا و خود WordPress این است که اگر نمی‌توانید فوری ارتقا دهید، سیستم را از اینترنت جدا کنید یا آفلاین کنید.
• نحوهٔ اجرا: PHP-FPM، mod_php، php-cgi، FrankenPHP، LiteSpeed و هر worker وب. mod_php پرریسک‌ترین سناریو اعلام شده است.
• اپلیکیشن‌ها: هر اسکریپت PHP وب، حتی Hello World. وردپرس، دروپال، جوملا، ووکامرس، Laravel، Magento و پنل‌های هاست که خودشان PHP دارند.

وردپرس رسماً اعلام کرد این باگ‌ها مخصوص وردپرس نیستند و هیچ آپدیت هستهٔ وردپرس برای آن‌ها برنامه‌ریزی نشده؛ فقط PHP را باید به‌روز کرد.

چک‌لیست فوری برای وردپرس

1. نسخهٔ دقیق PHP را ببینید: در پیشخوان وردپرس بروید به ابزارها ← سلامت سایت ← اطلاعات ← سرور ← نسخه PHP. فقط «۸٫۳» کافی نیست؛ باید patch level را ببینید (مثلاً 8.3.36).
2. اگر نسخه کمتر از اعداد رفع‌شده است: در پنل هاست (cPanel MultiPHP، Plesk، Hostinger PHP Configuration، SiteGround PHP Manager و مشابه) به شاخهٔ پشتیبانی‌شده بروید و از پشتیبانی بپرسید آیا build آن‌ها CVE-2026-109618 و CVE-2026-109619 را دارد. بعضی هاست‌ها fix را بدون تغییر شمارهٔ نسخه در پکیج خودشان می‌گذارند؛ پس تأیید کتبی هاست مهم است.
3. بعد از آپدیت، workerها را ری‌استارت کنید (PHP-FPM، Apache، LiteSpeed). بدون ری‌استارت، workerهای قدیمی هنوز آسیب‌پذیر می‌مانند.
4. کانتینر Docker: ایمیج را rebuild کنید تا از base image با PHP وصله‌شده استفاده کند؛ فقط restart کانتینر قدیمی کافی نیست اگر باینری قدیمی داخل ایمیج باشد.
5. WAF: Cloudflare، AWS WAF و بسیاری از هاست‌ها قوانین موقتی گذاشته‌اند. WAF کمک می‌کند ولی جایگزین پچ نیست.
6. اگر روی PHP 8.1 یا قدیمی‌تر هستید: بکاپ بگیرید، سازگاری افزونه‌ها را با PHP 8.3+ تست کنید و مهاجرت کنید. پشتیبانی امنیتی شاخهٔ 8.2 هم تا ۳۱ دسامبر ۲۰۲۶ تمام می‌شود؛ هدف منطقی 8.3 یا جدیدتر است.

مراحل عملی روی سرور خودتان (VPS / اختصاصی)

بسته به توزیع، بسته‌های PHP را از مخزن رسمی یا vendor خود به‌روز کنید. مثال برای apt-based (اعداد بسته را با مخزن خودتان تطبیق دهید):

# نسخهٔ فعلی
php -v
# و برای FPM واقعی (ممکن است با CLI فرق کند):
# php-fpm8.3 -v   یا مسیر معادل

# به‌روزرسانی و ری‌استارت (Debian/Ubuntu با مخزن ondrej یا vendor)
sudo apt update
sudo apt install --only-upgrade php8.3-fpm php8.3-cli
sudo systemctl restart php8.3-fpm
# اگر Apache mod_php دارید:
sudo systemctl restart apache2

بعد از ارتقا دوباره نسخه را چک کنید و مطمئن شوید وب‌سرور همان باینری را لود کرده است:

curl -sI https://yoursite.example/ | head
# یا یک صفحهٔ موقت phpinfo فقط برای خواندن نسخه، سپس فوری حذفش کنید

کاهش ریسک موقت (تا وقتی پچ می‌زنید)

هیچ mitigation به‌تنهایی کافی نیست، اما تا زمان آپدیت می‌توانید سطح حمله را کم کنید:

• دسترسی عمومی به اپ‌های آسیب‌پذیر را محدود کنید یا طبق توصیهٔ CERT-EU / CISA تا زمان پچ، سرویس اینترنت‌facing را ایزوله کنید.
• برای مسیرهای شناخته‌شدهٔ CVE-2026-109619: در php.ini یا pool تنظیم کنید session.upload_progress.enabled=0 و روی PHP 8.5 در صورت امکان fatal_error_backtraces=0، سپس همهٔ workerها را ری‌استارت کنید.
• قوانین WAF / reverse proxy جلوی PHP برای بلاک کردن bodyهای فرم غیرعادی (نام فیلد بسیار بلند، بایت‌های کنترل در POST).
• محدود کردن اندازهٔ body و نرخ درخواست در nginx/Apache.
• تنظیمات خطرناک مثل allow_url_include را خاموش نگه دارید و توابع خطرناک (exec، system، passthru، shell_exec و مشابه) را در disable_functions محدود کنید — این‌ها جایگزین پچ نیستند ولی پس از نفوذ، شعاع آسیب را کم می‌کنند.

Datadog تأکید کرده تنظیماتی مثل خاموش کردن upload progress به‌تنهایی شما را کاملاً امن نمی‌کند؛ تنها رفع کامل، پچ PHP است.

بعد از پچ: پایش و پاکسازی

• لاگ PHP را برای Allowed memory size ... exhausted با محل Unknown on line 0 و segfaultهای worker بررسی کنید.
• هر shell یا پروسسی که از زیر worker وب (www-data، nginx، apache) اجرا شده را مشکوک بدانید.
• اگر سایت قبل از پچ در اینترنت بوده، رمزها، کلیدهای API، saltهای وردپرس و توکن‌ها را بچرخانید؛ افشای حافظه می‌تواند سکرت را لو بدهد حتی بدون RCE کامل.
• افزونه‌ها و فایل‌های مشکوک در wp-content، کرون‌جاب‌های ناشناس و کاربرهای ادمین جدید را بررسی کنید.

جمع‌بندی

PHP2Shell یکی از جدی‌ترین رویدادهای امنیتی وب در سال‌های اخیر است چون در خود موتور PHP است و احراز هویت اپلیکیشن جلویش را نمی‌گیرد. برای وردپرس و CMSهای مشابه مسیر درست این است: نسخهٔ دقیق PHP را ببینید ← به 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 یا build وصله‌شدهٔ هاست ارتقا دهید ← workerها را ری‌استارت کنید ← WAF را نگه دارید ولی به آن اکتفا نکنید ← اگر مشکوک به نفوذ هستید سکرت‌ها را بچرخانید.

منابع اصلی: هشدار CISA (۲۱ اکتبر ۲۰۲۶)، اعلامیهٔ PHP Foundation، خبر امنیتی wordpress.org، گزارش‌های Wiz / Datadog / AWS و CERT-EU.