آسیب‌ پذیری PHP: آموزش پچ و رفع باگ‌های بحران RCE 2026

مقدمه: معرفی آسیب‌ پذیری PHP و لزوم پچ فوری آن

مبحث آسیب‌ پذیری PHP یکی از حیاتی‌ترین موضوعات امنیتی روز است. دو نقص امنیتی خطرناک از نوع اجرای کد از راه دور (RCE) با شناسه‌های CVE-2026-109618 و CVE-2026-109619 که با نام PHP2Shell شناخته می‌شوند، در تاریخ ۲۱ اکتبر ۲۰۲۶ (۲۹ مهر ۱۴۰۵) رسماً اعلام شدند. جزئیات این دو باگ یک روز زودتر و پیش از انتشار Patch در اینترنت لو رفته بود و گزارش‌هایی از تلاش برای سوءاستفاده از آن‌ها منتشر شده است. این نقص‌ها به مهاجم اجازه می‌دهند بدون نیاز به ورود و احراز هویت، کد دلخواه خود را روی سروری که PHP اجرا می‌کند اجرا کند. اعمال پچ امنیت PHP و به‌روزرسانی به نسخه‌های اصلاح‌شده، تنها راهکار قطعی برای خنثی‌سازی این تهدید است.

از آنجا که این زبان برنامه‌نویسی ستون فقرات بسیاری از وب‌سایت‌ها، سیستم‌های مدیریت محتوا نظیر وردپرس، دروپال، لاراول و اپلیکیشن‌های مستقر روی سرور مجازی ایران و سرویس‌های ابری است، بررسی زیرساخت‌ها اهمیت دوچندانی پیدا کرده است. در این مقاله ابتدا خود آسیب‌پذیری را معرفی می‌کنیم و سپس آموزش رفع آن را جداگانه برای مشترکین هاست اشتراکی و برای مدیران سرور با دسترسی WHM و root قدم به قدم توضیح می‌دهیم.

آسیب‌ پذیری PHP2Shell دقیقاً چیست؟

هر دو باگ در هسته خود PHP هستند، نه در وردپرس یا افزونه‌ها؛ به همین دلیل هر سایتی که با PHP اجرا می‌شود، صرف نظر از نوع برنامه‌اش، در معرض خطر است:

• CVE-2026-109618: خطا در مدیریت حافظه هنگام پر شدن سقف حافظه (memory limit) در حین پردازش درخواست. بخشی از حافظه نیمه‌کاره رها می‌شود و بعداً به اشتباه معتبر فرض می‌شود که به خرابی حافظه و در نهایت اجرای کد می‌رسد.
• CVE-2026-109619: یک باگ از نوع use-after-free؛ داده‌های باقی‌مانده از یک درخواست به حافظه‌ای آزادشده اشاره می‌کنند و درخواست بعدی که روی همان پروسس اجرا می‌شود می‌تواند از آن سوءاستفاده کند. نشت اطلاعات حافظه هم از پیامدهای تأییدشده این باگ است.

شدت هر دو آسیب‌پذیری در مقیاس CVSS نسخه ۴ برابر ۹.۲ (بحرانی) اعلام شده است. همه روش‌های اجرای PHP روی وب‌سرور یعنی PHP-FPM، ماژول mod_php آپاچی، php-cgi، LiteSpeed (lsphp) و FrankenPHP تحت تأثیر هستند.

چه کسانی تحت تأثیر آسیب‌ پذیری PHP قرار گرفته‌اند؟

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

پروژه اصلی PHP بسته‌های اصلاحی را برای شاخه‌های زیر ارائه کرده است:

اگر سیستم شما از نسخه‌های منسوخ (۸.۱ به پایین) استفاده می‌کند، از پروژه PHP نسخه اصلاحی دریافت نخواهید کرد و باید فوراً برای ارتقا به نسخه‌های پشتیبانی‌شده برنامه‌ریزی کنید.

