آسیب پذیری PHP؛ هشدار بحرانی PHP2Shell و خطر اجرای کد روی میلیون‌ها وب‌سایت

هشدار امنیتی فوری | ۲ آبان ۱۴۰۵ – ۲۴ اکتبر ۲۰۲۶

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

دو شناسه امنیتی CVE-۲۰۲۶-۱۰۹۶۱۸ و CVE-۲۰۲۶-۱۰۹۶۱۹ در تاریخ ۲۱ اکتبر ۲۰۲۶ با انتشار به‌روزرسانی‌های اضطراری PHP مورد توجه قرار گرفتند. هر دو آسیب‌پذیری امتیاز ۹.۲ از ۱۰ را در استاندارد CVSS ۴.۰ دریافت کرده‌اند و به دلیل تأثیر احتمالی بر طیف وسیعی از سرورهای وب، نیازمند رسیدگی فوری هستند.

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

در این گزارش تخصصی از پردازش ابری نیماد، جزئیات فنی آسیب‌پذیری PHP2Shell، نسخه‌های آسیب‌پذیر، پیامدهای امنیتی، روش‌های شناسایی و اقدامات لازم برای ایمن‌سازی سرورها را بررسی می‌کنیم.

آسیب پذیری PHP2Shell چیست؟

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

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

مشخصات اصلی این آسیب‌پذیری‌ها عبارت‌اند از:

مشخصه	اطلاعات
نام شناخته‌شده	PHP2Shell
شناسه اول	CVE-2026-109618
شناسه دوم	CVE-2026-109619
شدت	بحرانی (Critical)
امتیاز CVSS ۴.۰	۹.۲ از ۱۰ برای هر آسیب‌پذیری
پیامد اصلی	اجرای کد از راه دور (RCE)
نیاز به احراز هویت	در سناریوهای بهره‌برداری تأییدشده، خیر
تاریخ انتشار وصله	۲۱ اکتبر ۲۰۲۶
اقدام اصلی	نصب نسخه اصلاح‌شده PHP

نکته مهم این است که آسیب‌پذیر بودن یک نسخه PHP لزوماً به معنی امکان بهره‌برداری یکسان در تمام پیکربندی‌ها نیست. میزان مواجهه به نوع اجرای PHP، دسترسی شبکه، شرایط برنامه و وضعیت وصله‌ها بستگی دارد.

با این حال، تیم امنیت PHP صراحتاً توصیه کرده است که تمام نصب‌های PHP که درخواست‌های وب را پردازش می‌کنند، فوراً به‌روزرسانی شوند.

بررسی فنی آسیب پذیری PHP با شناسه CVE-۲۰۲۶-۱۰۹۶۱۸

اولین آسیب‌پذیری بحرانی، CVE-۲۰۲۶-۱۰۹۶۱۸، به مدیریت نادرست وضعیت حافظه هنگام وقوع خطای کمبود حافظه یا Out of Memory مربوط است.

PHP برای کنترل میزان حافظه مصرفی هر درخواست، از تنظیماتی مانند memory_limit استفاده می‌کند. وقتی اجرای یک درخواست از محدودیت تعیین‌شده عبور کند، PHP ممکن است اجرای آن را به‌صورت غیرعادی متوقف کند.

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

مشکل دقیقاً از کجا آغاز می‌شود؟

در سطح فنی، PHP ممکن است هنگام پردازش داده‌های درخواست، از جمله برخی داده‌های مربوط به بارگذاری فایل، با خطای کمبود حافظه مواجه شود.

اگر فرایند پاک‌سازی منابع پس از این خطا، ساختار ناقص یا نامعتبر را به‌عنوان ساختاری معتبر در نظر بگیرد، امکان فساد حافظه ایجاد می‌شود.

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

پیامد امنیتی چیست؟

بهره‌برداری موفق از این وضعیت می‌تواند به اجرای کد دلخواه در محدوده دسترسی پردازش PHP منجر شود.

