آسیب پذیری PHP در ۲۰۲۶ (PHP۲Shell)؛ آموزش آپدیت امنیتی در سی پنل و وردپرس

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

در این مقاله مو به مو توضیح می دهیم دقیقا چه اتفاقی افتاده، چرا هیچ تنظیم یا افزونه خاصی برای سوءاستفاده لازم نیست، کدام نسخه های PHP امن و کدام در خطرند و بعد از آن یک راهنمای گام به گام و عملی می دهیم: چطور روی سرور سی پنل با EasyApache ۴، سرور لینوکسی بدون کنترل پنل و یا حتی روی هاست اشتراکی، سایت وردپرسی تان را همین امروز امن کنید. دستورات را عینا کپی کنید و اجرا کنید؛ در انتها هم روش تایید نهایی داریم که مطمئن شوید پچ واقعا اعمال شده است.

PHP2Shell چیست و دقیقا چه اتفاقی افتاده؟

ماجرا از یک اطلاعیه پیشاپیش شروع شد: ۲۰ اکتبر ۲۰۲۶ تیم امنیتی PHP اعلام کرد فردا یک بروزرسانی امنیتی بحرانی منتشر می شود و هر کس PHP اجرا می کند باید همان لحظه آپدیت کند. این خودش نشانه جدی بودن ماجرا بود؛ چون پروژه PHP معمولا چنین هشدار قبلی نمی دهد. طبق گزارش اداره BSI آلمان، این دو حفره را تیم های امنیتی Wiz و Calif به همراه OpenAI کشف کرده اند و بعد از انتشار وصله، ENISA (مرکز اروپایی امنیت سایبری) هم یک بیانیه مشترک برای همه کشور های عضو منتشر کرد.

چرا اسمش PHP2Shell شد؟ چون قیاس مستقیمی با Log4Shell است؛ همان حفره معروف سال ۲۰۲۱ که یک درخواست ساده کافی بود تا مهاجم کنترل کامل سرور را بگیرد. اینجا هم وضعیت مشابه است: یک درخواست HTTP ساده که به هر آدرسی از سایت شما برسد و توسط PHP پردازش شود، می تواند به اجرای کد دلخواه مهاجم تبدیل شود. طبق اطلاعیه رسمی php.net، تمام نصب های PHP که درخواست های وب را پاسخ می دهند در خطرند؛ از PHP-FPM و mod_php و php-cgi گرفته تا FrankenPHP و حتی LiteSpeed که در خیلی از هاستینگ های ایرانی و خارجی استفاده می شود.

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

دو آسیب پذیری به زبان ساده؛ چه چیزی خراب است؟

هر دو حفره در یکی از حساس ترین لحظه های زندگی یک درخواست PHP رخ می دهند: وقتی PHP در حال آماده کردن یا جمع کردن داده های داخلی درخواست است و هنوز همه چیز کامل و معتبر نشده.

• CVE-۲۰۲۶-۱۰۹۶۱۸ (خرابی حافظه در حالت کمبود حافظه): وقتی حافظه PHP تمام می شود (مثلا با آپلود درشت و حساب شده ای که عمدا حافظه را پر کند)، PHP وسط کار قطع می شود؛ اما داده های ناقص و نیمه آماده درخواست هنوز در حافظه اند. در مرحله پاک سازی، سیستم این داده های خراب را به جای داده معتبر قبول می کند و همین نقطه، دریچه اجرای کد مهاجم می شود. مسیر تایید شده این حمله از قابلیت آپلود پیشرفت (upload progress) عبور می کند که به طور پیش فرض روشن است.
• CVE-۲۰۲۶-۱۰۹۶۱۹ (وضعیت سرسالات باقی مانده): داده هایی که مال یک درخواست اند، بعد از آزاد شدن حافظه شان از بین نمی روند. اگر همان worker کمی بعد درخواست دیگری را همکاری کند، ممکن است قبل از مقدار دهی اولیه، به آن داده های کهنه برسد و از روی آنها تصمیم بگیرد. تازه درخواست دوم بدون هیچ گناهی، زندانی داده های مسموم درخواست قبلی می شود.