نکته بسیار مهم درباره شماره نسخه: جدول بالا مربوط به نسخه‌های رسمی PHP است. سیستم‌عامل‌هایی مثل CloudLinux (رایج در سرورهای هاست سی‌پنل)، Red Hat و Debian Patch را داخل همان نسخه قبلی قرار می‌دهند (backport) و شماره نسخه تغییر نمی‌کند. مثلاً روی CloudLinux نسخه Patch شده PHP 8.4 همچنان 8.4.26 و نسخه Patch شده PHP 8.5 همچنان 8.5.11 نمایش داده می‌شود و تفاوت فقط در شماره بیلد پکیج (8.4.26-5 و 8.5.11-5) است. پس دیدن عدد 8.4.26 به تنهایی به معنی ناامن بودن نیست؛ روش درست بررسی را در ادامه توضیح داده‌ایم.

وضعیت محصولات مختلف و اقدامات لازم در برابر آسیب‌ پذیری PHP

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

پچ کردن آسیب‌ پذیری PHP تنها راه‌حل کامل است؛ بنابراین مراحل زیر را دنبال کنید:

1. فهرست‌برداری از سیستم‌ها: تمام سرورها، وردپرس، پنل‌های مدیریت (مثل phpMyAdmin) و ابزارهای قدیمی که PHP اجرا می‌کنند را لیست کنید.
2. پچ کردن فوری: بسته‌های به‌روزرسانی را اعمال کنید و حتماً پس از آن وب‌سرور و پروسس‌های PHP را ری‌استارت کنید.
3. بررسی واقعی Patch: به شماره نسخه بسنده نکنید و تغییرات پکیج (changelog) را برای شناسه‌های CVE بررسی کنید.
4. ارتقای نسخه‌های قدیمی: سایت‌هایی که روی نسخه 8.1 و پایین‌تر هستند را به نسخه 8.2 یا بالاتر منتقل کنید.
5. کاهش شعاع آسیب: دسترسی‌های عمومی غیرضروری را محدود کرده و فایروال یا قوانین WAF (مثل Imunify360 یا Cloudflare) را فعال نگه دارید.

آموزش برای مشترکین هاست اشتراکی (کاربران سی‌پنل)

اگر هاست اشتراکی دارید، PHP روی سرور ارائه‌دهنده نصب شده و شما امکان (و نیازی به) نصب Patch ندارید؛ این کار وظیفه شرکت میزبان است. تیم فنی ایران وی ام Patch این آسیب‌پذیری را روز ۲۲ اکتبر ۲۰۲۶ (۳۰ مهر ۱۴۰۵) روی سرورهای هاست اعمال کرده و تمام نسخه‌های PHP قابل انتخاب در هاست‌ها Patch شده هستند. با این حال برای اطمینان و افزایش امنیت سایت، مراحل زیر را انجام دهید:

۱. بررسی و انتخاب نسخه PHP سایت

1. وارد سی‌پنل هاست خود شوید.
2. در بخش Software روی Select PHP Version (یا در برخی هاست‌ها MultiPHP Manager) کلیک کنید.
3. نسخه فعلی (Current PHP version) را ببینید. اگر سایت شما روی نسخه 8.1 یا پایین‌تر است، آن را به 8.3 یا 8.4 تغییر دهید؛ این نسخه‌ها هم پشتیبانی رسمی دارند و هم با نسخه‌های جدید وردپرس سازگار هستند.
4. پس از تغییر نسخه، صفحات اصلی سایت، فرم‌ها و بخش مدیریت را یک بار بررسی کنید. اگر خطایی دیدید، به نسخه قبلی برگردید و برای بررسی سازگاری افزونه‌ها با پشتیبانی تماس بگیرید.

همان‌طور که بالاتر گفتیم، روی سرورهای CloudLinux شماره نسخه بعد از Patch تغییر نمی‌کند؛ بنابراین اگر در سی‌پنل نسخه‌ای مثل 8.4.26 یا 8.5.11 می‌بینید جای نگرانی نیست.

۲. به‌روزرسانی وردپرس، افزونه‌ها و قالب

این آسیب‌پذیری در خود PHP است، اما مهاجمان معمولاً هم‌زمان از باگ‌های افزونه‌های قدیمی هم استفاده می‌کنند. از پیشخوان وردپرس به بخش به‌روزرسانی‌ها بروید و هسته وردپرس، تمام افزونه‌ها و قالب را به آخرین نسخه برسانید. افزونه‌ها و قالب‌هایی که استفاده نمی‌کنید را کاملاً حذف کنید (غیرفعال کردن کافی نیست).