به بیان ساده، مهاجم ممکن است بتواند به جای اجرای منطق معمول برنامه، رفتار پردازش PHP را تغییر دهد.

این موضوع به‌خصوص زمانی خطرناک است که پردازش وب‌سرور به فایل‌های حساس، اطلاعات ورود یا سرویس‌های داخلی سازمان دسترسی داشته باشد.

بررسی فنی آسیب پذیری PHP با شناسه CVE-۲۰۲۶-۱۰۹۶۱۹

دومین آسیب‌پذیری، CVE-۲۰۲۶-۱۰۹۶۱۹، به باقی ماندن وضعیت داخلی نامعتبر پس از آزاد شدن حافظه مربوط می‌شود.

این دسته از مشکلات با مفاهیمی مانند Use-After-Free و Stale State ارتباط دارند.

Use-After-Free چیست؟

در برنامه‌نویسی سطح پایین، زمانی که یک بخش از حافظه آزاد می‌شود، برنامه نباید دوباره از همان حافظه به‌عنوان یک شیء معتبر استفاده کند.

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

این وضعیت ممکن است به توقف برنامه، افشای اطلاعات یا در شرایط خاص به اجرای کد منجر شود.

مشکل در PHP چگونه رخ می‌دهد؟

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

اگر پردازش PHP درخواست دیگری را دریافت کند و پیش از بازنشانی صحیح وضعیت داخلی از آن داده استفاده کند، امکان سوءاستفاده ایجاد می‌شود.

این موضوع در محیط‌هایی که یک پردازش اجرایی درخواست‌های متوالی را مدیریت می‌کند، اهمیت خاصی دارد.

در نتیجه، تیم‌های امنیتی نباید صرفاً با بررسی کد برنامه تصور کنند که این آسیب‌پذیری برطرف شده است؛ اصلاح باید در لایه 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 ۸.۱ و قدیمی‌تر	خارج از پشتیبانی رسمی بالادستی	ارتقا یا دریافت وصله معتبر از تأمین‌کننده

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

از سوی دیگر، PHP ۸.۲ در پایان دسامبر ۲۰۲۶ به پایان دوره پشتیبانی امنیتی خود می‌رسد. سازمان‌هایی که همچنان از این شاخه استفاده می‌کنند، بهتر است برنامه مهاجرت به نسخه پشتیبانی‌شده را نیز آماده کنند.

چه سرورها و نرم‌افزارهایی در معرض خطر هستند؟

دامنه آسیب پذیری PHP2Shell به یک وب‌سرور خاص محدود نیست.

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

• Apache همراه با mod_php
• PHP-FPM
• php-cgi
• LiteSpeed
• FrankenPHP
• محصولات سازمانی که PHP را در ساختار داخلی خود به کار می‌گیرند

در میان این پیکربندی‌ها، تیم PHP خطر را برای mod_php بالاتر ارزیابی کرده است؛ زیرا بهره‌برداری تأییدشده‌ای وجود دارد که در آن درخواست بدون احراز هویت می‌تواند پیش از اجرای کد برنامه، آسیب‌پذیری را فعال کند.

این مسئله نشان می‌دهد که حتی مکانیزم‌های امنیتی موجود در خود برنامه، لزوماً مانع بهره‌برداری از نقصی در لایه پایین‌تر نمی‌شوند.

آیا Nginx هم آسیب‌پذیر است؟

Nginx به‌تنهایی مفسر PHP نیست؛ اما اگر درخواست‌ها را به نسخه آسیب‌پذیر PHP-FPM ارسال کند، زیرساخت مربوطه باید بررسی و اصلاح شود.

بنابراین، صرف استفاده از Nginx به معنی مصونیت در برابر PHP2Shell نیست.

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

بله. سرورهایی که فقط در شبکه داخلی سازمان قابل دسترس هستند نیز ممکن است آسیب‌پذیر باشند.

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

به همین دلیل، موجودی دارایی‌ها باید هم سرورهای اینترنتی و هم سامانه‌های داخلی را شامل شود.