ترجمه عملی هر دو یکی است: اجرای کد دلخواه مهاجم روی سرور شما (RCE)؛ بدون نیاز به اکانت در سایت، بدون نیاز به کلیک یا تعامل کاربر و بدون نیاز به هیچ پیکربندی خاصی روی سرور. دو شرکت امنیتی VulnCheck و watchTowr از همان ساعت های اول (حتی قبل از انتشار رسمی وصله) اسکن های گسترده اینترنتی با ابزاری عمومی به نام php2shell ثبت کرده اند؛ یعنی مهاجم ها خبر را شنیده اند و در حال کاوش کردن اینترنت برای پیدا کردن قربانی های بی خبر هستند.

چه کسانی و چه چیزهایی در خطرند؟

طبق اطلاعیه رسمی PHP و تایید BSI، شرایط زیر همه با هم درست هستند و همین است که این خبر را از باگ های معمول جدا می کند:

سوال	پاسخ کوتاه
آیا همه نسخه های PHP در خطرند؟	بله؛ از PHP ۵ به بالا همه. فقط ۴ نسخه تازه منتشر شده امن اند.
آیا حمله نیاز به لاگین یا اکانت دارد؟	هیچ. یک درخواست ناشناس کافی است.
آیا تنظیم یا افزونه خاصی لازم است؟	نه؛ هیچ پیکربندی خاصی شرط نیست. هر سایت PHP ای هدف است.
کدام حالت اجرا خطرناک تر است؟	mod_php داخل Apache؛ اکسپلویت تایید شده قبل از اجرای کد برنامه فعال می شود.
PHP-FPM و LiteSpeed هم در خطرند؟	بله؛ همه روش های اجرا شامل FPM، php-cgi، FrankenPHP و LiteSpeed.
آیا سایت های HTML ساده هم در خطرند؟	نه؛ فقط جایی که PHP در پردازش درخواست نقش دارد در خطر است. سایت تمام استاتیک بدون PHP مشکلی ندارد.

بزرگترین ارائه دهنده های هاست اروپا واکنشان نشان می دهد این موضوع شوخی نیست: Hetzner آلمان بلافاصله بعد از انتشار وصله، همه نسخه های PHP روی سرورهای هاستینگ و مدیریت شده خود را (حتی نسخه های قدیمی ۵.۶ و ۷.۳) پچ کرد و همین را در صفحه وضعیت رسمی اش اعلام کرد؛ حتی ابزار های جانبی مثل phpMyAdmin و وب میل که با PHP کار می کنند را هم بروزرسانی کرد.

جدول نسخه های امن و در خطر

اگر امروز فقط یک جدول را از این مقاله با خود ببرید، همین باشد:

نسخه PHP	وضعیت	نسخه امن	توضیح
8.5	در خطر تا ۸.۵.۱۱	8.5.12	جدیدترین شاخه؛ سریع ترین مسیر آپدیت
8.4	در خطر تا ۸.۴.۲۶	8.4.27	انتخاب پیشنهادی برای اکثر سایت ها
8.3	در خطر تا ۸.۳.۳۵	8.3.36	پایدار و کاملا قابل قبول
8.2	در خطر تا ۸.۲.۳۴	8.2.35	توجه: پشتیبانی این شاخه ۳۱ دسامبر ۲۰۲۶ تمام می شود؛ برنامه مهاجرت به ۸.۳ را بچینید
8.1 و قدیمی تر	در خطر	وصله رسمی ندارد	EOL است؛ فقط میتیگیشن یا مهاجرت. توزیع های لینوکس و فروشندگان LTS ممکن است وصله پشتی برون داشته باشند

