آسیب‌پذیری بحرانی PHP (PHP2Shell)؛ نسخه‌های آسیب‌پذیر و روش رفع
· mytag_6166
دو آسیب‌پذیری بسیار خطرناک در هسته PHP شناسایی شده‌اند که امنیت میلیون‌ها وب‌سایت و اپلیکیشن تحت وب را تحت تأثیر قرار می‌دهند. این آسیب‌پذیری‌ها با شناسه‌های CVE-2026-109618 و CVE-2026-109619 شناخته می‌شوند و محققان امنیتی از آن‌ها با نام PHP2Shell یاد می‌کنند.
هر دو آسیب‌پذیری امتیاز 9.2 از 10 در استاندارد CVSS 4.0 دریافت کرده‌اند. مهاجمان ممکن است با سوءاستفاده از این مشکلات، بدون داشتن حساب کاربری یا احراز هویت، کد دلخواه خود را روی سرورهای آسیب‌پذیر اجرا کنند.
تیم توسعه PHP در تاریخ ۲۱ اکتبر ۲۰۲۶ اصلاحیه‌های امنیتی را منتشر کرد و از مدیران سرور و توسعه‌دهندگان خواست نسخه PHP خود را در سریع‌ترین زمان ممکن به‌روزرسانی کنند.
در این مقاله بررسی می‌کنیم آسیب‌پذیری PHP2Shell چیست، کدام نسخه‌های PHP در معرض خطر قرار دارند، این مشکلات چه تأثیری روی وردپرس و سایر اپلیکیشن‌های PHP دارند و چگونه می‌توان امنیت سرور را افزایش داد.
آسیب‌پذیری PHP2Shell چیست؟
PHP2Shell نامی است که برای دو آسیب‌پذیری بحرانی در هسته مفسر PHP استفاده می‌شود. برخلاف مشکلات امنیتی رایجی که به یک افزونه، قالب یا فریم‌ورک خاص مربوط می‌شوند، این مشکلات در خود PHP Runtime قرار دارند.
در نتیجه، آسیب‌پذیری می‌تواند وب‌سایت‌ها و اپلیکیشن‌هایی را تحت تأثیر قرار دهد که از نسخه‌های آسیب‌پذیر PHP برای پردازش درخواست‌های کاربران استفاده می‌کنند.
خطر اصلی PHP2Shell امکان Remote Code Execution یا RCE است. در چنین شرایطی، مهاجم ممکن است بتواند دستورات دلخواه را با سطح دسترسی فرایند PHP روی سرور اجرا کند.
زمان کشف و انتشار اصلاحیه‌های امنیتی PHP
تیم امنیت PHP در ۲۰ اکتبر ۲۰۲۶ اطلاعیه‌ای درباره دو آسیب‌پذیری بحرانی منتشر کرد. در آن زمان، جزئیات فنی و نسخه‌های دقیق آسیب‌پذیر هنوز به‌صورت کامل اعلام نشده بودند.
یک روز بعد، در ۲۱ اکتبر، اصلاحیه‌های امنیتی منتشر شدند و تیم PHP اطلاعات بیشتری درباره ماهیت مشکلات و نسخه‌های اصلاح‌شده ارائه کرد.
در ۲۳ اکتبر نیز یک مشکل امنیتی دیگر با شناسه CVE-2026-115560 اعلام شد که به یک ترکیب پیکربندی غیرمعمول مربوط است.
| تاریخ | رویداد |
|---|---|
| ۲۰ اکتبر ۲۰۲۶ | اطلاعیه اولیه دو آسیب‌پذیری بحرانی PHP |
| ۲۱ اکتبر ۲۰۲۶ | انتشار اصلاحیه‌های امنیتی و معرفی نسخه‌های امن |
| ۲۳ اکتبر ۲۰۲۶ | اعلام آسیب‌پذیری سوم با شرایط بهره‌برداری محدودتر |
جزئیات آسیب‌پذیری‌های جدید PHP
دو مشکل اصلی PHP2Shell به مدیریت حافظه و وضعیت داخلی درخواست‌ها در PHP مربوط می‌شوند. این مشکلات در شرایط خاص می‌توانند به Memory Corruption و در نهایت اجرای کد دلخواه منجر شوند.
CVE-2026-109618؛ آسیب‌پذیری مدیریت حافظه PHP
آسیب‌پذیری CVE-2026-109618 در مدیریت شرایط Out of Memory یا OOM رخ می‌دهد.
PHP برای جلوگیری از مصرف بیش‌ازحد حافظه از محدودیت‌هایی مانند memory_limit استفاده می‌کند. در شرایط خاص، توقف پردازش درخواست هنگام خطای کمبود حافظه می‌تواند بعضی ساختارهای داخلی PHP را در وضعیت ناقص قرار دهد.
در نتیجه، فرایند پاک‌سازی اطلاعات درخواست ممکن است با داده‌های حافظه‌ای کار کند که مقداردهی اولیه صحیحی ندارند.
این مشکل می‌تواند زمینه Memory Corruption و اجرای کد از راه دور را در یک محیط آسیب‌پذیر فراهم کند.
CVE-2026-109619؛ مشکل باقی ماندن وضعیت داخلی درخواست
آسیب‌پذیری CVE-2026-109619 نیز با مدیریت حافظه ارتباط دارد، اما علت آن متفاوت است.
در این حالت، بعضی اطلاعات داخلی مربوط به یک درخواست ممکن است پس از آزاد شدن حافظه همچنان در وضعیت سراسری PHP باقی بمانند.
اگر یک درخواست بعدی از همان Worker استفاده کند، ممکن است پیش از بازنشانی کامل وضعیت داخلی، به حافظه آزادشده اشاره کند.
این رفتار از نظر امنیتی خطرناک است و می‌تواند امکان سوءاستفاده از حافظه و اجرای کد را فراهم کند.
مقایسه دو آسیب‌پذیری بحرانی PHP
| مشخصات | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| نام شناخته‌شده | PHP2Shell | PHP2Shell |
| شدت | Critical | Critical |
| امتیاز CVSS 4.0 | 9.2 | 9.2 |
| عامل اصلی | خطا در مدیریت وضعیت Out of Memory | باقی ماندن State مربوط به حافظه آزادشده |
| خطر امنیتی | Remote Code Execution | Remote Code Execution |
| احراز هویت | در مسیرهای آسیب‌پذیر الزامی نیست | در مسیرهای آسیب‌پذیر الزامی نیست |
کدام نسخه‌های PHP آسیب‌پذیر هستند؟
تیم توسعه PHP اصلاحیه‌های مربوط به این دو آسیب‌پذیری را در شاخه‌های 8.2، 8.3، 8.4 و 8.5 منتشر کرده است.
اگر از نسخه‌های پایین‌تر از نسخه‌های اصلاح‌شده در هر شاخه استفاده می‌کنید، باید وضعیت امنیتی آن را بررسی و در صورت نیاز به‌روزرسانی کنید.
| شاخه PHP | نسخه‌های قبل از اصلاحیه | حداقل نسخه امن در شاخه |
|---|---|---|
| PHP 8.2 | تا 8.2.34 | 8.2.35 |
| PHP 8.3 | تا 8.3.35 | 8.3.36 |
| PHP 8.4 | تا 8.4.26 | 8.4.27 |
| PHP 8.5 | تا 8.5.11 | 8.5.12 |
| PHP 8.1 و قدیمی‌تر | خارج از پشتیبانی رسمی PHP | ارتقا یا استفاده از وصله امنیتی معتبر Vendor |
نسخه‌های قدیمی‌تر PHP نیز ممکن است در معرض خطر باشند. بعضی توزیع‌های لینوکس و ارائه‌دهندگان پشتیبانی بلندمدت، اصلاحیه‌های امنیتی را روی نسخه‌های قدیمی Backport می‌کنند. به همین دلیل شماره نسخه به‌تنهایی همیشه نشان‌دهنده وضعیت نهایی امنیت نیست.
توصیه می‌شود در صورت امکان از شاخه‌های پشتیبانی‌شده PHP استفاده کنید و اصلاحیه‌های رسمی یا نسخه‌های تأییدشده ارائه‌دهنده سیستم‌عامل را نصب کنید.
آسیب‌پذیری PHP چه خطراتی برای سرور دارد؟
اجرای موفق یک حمله RCE می‌تواند باعث شود مهاجم با سطح دسترسی فرایند PHP اقداماتی خارج از رفتار عادی اپلیکیشن انجام دهد.
بسته به تنظیمات سرور، مجوزهای فایل‌ها و سطح دسترسی اپلیکیشن، پیامدهای احتمالی می‌توانند شامل دسترسی به داده‌های حساس، خواندن فایل‌های پیکربندی، تغییر محتوای سایت، سرقت اطلاعات اتصال دیتابیس یا نصب کد مخرب باشند.
البته وجود نسخه آسیب‌پذیر به معنی هک شدن قطعی سرور نیست. شدت پیامدها به مسیر بهره‌برداری، پیکربندی سرویس و سطح دسترسی فرایند PHP وابسته است.
آیا وردپرس هم به آسیب‌پذیری PHP2Shell مبتلا می‌شود؟
بله، وب‌سایت‌های وردپرسی که روی PHP آسیب‌پذیر اجرا می‌شوند ممکن است در معرض خطر قرار بگیرند.
این مشکل در هسته PHP قرار دارد و لزوماً به وجود یک افزونه آلوده یا آسیب‌پذیر وابسته نیست.
تیم امنیت وردپرس نیز در اطلاعیه رسمی خود به مدیران سایت توصیه کرده است نسخه PHP سرور را در سریع‌ترین زمان ممکن به‌روزرسانی کنند.
نکته مهم این است که آپدیت هسته وردپرس، قالب یا افزونه‌ها به‌تنهایی مشکل PHP2Shell را برطرف نمی‌کند. باید Runtime مربوط به PHP را اصلاح کنید.
آیا Laravel، Symfony و سایر فریم‌ورک‌های PHP در خطر هستند؟
اپلیکیشن‌هایی که با Laravel، Symfony یا سایر فریم‌ورک‌های مبتنی بر PHP ساخته شده‌اند نیز ممکن است تحت تأثیر قرار بگیرند.
به‌روزرسانی Dependencyهای برنامه کار مفیدی است، اما رفع این دو آسیب‌پذیری اصلی به اصلاح نسخه PHP محیط اجرا نیاز دارد.
بنابراین مدیران زیرساخت باید نسخه PHP واقعی استفاده‌شده توسط Web Server، PHP-FPM، Containerها و سرویس‌های پس‌زمینه را بررسی کنند.
چگونه نسخه PHP سایت را بررسی کنیم؟
قبل از هر اقدامی باید مشخص کنید سرور از کدام نسخه PHP استفاده می‌کند.
بررسی نسخه PHP از طریق Terminal
اگر دسترسی SSH دارید، دستور زیر نسخه PHP مربوط به محیط Command Line را نمایش می‌دهد:
php -vبرای بررسی نسخه و تنظیمات بیشتر می‌توانید از دستور زیر استفاده کنید:
php -iتوجه داشته باشید نسخه PHP در محیط CLI ممکن است با نسخه PHP واقعی وب‌سایت متفاوت باشد. در سرورهای دارای چند نسخه PHP یا سرویس PHP-FPM باید Runtime مربوط به همان وب‌سایت را جداگانه بررسی کنید.
بررسی نسخه PHP در وردپرس
اگر از وردپرس استفاده می‌کنید، وارد پنل مدیریت شوید و مسیر زیر را باز کنید:
ابزارها (Tools) ← سلامت سایت (Site Health) ← اطلاعات (Info) ← سرور (Server)
در این قسمت نسخه PHP مورد استفاده وردپرس نمایش داده می‌شود.
بررسی نسخه PHP در هاست
در کنترل‌پنل‌هایی مانند cPanel یا DirectAdmin می‌توانید از بخش مدیریت نسخه PHP استفاده کنید.
در هاست اشتراکی، نصب اصلاحیه ممکن است توسط شرکت ارائه‌دهنده انجام شود؛ بنابراین در صورت نبود نسخه امن، باید از پشتیبانی هاست درباره زمان و وضعیت نصب وصله امنیتی سؤال کنید.
چگونه آسیب‌پذیری PHP2Shell را برطرف کنیم؟
مهم‌ترین اقدام برای برطرف کردن این آسیب‌پذیری‌ها، نصب نسخه اصلاح‌شده PHP است.
اگر از PHP 8.4 استفاده می‌کنید، باید حداقل به PHP 8.4.27 ارتقا دهید. همین موضوع درباره نسخه‌های 8.2، 8.3 و 8.5 نیز صدق می‌کند.
بهتر است قبل از تغییر نسخه PHP، از فایل‌ها و دیتابیس Backup تهیه کنید و سازگاری قالب، افزونه‌ها و Dependencyهای پروژه را بررسی کنید.
به‌روزرسانی PHP در سرور لینوکس
روش به‌روزرسانی به توزیع لینوکس و Repositoryهای فعال آن بستگی دارد.
در سیستم‌های مبتنی بر Debian یا Ubuntu، ابتدا اطلاعات پکیج‌ها را به‌روزرسانی کنید:
sudo apt updateسپس پکیج‌های امنیتی PHP را از Repository معتبر و مناسب همان توزیع نصب کنید.
پس از نصب اصلاحیه، سرویس‌های مربوط به PHP-FPM یا وب‌سرور را طبق ساختار زیرساخت Reload یا Restart کنید تا Workerهای قدیمی با نسخه اصلاح‌شده جایگزین شوند.
در پایان دوباره نسخه PHP وب‌سایت و وضعیت سلامت اپلیکیشن را بررسی کنید.
به‌روزرسانی PHP در Docker
اگر پروژه را داخل Docker اجرا می‌کنید، باید Image پایه PHP را نیز بررسی کنید.
برای نمونه، یک Dockerfile می‌تواند از نسخه اصلاح‌شده مشخص استفاده کند:
FROM php:8.4.27-fpmپس از بررسی در دسترس بودن Image معتبر، آن را دوباره دریافت کنید، پروژه را Build کنید و Containerهای قدیمی را با نسخه جدید جایگزین کنید.
همچنین اگر از Image اختصاصی یا توزیع دارای Backport استفاده می‌کنید، وجود Patch امنیتی را از طریق Advisory همان Vendor بررسی کنید.
اگر نتوانیم PHP را فوراً آپدیت کنیم چه کنیم؟
تیم امنیت PHP چند راهکار موقت برای کاهش سطح حمله پیشنهاد کرده است. بااین‌حال هیچ‌کدام از این اقدامات جایگزین کامل نصب اصلاحیه نیستند.
یکی از اقدامات موقت برای کاهش مسیرهای حمله مرتبط با Session، غیرفعال کردن قابلیت Session Upload Progress است.
session.upload_progress.enabled=0این تنظیم باید در سطح مناسب سرور مانند php.ini یا پیکربندی PHP-FPM اعمال شود و Workerهای مربوط نیز Restart شوند.
همچنین مدیران زیرساخت می‌توانند محدودیت‌های دریافت Request، مدیریت آپلود فایل‌ها و قوانین WAF را بررسی کنند.
اطلاعیه رسمی PHP راهکارهای دیگری برای مدیریت شرایط Out of Memory معرفی کرده است؛ اما اعمال آن‌ها بدون بررسی اثرشان بر مصرف حافظه و پایداری سرویس توصیه نمی‌شود.
نکته امنیتی: حتی پس از اجرای راهکارهای موقت، سرور ممکن است از مسیرهای دیگری در معرض خطر باشد. نصب نسخه اصلاح‌شده همچنان اقدام اصلی است.
آسیب‌پذیری سوم PHP با شناسه CVE-2026-115560 چیست؟
در تاریخ ۲۳ اکتبر ۲۰۲۶، تیم PHP درباره یک مسیر احتمالی دیگر برای اجرای کد از راه دور اطلاع‌رسانی کرد.
این مشکل با شناسه CVE-2026-115560 شناخته می‌شود، اما برخلاف دو آسیب‌پذیری اصلی PHP2Shell، به ترکیب غیرمعمولی از تنظیمات Session و رفتار اپلیکیشن نیاز دارد.
این حالت زمانی ممکن است رخ دهد که اپلیکیشن از برخی مقدارهای session.serialize_handler استفاده کند و سپس هنگام اجرای برنامه، Handler را تغییر دهد؛ درحالی‌که Session Upload Progress همچنان فعال باشد.
تیم PHP اعلام کرده است که برای این مشکل اصلاحیه اضطراری جداگانه منتشر نمی‌کند و جزئیات کامل آن را در چرخه انتشار عادی بعدی ارائه خواهد کرد.
تا آن زمان، برای محیط‌هایی که در معرض این مسیر قرار دارند، غیرفعال‌سازی Session Upload Progress یکی از اقدامات پیشنهادی است.
آیا فعال بودن WAF برای محافظت از PHP کافی است؟
Web Application Firewall یا WAF می‌تواند بخشی از درخواست‌های مخرب را شناسایی و مسدود کند.
شرکت‌هایی مانند Cloudflare نیز برای مقابله با مسیرهای شناخته‌شده سوءاستفاده از PHP2Shell محافظت‌هایی ارائه کرده‌اند.
بااین‌حال WAF تضمین نمی‌کند تمام روش‌های بهره‌برداری مسدود شوند و نباید آن را جایگزین نصب Patch امنیتی دانست.
اگر احتمال می‌دهیم سرور قبلاً هک شده است چه کنیم؟
اگر سرور آسیب‌پذیر در دسترس اینترنت بوده و نشانه‌هایی از فعالیت غیرعادی مشاهده می‌کنید، فقط به‌روزرسانی PHP کافی نیست.
در این شرایط باید لاگ‌های وب‌سرور، PHP، فعالیت فرایندها، تغییرات فایل‌ها و دسترسی‌های غیرمعمول را بررسی کنید.
اگر احتمال نفوذ جدی است، بهتر است قبل از پاک‌سازی شواهد لازم را برای بررسی امنیتی حفظ کنید و از تیم پاسخ به رخداد کمک بگیرید.
همچنین بعد از تأیید نفوذ، وضعیت Credentialها، Tokenها، کلیدهای API و دسترسی دیتابیس باید ارزیابی شود.
چک‌لیست امنیتی برای مدیران سایت‌های PHP
| اقدام | اولویت |
|---|---|
| شناسایی نسخه PHP واقعی وب‌سایت و سرور | فوری |
| نصب اصلاحیه PHP2Shell یا Patch معتبر Vendor | فوری |
| بررسی تمام PHP Workerها و Containerها | فوری |
| بررسی لاگ‌ها و نشانه‌های احتمالی سوءاستفاده | بالا |
| بررسی تنظیمات WAF و محدودیت Requestها | بالا |
| تست سازگاری اپلیکیشن پس از ارتقا | بالا |
| تهیه و بررسی Backup معتبر | بالا |
| بررسی نسخه‌های PHP خارج از پشتیبانی | بالا |
سوالات متداول درباره آسیب‌پذیری جدید PHP
PHP2Shell چیست؟
PHP2Shell نام رایج دو آسیب‌پذیری بحرانی در هسته PHP است که می‌توانند در شرایط آسیب‌پذیر به اجرای کد از راه دور بدون احراز هویت منجر شوند.
شناسه‌های CVE آسیب‌پذیری PHP2Shell چیست؟
دو شناسه اصلی PHP2Shell عبارت‌اند از CVE-2026-109618 و CVE-2026-109619. هر دو امتیاز 9.2 در CVSS 4.0 دارند.
کدام نسخه‌های PHP مشکل امنیتی دارند؟
نسخه‌های قبل از PHP 8.2.35، 8.3.36، 8.4.27 و 8.5.12 در شاخه‌های مربوط به خود، فاقد اصلاحیه رسمی این دو آسیب‌پذیری هستند. وضعیت نسخه‌های قدیمی‌تر و بسته‌های Backport شده باید از طریق Vendor بررسی شود.
آیا PHP 8.4 امن است؟
برای مقابله با دو آسیب‌پذیری اصلی PHP2Shell باید از PHP 8.4.27 یا نسخه جدیدتر اصلاح‌شده همان شاخه استفاده کنید.
آیا PHP 8.5 هم آسیب‌پذیر است؟
بله. نسخه‌های تا PHP 8.5.11 در معرض این دو آسیب‌پذیری قرار دارند و اصلاحیه در PHP 8.5.12 منتشر شده است.
آیا وردپرس به‌صورت مستقیم آسیب‌پذیر است؟
آسیب‌پذیری در هسته PHP قرار دارد، نه در کد وردپرس. بااین‌حال وردپرس روی PHP اجرا می‌شود و اگر سرور از نسخه آسیب‌پذیر استفاده کند، سایت ممکن است در معرض خطر قرار بگیرد.
آیا به‌روزرسانی وردپرس مشکل PHP2Shell را حل می‌کند؟
خیر. برای رفع دو آسیب‌پذیری اصلی باید Runtime مربوط به PHP را به‌روزرسانی کنید. نصب نسخه جدید وردپرس به‌تنهایی جایگزین اصلاحیه PHP نیست.
چطور نسخه PHP هاست را بررسی کنیم؟
در وردپرس از بخش Tools و Site Health استفاده کنید. در سرورهایی که دسترسی SSH دارند نیز می‌توانید نسخه CLI را با php -v بررسی کنید، اما نسخه واقعی وب‌سرور ممکن است متفاوت باشد.
آیا استفاده از Cloudflare مشکل PHP2Shell را برطرف می‌کند؟
Cloudflare و سایر WAFها می‌توانند برخی حملات را مسدود کنند، اما آسیب‌پذیری داخل PHP Runtime باقی می‌ماند. برای رفع مشکل باید Patch امنیتی نصب شود.
آسیب‌پذیری CVE-2026-115560 چیست؟
این آسیب‌پذیری سوم در ۲۳ اکتبر ۲۰۲۶ اعلام شد و به ترکیب خاصی از تنظیمات Session و تغییر Handler در زمان اجرای برنامه مربوط است. تیم PHP راهکار موقت آن را اعلام کرده و انتشار Advisory کامل را به نسخه بعدی موکول کرده است.
آیا باید سایت را تا زمان نصب اصلاحیه غیرفعال کنیم؟
برای سرورهای حساس و اینترنتی که امکان نصب فوری اصلاحیه ندارند، محدود کردن دسترسی یا خارج کردن موقت سرویس از دسترس عمومی می‌تواند یکی از اقدامات کاهش خطر باشد. تصمیم نهایی باید براساس ارزیابی ریسک و وضعیت زیرساخت گرفته شود.
جمع‌بندی
آسیب‌پذیری‌های CVE-2026-109618 و CVE-2026-109619 از مهم‌ترین هشدارهای امنیتی PHP در اکتبر ۲۰۲۶ هستند.
این دو مشکل با نام PHP2Shell شناخته می‌شوند و به دلیل احتمال اجرای کد از راه دور بدون احراز هویت، امتیاز بحرانی 9.2 دریافت کرده‌اند.
تیم PHP برای رفع آن‌ها نسخه‌های 8.2.35، 8.3.36، 8.4.27 و 8.5.12 را منتشر کرده است.
اگر مدیر یک سایت وردپرسی، فروشگاه اینترنتی یا اپلیکیشن مبتنی بر PHP هستید، مهم‌ترین اقدام شناسایی نسخه PHP واقعی سرور و نصب اصلاحیه معتبر است.
ابزارهایی مانند WAF و محدودسازی Requestها می‌توانند در کاهش ریسک کمک کنند؛ اما جایگزین به‌روزرسانی امنیتی نیستند.
منابع رسمی و معتبر
اطلاعیه رسمی PHP درباره PHP2Shell و نسخه‌های اصلاح‌شده