آیا سایت‌های وردپرسی در معرض آسیب پذیری PHP قرار دارند؟

وردپرس با زبان PHP توسعه یافته است. بنابراین، اگر وب‌سرور یک سایت وردپرسی از نسخه آسیب‌پذیر PHP استفاده کند، باید وضعیت امنیتی آن بررسی شود.

نکته مهم این است که به‌روزرسانی وردپرس، قالب یا افزونه‌ها به‌تنهایی آسیب‌پذیری هسته PHP را اصلاح نمی‌کند.

برای مثال، یک سایت ممکن است شرایط زیر را داشته باشد:

• آخرین نسخه وردپرس نصب شده باشد.
• تمام افزونه‌ها به‌روز باشند.
• قالب سایت از منبع معتبر تهیه شده باشد.
• دسترسی مدیر با احراز هویت دومرحله‌ای محافظت شود.

با وجود همه این اقدامات، اگر PHP اجراکننده درخواست‌ها وصله نشده باشد، خطر PHP2Shell همچنان می‌تواند وجود داشته باشد.

مدیران سایت‌های وردپرسی باید از شرکت هاستینگ بخواهند وضعیت وصله PHP را تأیید کند.

در سرویس‌های میزبانی اشتراکی، ممکن است مدیر سایت امکان به‌روزرسانی مستقیم بسته PHP را نداشته باشد؛ در این شرایط مسئولیت اعمال وصله در لایه سرور بر عهده ارائه‌دهنده میزبانی است.

پیامدهای احتمالی بهره‌برداری از آسیب پذیری PHP

اجرای کد از راه دور یکی از جدی‌ترین پیامدهای امنیتی برای یک سرور محسوب می‌شود.

در صورت بهره‌برداری موفق، مهاجم ممکن است بسته به سطح دسترسی پردازش و کنترل‌های امنیتی موجود، اقدامات زیر را انجام دهد.

دسترسی به اطلاعات حساس

فایل‌های پیکربندی برنامه ممکن است حاوی اطلاعات اتصال به پایگاه داده، توکن‌ها یا کلیدهای دسترسی باشند.

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

تغییر محتوای وب‌سایت

مهاجم ممکن است بتواند فایل‌های قابل نوشتن را تغییر دهد، صفحات مخرب ایجاد کند یا رفتار برنامه را دست‌کاری کند.

ایجاد دسترسی پایدار

در صورت وجود مجوزهای کافی، امکان تلاش برای ایجاد فایل‌ها یا مکانیزم‌های دسترسی غیرمجاز وجود دارد.

استفاده از سرور برای حملات بعدی

یک سرور آلوده ممکن است برای ارتباط با سامانه‌های دیگر، اجرای فرایندهای مخرب یا تلاش برای دسترسی به منابع داخلی مورد سوءاستفاده قرار گیرد.

اختلال در سرویس‌دهی

حملات مرتبط با مدیریت حافظه ممکن است باعث توقف پردازش‌ها، افزایش خطاهای HTTP یا کاهش دسترس‌پذیری سرویس شوند.

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

چگونه نسخه PHP سرور را بررسی کنیم؟

اولین اقدام عملی برای مدیران سیستم، شناسایی نسخه‌های PHP نصب‌شده و سرویس‌هایی است که از آن‌ها استفاده می‌کنند.

بررسی نسخه PHP در لینوکس

در ترمینال سرور دستور زیر را اجرا کنید:

php -v

این دستور نسخه PHP مربوط به محیط خط فرمان را نشان می‌دهد.

اما توجه داشته باشید که نسخه PHP در CLI ممکن است با نسخه‌ای که وب‌سرور استفاده می‌کند متفاوت باشد.

بررسی سرویس‌های PHP-FPM

در سرورهای مبتنی بر systemd می‌توان سرویس‌های مرتبط را مشاهده کرد:

systemctl list-units --all 'php*-fpm.service'