تیم PHP برای نسخه های ۷.۴ و ۸.۰ و ۸.۱ صرفا backport های سورس منتشر کرده که برای کسانی است که خودشان از سورس بیلد می کنند یا از فروشنده LTS می گیرند؛ برای کاربر عادی یعنی فقط یک پیام: باید به ۸.۲.۳۵ یا بالاتر بروید. اگر این جدول را دیدید و نسخه سایت تان ۸.۱ یا پایین تر است، مهاجرت را از همین امروز شروع کنید؛ بخش پایین مقاله برای همین است.

آیا سایت وردپرسی من در خطر است؟

بله و به شکل جدی. تقریبا ۴۰ درصد همه سایت های دنیا روی وردپرس است و وردپرس با PHP کار می کند؛ یعنی این حفره مستقیما پشت در خانه صدها هزار سایت فروشگاهی و شرکتی ایرانی است. اما یک سوءتفاهم رایج را همین جا حل کنیم:

• این حفره باگ خود وردپرس نیست. وردپرس و ووکامرس و افزونه ها تازه زیر خط آتش اند؛ مشکل در مفسر PHP است که زیر همه این ها کار می کند.
• آپدیت کردن وردپرس و افزونه ها کار درستی است اما برای این حفره کافی نیست؛ مهاجم قبل از رسیدن به وردپرس، در لایه PHP فرود می آید.
• افزونه های امنیتی و فایروال افزونه ای مثل Wordfence در لایه اپلیکیشن کار می کنند؛ این حمله در لایه ای پایین تر اتفاق می افتد. رول های سطح سرور (مثل ModSecurity و Imunify360) می توانند ردپای درخواست های مشکوک را بگیرند و حتما باید بروزرسانی شوند، اما طبق تایید خود php.net، هیچ میتیگیشنی جای آپدیت را نمی گیرد.
• اگر سایت تان روی وردپرس است و روی هاست اشتراکی است، امروز نسخه PHP هاست تان را چک کنید و اگر قدیمی بود، تیکت فوری بزنید. بخش مربوطه را در پایین آورده ایم.

گام ۱: وضعیت فعلی سرور سی پنل را دقیق ببینید

قبل از هر آپدیتی باید بدانید روی سرور چند نسخه PHP نصب است، کدام اکانت ها از کدام نسخه استفاده می کنند و هندلر (روش اتصال به Apache) تان چیست. به WHM نمی خواهید بروید؛ همه با ترمینال SSH انجام می شود. این دستورات فقط وضعیت را نشان می دهند و هیچ چیزی را تغییر نمی دهند:

# exact versions of all installed EA4 PHP packages
rpm -qa | grep -E '^ea-php[0-9]+' | sort

# which PHP handler is active? (mod_php / lsapi / php-fpm)
httpd -M 2>/dev/null | grep -iE 'php|lsapi|fcgi'

# quick EA4 profile summary (packages + versions + handlers)
/usr/local/cpanel/bin/ea-summary | head -40

# which PHP version each cPanel account uses
whmapi1 php_get_vhost_versions | head -40

سه نکته را در خروجی چک کنید:

• بسته های ea-php: احتمالا چند نسخه موازی نصب است (مثلا ۸.۱ و ۸.۲ و ۸.۳). همه نسخه هایی که اکانتی رویشان است باید آپدیت شوند؛ نه فقط یکی.
• هندلر: اگر در خروجی httpd چیزی شبیه php_module دیدید یعنی روی mod_php هستید؛ همان حالت پرخطر این ماجرا. اگر ea-phpXX-php-fpm دیدید روی FPM هستید و اگر lsapi دیدید روی mod_lsapi. هر سه بعد از آپدیت امن می شوند، اما این تفاوت را در گام ۴ یادتان باشد.
• نسخه های قدیمی: اگر ea-php81 یا پایین تر نصب است و اکانتی روی آن نشسته، برای همان اکانت ها باید برنامه مهاجرت بچینید (گام ۵).