۳. حذف فایل‌های اضافی و حساس

فایل‌هایی مثل info.php یا phpinfo.php که برای تست ساخته شده‌اند، نسخه‌های پشتیبان (.zip و .sql) داخل پوشه public_html و اسکریپت‌های نصب رهاشده، اطلاعات سرور را در اختیار مهاجم قرار می‌دهند. آن‌ها را از طریق File Manager سی‌پنل حذف کنید.

۴. بررسی نشانه‌های نفوذ

• در File Manager فایل‌ها را بر اساس تاریخ آخرین تغییر (Last Modified) مرتب کنید و به دنبال فایل‌های .php ناآشنا که از ۲۰ اکتبر ۲۰۲۶ (۲۸ مهر ۱۴۰۵) به بعد ساخته یا تغییر کرده‌اند بگردید.
• پوشه wp-content/uploads در حالت عادی نباید هیچ فایل .php داشته باشد.
• اگر در سی‌پنل ابزار Imunify360 فعال است، یک اسکن بدافزار کامل اجرا کنید.
• در پیشخوان وردپرس، فهرست کاربران را برای حساب‌های مدیر ناشناس بررسی کنید.

۵. اگر به نفوذ مشکوک هستید

رمز عبور سی‌پنل، حساب‌های FTP، دیتابیس و مدیران وردپرس را تغییر دهید و از طریق تیکت با پشتیبانی تماس بگیرید تا بررسی و پاک‌سازی سرویس شما انجام شود. در صورت نیاز، بازگردانی سایت از نسخه پشتیبان مربوط به قبل از ۲۰ اکتبر ۲۰۲۶ هم امکان‌پذیر است.

آموزش برای مدیران سرور با دسترسی WHM و root

این بخش برای کسانی است که سرور هاستینگ (سی‌پنل/WHM) را خودشان مدیریت می‌کنند، مثلاً روی یک سرور مجازی یا اختصاصی، و به SSH با کاربر root دسترسی دارند. دستورات زیر برای سرورهای cPanel روی CloudLinux، AlmaLinux و Rocky Linux نوشته شده‌اند. روی این سرورها معمولاً دو دسته PHP وجود دارد: alt-php که CloudLinux ارائه می‌دهد و ea-php که از EasyApache 4 سی‌پنل نصب می‌شود. هر دو باید به‌روز شوند.

مرحله ۱: شناسایی سیستم‌عامل و نسخه‌های نصب‌شده PHP

با SSH و کاربر root وارد سرور شوید و دستورات زیر را اجرا کنید:

cat /etc/redhat-release
rpm -qa 'alt-php*-common' 'ea-php*-php-cli' | sort
whmapi1 php_get_vhost_versions

دستور اول نسخه سیستم‌عامل (مثلاً CloudLinux 9)، دستور دوم همه پکیج‌های PHP نصب‌شده و دستور سوم نسخه PHP هر دامنه را نشان می‌دهد. خروجی را نگه دارید تا پس از آپدیت مقایسه کنید.

مرحله ۲: به‌روزرسانی سی‌پنل

/scripts/upcp

این دستور خود سی‌پنل و PHP داخلی آن را به‌روز می‌کند. توجه کنید که به‌روزرسانی سی‌پنل به تنهایی کافی نیست و PHP سایت‌ها (alt-php و ea-php) جداگانه باید آپدیت شوند.

مرحله ۳: نصب پکیج‌های Patch شده alt-php و ea-php

روی CloudLinux، AlmaLinux و Rocky Linux نسخه ۸ و ۹:

dnf clean all && dnf upgrade -y 'alt-php*' 'ea-php*'

روی CloudLinux 7 و CentOS 7:

yum clean all && yum update -y 'alt-php*' 'ea-php*'

نکته: گزینه -y را حذف نکنید. اگر بدون آن دستور را اجرا کنید و هنگام سؤال Is this ok [y/N] کیبورد روی زبان فارسی باشد، dnf به جای حرف y یک حرف فارسی دریافت می‌کند و با خطای UnicodeDecodeError متوقف می‌شود، بدون اینکه چیزی نصب شود.

اگر از مخزن Hardened PHP ایمونیفای برای ea-php استفاده می‌کنید، این دستور را هم اجرا کنید:

dnf update -y "ea*" --enablerepo=imunify360-ea-php-hardened --refresh

مرحله ۴: ری‌استارت وب‌سرور و پروسس‌های PHP

این مرحله را به هیچ عنوان جا نیندازید؛ پروسس‌هایی که از قبل در حال اجرا هستند کد آسیب‌پذیر قدیمی را در حافظه نگه می‌دارند، حتی اگر پکیج جدید نصب شده باشد.

روی سرورهای با وب‌سرور آپاچی:

/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

روی سرورهای با وب‌سرور LiteSpeed:

/usr/local/lsws/bin/lswsctrl restart
pkill -f lsphp

LiteSpeed در حالت detached پروسس‌های lsphp را حتی بعد از ری‌استارت زنده نگه می‌دارد؛ دستور دوم آن‌ها را می‌بندد و با اولین درخواست به سایت، با نسخه جدید دوباره ساخته می‌شوند. برای اطمینان، زمان شروع پروسس‌ها را ببینید؛ همه باید بعد از زمان ری‌استارت باشند:

ps -eo pid,lstart,cmd | grep [l]sphp

مرحله ۵: بررسی قطعی نصب Patch

چون CloudLinux شماره نسخه را تغییر نمی‌دهد، ملاک درستی Patch، وجود شناسه CVE در تغییرات (changelog) پکیج است. این حلقه همه پکیج‌های PHP سرور را یک‌جا بررسی می‌کند:

for p in $(rpm -qa 'alt-php*-common' 'ea-php*-php-cli'); do
  if rpm -q --changelog "$p" | grep -qE 'CVE-2026-109618'; then echo "OK      $p"; else echo "NOFIX   $p"; fi
done

جلوی هر پکیج Patch شده عبارت OK و جلوی پکیج‌های Patch نشده NOFIX نوشته می‌شود. برای دیدن جزئیات یک پکیج خاص:

rpm -q --changelog alt-php84-common | grep -E 'CVE-2026-(109618|109619)'

اگر خروجی خالی بود، آن پکیج هنوز Patch نشده است؛ مرحله ۳ را تکرار کنید. پکیج alt-php-internal مخصوص ابزارهای داخلی CloudLinux است و درخواست‌های وب را پردازش نمی‌کند؛ بنابراین NOFIX بودن آن خطری برای سایت‌ها ندارد، هرچند می‌توانید با dnf upgrade -y 'alt-php-internal*' آن را هم به‌روز کنید.

مرحله ۶: به‌روزرسانی قوانین Imunify360

اگر Imunify360 روی سرور نصب است، قوانین فایروال وب (WAF) آن را به‌روز کنید:

imunify360-agent update --force modsec-rules
cat /etc/apache2/conf.d/modsec_vendor_configs/imunify360-full-apache/VERSION

نسخه قوانین باید 8.85 یا بالاتر باشد (روی LiteSpeed مسیر این فایل متفاوت است). توجه کنید که این قوانین فقط مسیر حمله CVE-2026-109619 را می‌بندند و در برابر CVE-2026-109618 محافظتی ندارند؛ پس جایگزین آپدیت PHP نیستند.

مرحله ۷: انتقال سایت‌ها از نسخه‌های قدیمی PHP

در WHM به مسیر Software > MultiPHP Manager بروید و دامنه‌هایی که هنوز روی PHP 8.1 یا پایین‌تر هستند را به نسخه 8.2 یا بالاتر منتقل کنید. هرچند CloudLinux برای برخی نسخه‌های قدیمی alt-php هم Patch منتشر کرده، این نسخه‌ها دیگر پشتیبانی رسمی ندارند و آسیب‌پذیری‌های بعدی را دریافت نخواهند کرد.

اگر فعلاً امکان آپدیت ندارید

راهکار موقت پیشنهادی PHP، خاموش کردن قابلیت گزارش پیشرفت آپلود در تنظیمات PHP است. این کار را در WHM از مسیر MultiPHP INI Editor یا در فایل php.ini انجام دهید:

session.upload_progress.enabled = 0