در توزیع‌هایی که نام‌گذاری متفاوتی دارند، باید سرویس‌های مرتبط با PHP-FPM را بر اساس ساختار همان سیستم‌عامل بررسی کنید.

بررسی بسته‌های PHP در Ubuntu و Debian

dpkg -l 'php*'

برای مشاهده سیاست نسخه بسته‌ها:

apt-cache policy php8.3-fpm

در این مثال، نسخه ۸.۳ فقط نمونه است؛ باید نسخه نصب‌شده روی سرور خود را جایگزین کنید.

بررسی بسته‌ها در RHEL و توزیع‌های مشابه

rpm -qa | grep -i php

همچنین می‌توان اطلاعیه‌های امنیتی موجود را از طریق ابزار مدیریت بسته همان توزیع بررسی کرد.

بررسی نسخه PHP در وردپرس

در پیشخوان وردپرس به مسیر زیر مراجعه کنید:

ابزارها ← سلامت سایت ← اطلاعات ← سرور

در این قسمت معمولاً نسخه PHP مورد استفاده سایت نمایش داده می‌شود.

از ایجاد فایل عمومی phpinfo() روی سرور عملیاتی خودداری کنید؛ زیرا این فایل ممکن است اطلاعات حساس پیکربندی را افشا کند.

راهکار اصلی رفع آسیب پذیری PHP چیست؟

مهم‌ترین و مطمئن‌ترین اقدام، نصب نسخه اصلاح‌شده PHP است.

تیم امنیت PHP اعلام کرده است که برای این دو آسیب‌پذیری، راهکار جایگزین کاملی وجود ندارد که بتوان آن را معادل نصب وصله دانست.

بنابراین، استفاده از WAF، محدودسازی دسترسی یا تغییر تنظیمات صرفاً باید به‌عنوان کنترل مکمل یا موقت در نظر گرفته شود.

مرحله اول: شناسایی دارایی‌های آسیب‌پذیر

تمام سامانه‌هایی را که PHP اجرا می‌کنند شناسایی کنید.

این فهرست باید شامل موارد زیر باشد:

• وب‌سایت‌های عمومی
• پنل‌های مدیریت
• نرم‌افزارهای داخلی
• APIهای مبتنی بر PHP
• سرویس‌های کانتینری
• ماشین‌های مجازی
• محصولات دارای PHP تعبیه‌شده

در محیط‌های Docker و Kubernetes، صرف بررسی PHP نصب‌شده روی میزبان کافی نیست؛ نسخه موجود در ایمیج و کانتینر در حال اجرا نیز باید بررسی شود.

مرحله دوم: تهیه نسخه پشتیبان

پیش از اعمال تغییرات، از فایل‌های برنامه، پایگاه داده و تنظیمات سرویس نسخه پشتیبان تهیه کنید.

بهتر است قابلیت بازیابی نسخه پشتیبان نیز تأیید شده باشد.

مرحله سوم: دریافت وصله از منبع معتبر

وصله‌ها را از مخزن رسمی سیستم‌عامل، تأمین‌کننده پشتیبانی‌شده یا کانال معتبر انتشار PHP دریافت کنید.

در Ubuntu و Debian می‌توان ابتدا فهرست بسته‌ها را به‌روزرسانی کرد:

sudo apt update

سپس وضعیت نسخه اصلاح‌شده بسته PHP را بررسی کرد و بسته مربوطه را از مخزن معتبر نصب کرد.

برای نمونه:

sudo apt install --only-upgrade php8.3-fpm

این دستور فقط نمونه‌ای برای سروری است که PHP-FPM ۸.۳ دارد؛ اجرای آن به معنی تضمین نصب وصله نیست. پیش از اجرا باید مطمئن شوید مخزن فعال واقعاً نسخه اصلاح‌شده یا بسته دارای Backport امنیتی را ارائه می‌کند.