گام ۲: آپدیت امنیتی PHP در سی پنل (EasyApache ۴)

cPanel بسته های پچ شده EasyApache ۴ را در قالب نسخه v25.91 منتشر کرده و روی مخازن رسمی خود قرار داده؛ پس سرور سی پنل شما که همین مخازن را دارد، فقط به یک آپدیت ساده نیاز دارد. قبل از شروع یک نکته حرفه ای: اگر می توانید یک اسنپشات یا بکاپ سریع از سرور بگیرید؛ آپدیت های EA4 معمولا بی دردسرند اما اصول امنیت همیشه همین است.

# refresh repo metadata
yum clean expire-cache

# install all patched EA4 PHP packages (security release v25.91)
yum update 'ea-php*'

چند نکته مهم درباره این آپدیت:

• از yum –security استفاده نکنید. متادیتای امنیتی (OVAL) این بسته ها هنوز منتشر نشده و ممکن است yum اصلا چیزی برای نصب پیدا نکند. آپدیت معمولی همان دستور بالا درست است.
• اگر روی سرور شما CloudLinux نصب است و اکانت ها از alt-php (PHP انتخابی داخل CageFS) هم استفاده می کنند، آن ها را هم جدا بروزرسانی کنید: yum update 'alt-php*'. تا تاریخ ۲۲ اکتبر، بسته های پچ شده alt-php برای همه شاخه ها هنوز روی مخازن CloudLinux ۷ و ۸ و ۹ نرسیده بودند؛ اگر چیزی برای نصب پیدا نشد، میتیگیشن های گام ۶ را برای اکانت های alt-php اعمال کنید و صفحه بلاگ رسمی CloudLinux را برای انتشار بسته ها دنبال کنید.
• اگر آپدیت خطا داد یا چیزی نصب نکرد، اول بسته cloudlinux-release خود را بروزرسانی کنید: yum update cloudlinux-release && yum clean all و بعد دوباره آپدیت PHP را اجرا کنید.

مسیر دوم برای کسانی است که ترجیح می دهند از WHM کار کنند: از منوی Software وارد EasyApache 4 شوید و پروفایل فعلی را Review و بعد Provision کنید تا بسته های جدید نصب شوند. نتیجه هر دو روش یکی است؛ ولی روش ترمینال سریع تر است و همین امروز توصیه ما همین است.

گام ۳: ریستارت سرویس ها؛ بدون این کار آپدیت نصفه است!

اگر Apache و PHP-FPM را ریستارت نکنید، بسته جدید روی دیسک است ولی نسخه قدیمی هنوز در حافظه دارد و درخواست ها را پاسخ می دهد. این پرطرفدارترین اشتباه این روزهاست و متاسفانه سایت هنوز آسیب پذیر می ماند:

# restart Apache
/scripts/restartsrv_httpd

# restart Apache PHP-FPM (all EA4 php-fpm services)
/scripts/restartsrv_apache_php_fpm

اگر ترجیح می دهید دستی، سرویس هر نسخه را جدا ریستارت کنید: systemctl restart ea-php82-php-fpm و همین برای ۸۳ و ۸۴ و ۸۵. بعد از ریستارت، یک بار از خارج سرور سایت تان را باز کنید و از سالم بودن صفحه اصلی مطمئن شوید.

گام ۴: تایید نهایی که واقعا پچ شده اید

نسخه های PHP نصب شده را دوباره چک کنید و بعد تایید قطعی را از چنج لاگ بسته ها بگیرید. این روشی است که خود CloudLinux هم رسما توصیه می کند، چون بعضی بسته ها وصله را به صورت backport می گیرند و شماره نسخه PHP شان عوض نمی شود؛ پس به اعداد بسنده نکنید:

# show the running PHP version of every installed branch
for v in 82 83 84 85; do
  [ -x /opt/cpanel/ea-php$v/root/usr/bin/php ] && echo -n "ea-php$v => " && /opt/cpanel/ea-php$v/root/usr/bin/php -v | head -1