این تنظیم فقط بخشی از مسیرهای حمله را می‌بندد و طبق اعلام PHP هیچ تنظیمی آسیب‌پذیری را به طور کامل رفع نمی‌کند. به محض امکان، آپدیت را انجام دهید و پس از نصب Patch این تنظیم موقت را بردارید.

اقدام برای سرورهای لینوکسی بدون کنترل پنل

ابتدا برای بررسی نسخه فعلی پی‌اچ‌پی در ترمینال دستور زیر را وارد کنید:

php -v

دستورات به‌روزرسانی برای اوبونتو و دبیان

sudo apt update
sudo apt install --only-upgrade 'php*'

دستورات به‌روزرسانی برای سن‌توس، فدورا، راکی و آلما لینوکس

sudo dnf upgrade 'php*'

نکته مهم: پس از پچ کردن، حتماً وب‌سرور یا PHP-FPM را ری‌استارت کنید تا پردازش‌های آسیب‌پذیر متوقف شوند. مثلاً در اوبونتو با PHP 8.3:

sudo systemctl restart php8.3-fpm
sudo systemctl restart nginx

سوالات متداول (FAQ) درباره رفع آسیب‌پذیری PHP

من هاست اشتراکی دارم؛ آیا باید کاری انجام دهم؟

نصب Patch بر عهده ارائه‌دهنده هاست است و روی سرورهای هاست ایران وی ام انجام شده است. کافی است نسخه PHP سایت را روی 8.2 یا بالاتر قرار دهید، وردپرس و افزونه‌ها را به‌روز نگه دارید و موارد بخش مشترکین هاست را بررسی کنید.

نسخه PHP سرور من 8.4.26 است؛ یعنی هنوز آسیب‌پذیر هستم؟

نه لزوماً. روی CloudLinux و برخی توزیع‌های لینوکس، Patch بدون تغییر شماره نسخه نصب می‌شود. روش مطمئن، بررسی changelog پکیج طبق مرحله ۵ بخش مدیران WHM است.

آیا پس از آپدیت نیاز به ری‌استارت سرور است؟

ری‌استارت کل سرور لازم نیست، اما ری‌استارت وب‌سرور و پروسس‌های PHP (PHP-FPM، آپاچی یا lsphp در LiteSpeed) الزامی است؛ در غیر این صورت کد قدیمی همچنان در حافظه اجرا می‌شود.

چگونه مطمئن شویم که فرآیند پچ امنیت PHP کامل شده است؟

اگر PHP را از سایت رسمی یا مخازنی که نسخه را عوض می‌کنند نصب کرده‌اید، نسخه خود را با لیست اصلاح‌شده (8.5.12، 8.4.27، 8.3.36، 8.2.35) مقایسه کنید. روی CloudLinux، Red Hat و Debian، وجود شناسه‌های CVE-2026-109618 و CVE-2026-109619 در changelog پکیج ملاک است.

آیا فایروال Imunify360 به تنهایی کافی است؟

خیر. قوانین Imunify360 فقط جلوی یکی از دو مسیر حمله (CVE-2026-109619) را می‌گیرند و تنها راه رفع کامل، نصب Patch PHP است.

جمع‌بندی نهایی

مقابله با هرگونه آسیب‌ پذیری PHP مستلزم پچ سریع و به‌روزرسانی مداوم است تا از هک شدن و سوءاستفاده‌های احتمالی جلوگیری شود. اگر مشترک هاست هستید، نسخه PHP سایت و افزونه‌های وردپرس خود را بررسی کنید؛ و اگر سرور خودتان را مدیریت می‌کنید، پس از آپدیت پکیج‌ها حتماً سرویس‌ها را ری‌استارت کرده و Patch را با changelog تأیید کنید.

به دنبال بستر میزبانی کاملاً امن و پرسرعت هستید؟
برای پیاده‌سازی پروژه‌های حرفه‌ای و استقرار امن سیستم‌ها، همین حالا می‌توانید از پکیج‌های استاندارد سرور مجازی ایران در ایران وی ام (IRVM) استفاده کنید.

منابع: این مقاله بر اساس گزارش رسمی وبلاگ دیجیتال اوشن (DigitalOcean Blog)، راهنمای Imunify360 و CloudLinux و تجربه تیم فنی ایران وی ام در Patch سرورهای هاست تهیه و بومی‌سازی شده است.