در RHEL و توزیع‌های مشابه نیز باید از ابزار مدیریت بسته و اطلاعیه امنیتی تأمین‌کننده استفاده شود.

مرحله چهارم: راه‌اندازی مجدد سرویس مرتبط

پس از نصب بسته اصلاح‌شده، سرویس‌های PHP باید طبق دستورالعمل بسته و برنامه تغییرات سازمان راه‌اندازی مجدد شوند تا پردازش‌های قدیمی جای خود را به نسخه جدید بدهند.

برای نمونه، در سرور دارای PHP-FPM ۸.۳:

sudo systemctl restart php8.3-fpm

این دستور را فقط زمانی اجرا کنید که نام سرویس و وضعیت به‌روزرسانی را تأیید کرده‌اید.

مرحله پنجم: تأیید اصلاح و تست سرویس

پس از به‌روزرسانی:

• نسخه و وضعیت بسته اصلاح‌شده را بررسی کنید.
• مطمئن شوید پردازش‌های قدیمی PHP باقی نمانده‌اند.
• عملکرد وب‌سایت و APIها را آزمایش کنید.
• لاگ‌های خطا را بررسی کنید.
• وضعیت امنیتی سامانه را در سامانه مدیریت آسیب‌پذیری ثبت کنید.

در محیط‌های حساس، بهتر است این مراحل با برنامه تغییرات، آزمون سازگاری و روش بازگشت کنترل‌شده انجام شوند.

اگر امکان به‌روزرسانی فوری PHP وجود نداشته باشد چه کنیم؟

در بعضی سازمان‌ها، وابستگی نرم‌افزارهای قدیمی به نسخه مشخصی از PHP باعث می‌شود ارتقای فوری با محدودیت مواجه شود.

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

اقدامات موقت قابل بررسی عبارت‌اند از:

1. محدود کردن دسترسی عمومی به سرویس آسیب‌پذیر
2. انتقال سامانه به شبکه ایزوله در صورت امکان
3. اعمال محدودیت دسترسی در فایروال و Reverse Proxy
4. فعال‌سازی قواعد دفاعی معتبر در WAF
5. محدود کردن سطح دسترسی پردازش‌های PHP
6. افزایش نظارت بر لاگ‌ها و رفتارهای غیرعادی
7. هماهنگی فوری با تأمین‌کننده نرم‌افزار برای دریافت نسخه اصلاح‌شده

هیچ‌کدام از این اقدامات جایگزین کامل نصب وصله نیستند.

اگر سامانه‌ای در معرض اینترنت قرار دارد و امکان اصلاح آن وجود ندارد، ایزوله کردن یا خارج کردن موقت آن از دسترس عمومی باید به‌عنوان یک گزینه جدی در مدیریت ریسک بررسی شود.

آیا حملات واقعی با استفاده از PHP2Shell آغاز شده‌اند؟

پس از انتشار جزئیات PHP2Shell، گزارش‌هایی درباره تلاش برای بهره‌برداری از این آسیب‌پذیری‌ها منتشر شده است.

با این حال، باید بین سه مفهوم تفاوت قائل شد:

اسکن آسیب‌پذیری: مهاجم یا ابزار خودکار تلاش می‌کند سرورهای بالقوه آسیب‌پذیر را شناسایی کند.

تلاش برای بهره‌برداری: درخواست‌هایی با هدف فعال کردن آسیب‌پذیری ارسال می‌شوند.

نفوذ موفق: شواهد نشان می‌دهد مهاجم واقعاً به اجرای کد یا دسترسی غیرمجاز دست یافته است.

مشاهده درخواست مشکوک در لاگ، به‌تنهایی اثبات نفوذ موفق نیست. در مقابل، نصب وصله نیز به‌تنهایی ثابت نمی‌کند که سرور پیش از به‌روزرسانی مورد سوءاستفاده قرار نگرفته است.

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

تیم SOC چگونه حملات مرتبط با آسیب پذیری PHP را شناسایی کند؟