done

# the authoritative check: CVE IDs inside the package changelog
rpm -q ea-php84-php-cli --changelog | grep -E 'CVE-2026-(109618|109619)'
rpm -q ea-php83-php-cli --changelog | grep -E 'CVE-2026-(109618|109619)'

# nothing left to install?
yum check-update 'ea-php*' | head

خروجی مطلوب این است: ea-php85 روی ۸.۵.۱۲، ea-php84 روی ۸.۴.۲۷، ea-php83 روی ۸.۳.۳۶ و ea-php82 روی ۸.۲.۳۵ (یا چنج لاگ حاوی شناسه دو CVE). اگر هر کدام از نسخه های نصب شده هنوز عدد قدیمی را نشان می دهد و چنج لاگ هم خالی است، یعنی آن شاخه آپدیت نشده؛ دوباره گام ۲ و ۳ را برای آن چک کنید یا اگر نسخه EOL است به گام ۵ بروید.

گام ۵: نسخه های EOL (۸.۱ و قدیمی تر) را مهاجرت دهید

اول ببینید اصلا نسخه منسوخ روی سرور دارید یا نه:

rpm -qa | grep -E '^ea-php(5[0-9]|7[0-4]|8[01])-' || echo "OK: no EOL PHP"

اگر خروجی داد، لیست اکانت های روی آن نسخه را پیدا کنید و در WHM از بخش MultiPHP Manager نسخه آنها را به ea-php83 یا ea-php84 منتقل کنید. این کار چند دقیقه بیشتر طول نمی کشد اما قبل از تغییر، یک بکاپ کامل از آن اکانت ها بگیرید و بعد از تغییر چند دقیقه سایت و لاگ خطاها را زیر نظر داشته باشید؛ اگر افزونه قدیمی با نسخه جدید PHP مشکل داشته باشد معمولا در همان دقایق اول خودش را نشان می دهد و راه حل هم ارتقای افزونه یا قالب است.

سرور لینوکسی بدون کنترل پنل چطور؟

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

# Debian / Ubuntu
apt update && apt full-upgrade -y
systemctl restart apache2   # or: systemctl restart nginx php8.4-fpm

# AlmaLinux / Rocky / CentOS / RHEL
dnf update -y
systemctl restart httpd     # or: systemctl restart php-fpm

اگر از مخزن Remi (rpms.remirepo.net) استفاده می کنید حواستان باشد؛ طبق هشدار خود PHP این مخزن روز اول بروزرسانی نداشته و باید تا انتشار بسته هایش صبر کنید یا موقتا به بسته های توزیع سوییچ کنید. کانتینر Docker هم اگر دارید، ایمیج پایه را دوباره pull و rebuild کنید: docker pull php:8.4-apache و بعد ایمیج اپلیکیشن را از نو بسازید و بالا بیاورید؛ ایمیج قدیمی مانده روی سرور همان آسیب پذیری را دارد.

هاست اشتراکی دارید؟ کار شما این سه قدم است

به عنوان کاربر هاست اشتراکی، شما دسترسی root ندارید و آپدیت بسته های PHP کار شرکت هاستینگ است؛ اما کار های مشخصی از دستتان برمی آید:

• قدم اول، چک نسخه: وارد سی پنل شوید و بخش MultiPHP Manager (یا Select PHP Version) را باز کنید و نسخه فعلی را ببینید. راه دیگر بدون خروج از وردپرس: از پیشخوان وارد ابزار ها، سلامت سایت (Site Health) شوید و در تب اطلاعات، بخش سرور را ببینید.
• قدم دوم، تیکت فوری: به پشتیبانی هاست تیکت بزنید و بنویسید: آیا بسته های PHP سرور برای CVE-۲۰۲۶-۱۰۹۶۱۸ و CVE-۲۰۲۶-۱۰۹۶۱۹ پچ شده اند؟ یک هاست مسئول، یا از قبل پچ کرده یا همین روز ها جواب دقیق می دهد. تاخیر و جواب مبهم، خودش علامت خطر است.
• قدم سوم، سوییچ به شاخه امن: اگر هاست تان فقط آپدیت را روی بعضی شاخه ها اعمال کرده، از همان MultiPHP Manager نسخه اکانت خود را به ۸.۳ یا ۸.۴ ببرید (قبل از آن یک بکاپ کامل بگیرید). اگر سایت تان هنوز روی ۸.۱ یا پایین تر است، جدی ترین جواب این است که فکر مهاجرت به هاستی با نرم افزار به روز را بکنید.