برای مراکز عملیات امنیت، PHP2Shell باید به‌عنوان یک سناریوی مهم پایش و پاسخ به رخداد در نظر گرفته شود.

تیم SOC می‌تواند بر شاخص‌های رفتاری زیر تمرکز کند:

اجرای فرایندهای غیرمعمول توسط وب‌سرور

اگر پردازش PHP یا وب‌سرور به‌صورت غیرمنتظره فرایندهای سیستمی اجرا کند، موضوع نیازمند بررسی است.

البته بعضی برنامه‌های قانونی نیز ممکن است چنین رفتاری داشته باشند؛ بنابراین تحلیل باید بر اساس خط مبنای رفتاری هر سرور انجام شود.

تغییر فایل‌های حساس

ایجاد یا تغییر غیرمنتظره فایل‌های PHP، فایل‌های پیکربندی و مسیرهای اجرایی می‌تواند نشانه فعالیت مشکوک باشد.

ارتباطات خروجی غیرعادی

ارتباطات شبکه‌ای که با عملکرد معمول وب‌سایت همخوانی ندارند، به‌ویژه از پردازش‌های سرویس وب، باید بررسی شوند.

خطاهای غیرعادی حافظه و توقف پردازش‌ها

افزایش ناگهانی خطاهای PHP، توقف Workerها، خطاهای Fatal و رخدادهای غیرمعمول مدیریت حافظه می‌توانند در کنار سایر شواهد به تشخیص فعالیت مشکوک کمک کنند.

این موارد به‌تنهایی شاخص قطعی بهره‌برداری از PHP2Shell نیستند.

بررسی احتمال افشای اطلاعات

اگر شواهد نفوذ وجود داشته باشد، باید احتمال دسترسی به اطلاعات اتصال پایگاه داده، توکن‌ها، کلیدهای API و سایر اطلاعات حساس بررسی شود.

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

هشدار تکمیلی: آسیب‌پذیری جدید CVE-۲۰۲۶-۱۱۵۵۶۰

در ۲۳ اکتبر ۲۰۲۶، هشدار دیگری درباره آسیب‌پذیری اجرای کد در PHP با شناسه CVE-۲۰۲۶-۱۱۵۵۶۰ منتشر شد.

این مشکل با دو آسیب‌پذیری اصلی PHP2Shell متفاوت است و بهره‌برداری از آن به ترکیب غیرمعمولی از تنظیمات PHP و رفتار برنامه وابسته است.

نکته مهم این است که وصله‌های منتشرشده در ۲۱ اکتبر برای PHP2Shell، این آسیب‌پذیری جدید را برطرف نمی‌کنند.

طبق هشدار امنیتی منتشرشده، یکی از اقدامات موقت پیشنهادی تا زمان ارائه اصلاح مناسب، غیرفعال کردن قابلیت Session Upload Progress است:

session.upload_progress.enabled=0

این تغییر باید پس از بررسی وابستگی‌های برنامه و در قالب فرایند مدیریت تغییر انجام شود.

تیم‌های فنی باید اطلاعیه‌های بعدی PHP را نیز دنبال کنند؛ زیرا وضعیت اصلاح این آسیب‌پذیری ممکن است تغییر کند.

نقش امنیت زیرساخت و مدیریت آسیب‌پذیری در جلوگیری از نفوذ

حادثه PHP2Shell بار دیگر نشان می‌دهد که امنیت یک وب‌سایت صرفاً با نصب افزونه امنیتی یا فعال‌سازی فایروال تأمین نمی‌شود.

یک نقص در Runtime می‌تواند مستقل از منطق برنامه، بخش مهمی از زیرساخت را در معرض خطر قرار دهد.

برای کاهش چنین ریسک‌هایی، سازمان‌ها به یک چرخه مستمر مدیریت آسیب‌پذیری نیاز دارند:

• شناسایی و ثبت دارایی‌های فناوری اطلاعات
• پایش اطلاعیه‌های امنیتی
• اولویت‌بندی آسیب‌پذیری‌ها بر اساس شدت و میزان مواجهه
• نصب وصله‌های امنیتی
• ارزیابی اثر تغییرات بر سرویس‌ها
• پایش رفتارهای مشکوک
• بررسی شواهد نفوذ
• مستندسازی و گزارش‌دهی مدیریتی

همچنین استفاده از راهکارهای SIEM، پایش لاگ، کنترل دسترسی، سخت‌سازی سرورها و تفکیک شبکه می‌تواند به کاهش سطح حمله و تشخیص سریع‌تر تهدیدات کمک کند.

پردازش ابری نیماد و امنیت زیرساخت‌های سازمانی

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

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

برای آشنایی بیشتر با خدمات تخصصی امنیت و زیرساخت می‌توانید به وب‌سایت پردازش ابری نیماد مراجعه کنید.

پرسش‌های متداول درباره آسیب پذیری PHP

آسیب پذیری PHP2Shell چیست؟

PHP2Shell نام دو آسیب‌پذیری بحرانی در هسته PHP با شناسه‌های CVE-۲۰۲۶-۱۰۹۶۱۸ و CVE-۲۰۲۶-۱۰۹۶۱۹ است که می‌توانند در شرایط مشخص امکان اجرای کد از راه دور بدون احراز هویت را فراهم کنند.

آیا آسیب پذیری PHP روی وردپرس تأثیر دارد؟

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

کدام نسخه PHP امن است؟

برای دو آسیب‌پذیری اصلی PHP2Shell، نسخه‌های اصلاح‌شده عبارت‌اند از PHP ۸.۲.۳۵، PHP ۸.۳.۳۶، PHP ۸.۴.۲۷ و PHP ۸.۵.۱۲. این موضوع به معنی مصونیت این نسخه‌ها در برابر تمام آسیب‌پذیری‌های دیگر نیست.

آیا آسیب پذیری PHP بدون رمز عبور قابل بهره‌برداری است؟

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

آیا WAF می‌تواند آسیب پذیری PHP2Shell را برطرف کند؟

خیر. WAF ممکن است بخشی از درخواست‌های مخرب را شناسایی یا مسدود کند، اما نقص موجود در هسته PHP را اصلاح نمی‌کند. نصب وصله امنیتی ضروری است.

چگونه متوجه شویم سرور PHP ما آسیب‌پذیر است؟

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

آیا بعد از به‌روزرسانی PHP نیاز به بررسی امنیتی داریم؟

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

جمع‌بندی: آسیب پذیری PHP را فوراً بررسی و اصلاح کنید

آسیب پذیری PHP2Shell با دو شناسه CVE-۲۰۲۶-۱۰۹۶۱۸ و CVE-۲۰۲۶-۱۰۹۶۱۹ یکی از هشدارهای مهم امنیت وب در اکتبر ۲۰۲۶ است.

امکان اجرای کد از راه دور بدون احراز هویت، قرار داشتن نقص در هسته PHP و گستردگی استفاده از این فناوری باعث شده است که مدیران سیستم و تیم‌های امنیتی نیازمند اقدام فوری باشند.

اولویت اصلی سازمان‌ها باید شناسایی سرورهای آسیب‌پذیر، نصب نسخه اصلاح‌شده PHP، تأیید اعمال وصله و بررسی نشانه‌های احتمالی نفوذ باشد.

امنیت پایدار تنها با واکنش به یک آسیب‌پذیری به دست نمی‌آید؛ بلکه نتیجه مدیریت مستمر وصله‌ها، پایش امنیتی و طراحی اصولی زیرساخت است.

منابع فنی و امنیتی

1. PHP.net – اطلاعیه امنیتی رسمی و نسخه‌های اصلاح‌شده
2. CERT-EU – Critical Vulnerabilities in PHP
3. Canadian Centre for Cyber Security – PHP Critical Vulnerabilities
4. PHP ۸ ChangeLog – جزئیات اصلاحات امنیتی