اگر همین امروز نمی توانید آپدیت کنید: میتیگیشن های موقت

خود php.net صریح گفته: هیچ جایگزینی برای آپدیت وجود ندارد و این تنظیمات فقط بعضی مسیر های حمله را سخت می کنند. با این حال اگر سروری دارید که بسته پچ شده برایش هنوز منتشر نشده (مثلا alt-php روی CloudLinux)، این ها را اعمال کنید و بعد از آپدیت اصلی حذفشان نکنید فراموشی:

تنظیم موقت	برای کدام حفره	نکته اجرا
session.upload_progress.enabled=0	CVE-2026-109619	در php.ini یا FPM pool و بعد ریستارت همه worker ها؛ با ini_set و user.ini تاثیری ندارد
memory_limit=-1	CVE-2026-109618	با php_admin_value تا اپلیکیشن نتواند عوضش کند؛ مطمئن شوید هیچ تنظیم دیگری عدد محدود برنگرداند
post_max_size = 8M (اگر آپلود لازم نیست) یا 32M	CVE-2026-109618	حجم درخواست های آپلود را کوچک نگه می دارد؛ upload_max_filesize باید کوچکتر باشد
fatal_error_backtraces=0 (فقط PHP ۸.۵)	CVE-2026-109619	یکی از مسیر های تایید شده را می بندد؛ بعد از آپدیت لازم نیست
آپدیت رول های WAF سطح سرور	هر دو	Imunify360 رول های بلاک را در ruleset های ۸.۸۴ و ۸.۸۵ آورده؛ با دستور پایین بروزرسانی و چک کنید
جداسازی موقت اپلیکیشن های اینترنتی	هر دو	توصیه CERT-EU برای وقتی که هیچ راه دیگری نیست؛ آخرین گزینه، نه اولین

اگر Imunify360 دارید، وضعیت رول ها را چک و بروزرسانی کنید:

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

رد پای مهاجم ها را در لاگ های سرور بگردید

ابزار اسکنر عمومی این حمله، خودش را با یک ردپای واضح در User Agent نشان می دهد؛ VulnCheck از ساعت های اول رشته هایی مثل php2shell-scan/109618 و php2shell-poc و php2shell-verify/1.0 ثبت کرده. یک بررسی سریع روی لاگ های Apache سی پنل می گوید آیا کسی در این روز ها سراغ سرور شما آمده یا نه:

# any php2shell footprint in access logs?
grep -l "php2shell" /usr/local/apache/domlogs/* 2>/dev/null

# suspicious probing of php info pages
grep -hE "GET /(phpinfo|info|test|php)\.php" /usr/local/apache/domlogs/* 2>/dev/null | head

# block known scanner sources reported by VulnCheck (optional, CSF)
csf -d 85.11.167.243 "php2shell scanner"
csf -d 45.198.224.169 "php2shell scanner"
csf -d 221.14.159.134 "php2shell exploit attempt"

اگر از این جستجو چیزی پیدا شد، آدم بدشانسی نبوده اید؛ باید فرض را بر این بگذارید که مهاجم به سرور دسترسی پیدا کرده و عمیق تر بررسی کنید: فایل های PHP که در چند روز اخیر تغییر کرده اند، فایل های سشن بزرگ و ناشناس در مسیر tmp، کرون جاب های جدید و اکانت های جدید و ناشناس. برای این حالت، یک بررسی امنیتی تخصصی جدا لازم است و اگر سوالی داشتید پشتیبانی نگارنوین کنار شماست.

اشتباهات رایج در این آپدیت که نباید مرتکب شوید

اشتباه	عاقبت	کار درست
فقط یک نسخه PHP را آپدیت کردن	اکانت های روی بقیه نسخه ها باز در خطر	همه شاخه های فعال سرور: yum update 'ea-php*'
ریستارت نکردن Apache و PHP-FPM	بسته جدید نصب، نسخه قدیمی در حافظه؛ سایت هنوز آسیب پذیر	دو دستور ریستارت گام ۳، بعد چک خروجی گام ۴
تکیه بر yum –security	این بسته ها در متادیتای امنیتی نیستند و چیزی نصب نمی شود	آپدیت معمولی با گلوب ea-php*
بسنده کردن به عدد نسخه	بسته های backport شده شماره نسخه قدیمی را دارند؛ آدم به اشتباه فکر می کند پچ نشده یا برعکس	چنج لاگ بسته را با شناسه CVE چک کنید (گام ۴)
رها کردن اکانت های روی PHP ۸.۱ و قدیمی تر	این شاخه ها وصله رسمی ندارند؛ آسیب پذیری برای همیشه باز می ماند	مهاجرت به ۸.۲.۳۵ به بالا طبق گام ۵
اعتماد کامل به WAF و افزونه امنیتی	رول ها کمک می کنند ولی جای آپدیت را نمی گیرند؛ خود PHP هم تایید کرده	آپدیت اصلی + رول های بروزرسانی شده روی آن

سوالات متداول درباره آسیب پذیری PHP2Shell

آیا سایت من تا الان هک شده؟ چطور بفهمم؟

تا امروز گزارش تایید شده ای از سوءاستفاده موفق گسترده منتشر نشده و شرکت های امنیتی صبح ۲۱ اکتبر هنوز شواهد اکسپلویت موفق نداشتند؛ اما اسکن ها شروع شده. ساده ترین بررسی، جستجوی ردپای php2shell در لاگ هاست است که دستورش را در بخش لاگ ها آوردیم. اگر چیزی پیدا شد، عمیق تر بررسی کنید و اگر سایت رفتار عجیبی داشت (فایل های ناشناس، ریدایرکت، تبلیغ اضافه) آن را جدی بگیرید.

من فقط کاربر هاست اشتراکی هستم؛ خودم می توانم PHP را آپدیت کنم؟

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

نسخه PHP من ۸.۱ یا قدیمی تر است؛ چه کنم؟

برای این شاخه ها هیچ وصله رسمی وجود ندارد و سه راه دارید: انتقال سایت به نسخه ۸.۲.۳۵ یا بالاتر، گرفتن وصله از فروشنده LTS اگر قرارداد پشتیبانی بلند مدت دارید، یا اعمال میتیگیشن های موقت جدول بالا و برنامه مهاجرت. راه اول را در اکثر موارد توصیه می کنیم.

آیا فایروال یا WAF جلوی این حمله را نمی گیرد؟

رول های تازه WAF مثل رول های ۸.۸۴ و ۸.۸۵ در Imunify360 ردپای حملات شناخته شده را می بندند و قطعا باید بروزرسانی شوند؛ اما چون حمله در لایه خود PHP و قبل از اپلیکیشن اتفاق می افتد، این ها تنها یک لایه کمکی هستند. طبق اطلاعیه رسمی PHP، تنها راه کامل، آپدیت است.

بعد از آپدیت، عدد نسخه PHP همان عدد قدیمی است! یعنی پچ نشده؟

نه لزوما. بعضی فروشندگان (از جمله CloudLinux برای بسته های alt-php و ea-php خود) وصله را به صورت backport می دهند و شماره نسخه را به روز نمی کنند؛ مثلا بسته پچ شده ea-php84 همان ۸.۴.۲۶ را نشان می دهد ولی داخلش وصله هست. معیار قطعی، چنج لاگ بسته است که باید شناسه CVE-۲۰۲۶-۱۰۹۶۱۸ یا CVE-۲۰۲۶-۱۰۹۶۱۹ در آن باشد.

آیا مرورگر بازدیدکنندگان سایت هم باید کاری انجام دهد؟

خیر؛ این حفره کاملا سمت سرور است و هیچ ربطی به مرورگر کاربران ندارد. هیچ نرم افزاری روی کامپیوتر و گوشی بازدیدکنندگان درگیر این ماجرا نیست.

آیا باید سایت را موقتا ببندم تا آپدیت انجام شود؟

برای یک سرور معمولی، نه؛ آپدیت EA4 و ریستارت چند دقیقه بیشتر طول نمی کشد و سایت در همان فاصله هم چند ثانیه قطعی کوتاه دارد. توصیه به جداسازی موقت اپلیکیشن (CERT-EU) فقط برای وضعیت های خاص است: سروری که بسته پچ شده برایش وجود ندارد و میزبانی داده حساسی دارد. جای آن، امروز آپدیت کنید و تمام.

وردپرس و افزونه ها را هم باید بروزرسانی کنم؟

بله، ولی بدانید این دو کار بی ربط به هم هستند: آپدیت PHP همین امروز برای رفع این حفره، و بروزرسانی مرتب وردپرس و افزونه ها برای سلامت کلی سایت در برابر باگ های دیگر. اگر وردپرس چند سال بی آپدیت مانده، بعد از پچ PHP با خیال راحت تر به آن برسید.

جمع بندی؛ امروز کار تمام می شود

یک قاعده قدیمی امنیت را این روزها همه یادشان آمد: وقتی وصله منتشر شد، مسابقه شروع شده است. تیم PHP نسخه های امن را منتشر کرد (۸.۵.۱۲، ۸.۴.۲۷، ۸.۳.۳۶، ۸.۲.۳۵)، cPanel و CloudLinux بسته های EasyApache ۴ را پچ کردند و مهاجم ها هم از شب قبل با ابزار اسکن مشغول گشتن اینترنت هستند. اگر مدیر سرور هستید، دستورات گام ۲ تا ۴ را همین حالا روی سرور اجرا کنید؛ اگر کاربر هاست اشتراکی هستید، سه قدم بخش هاست اشتراکی کار شماست و کل ماجرا کمتر از یک فنجان چای طول می کشد. اگر سرور سی پنل دارید و می خواهید این فشار از روی دوش شما برداشته شود، سرور مجازی نگارنوین و هاست سی پنل نگارنوین با پشتیبانی فنی ۲۴ ساعته در کنار شما هستند؛ همین مقاله هم دقیقا با همین ابزارها و همین دستورات نوشته شده است. سوالی از بخشی از این آپدیت مانده؟ در دیدگاه ها بپرسید تا با جزئیات راهنمایی کنیم.

منابع این مقاله: اطلاعیه رسمی php.net (۲۱ اکتبر ۲۰۲۶)، هشدار BSI آلمان شماره ۲۰۲۶-۲۹۷۹۸۱-۱۲۳۲، اطلاعیه cPanel درباره EasyApache ۴ v25.۹۱، بلاگ رسمی CloudLinux و Imunify360 (۲۱ و ۲۲ اکتبر ۲۰۲۶)، گزارش VulnCheck و صفحه وضعیت Hetzner. برای خواندن متن کامل هر منبع، روی نام آن در اینترنت جستجو کنید.

📄 نحوهٔ استناد به این صفحهنگارنوین، «آسیب پذیری PHP در 2026 (PHP2Shell)؛ آموزش آپدیت امنیتی در سی پنل و وردپرس»، negarnovin.comکپی استناد✓ کپی شد