آسیب‌پذیری بحرانی PHP2Shell؛ بررسی CVE-2026-109618 و CVE-2026-109619 و روش رفع آن‌ها

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

در ۲۱ اکتبر ۲۰۲۶، تیم توسعه PHP نسخه‌های امنیتی PHP ۸.۵.۱۲، ۸.۴.۲۷، ۸.۳.۳۶ و ۸.۲.۳۵ را برای اصلاح این دو آسیب‌پذیری منتشر کرد. هر دو نقص دارای امتیاز ۹.۲ از ۱۰ در CVSS نسخه ۴.۰ و سطح خطر Critical هستند. هم‌زمان، مراکز امنیتی مانند CERT-EU، Google Cloud، AWS و CERT Coordination Center به مدیران زیرساخت توصیه کردند فوراً نسخه‌های آسیب‌پذیر را شناسایی و اصلاح کنند.

اهمیت ماجرا زمانی بیشتر می‌شود که بدانیم این مشکلات فقط به یک روش اجرای PHP محدود نیستند. محیط‌های PHP-FPM، Apache با mod_php، php-cgi، LiteSpeed و FrankenPHP می‌توانند تحت تأثیر قرار گیرند. تیم امنیتی PHP، پیکربندی mod_php را از نظر بهره‌برداری تأییدشده، پرخطرتر ارزیابی کرده است.

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

تاریخ بررسی و به‌روزرسانی اطلاعات: ۲۳ اکتبر ۲۰۲۶ | سطح: متوسط تا پیشرفته | مناسب برای: مدیران سایت، مدیران هاستینگ، متخصصان امنیت، مدیران VPS و سرور اختصاصی، توسعه‌دهندگان PHP و کارشناسان DevOps.

فهرست مطالب

• خلاصه فوری آسیب‌پذیری‌های PHP2Shell
• PHP2Shell چیست؟
• CVE-۲۰۲۶-۱۰۹۶۱۸ چیست؟
• CVE-۲۰۲۶-۱۰۹۶۱۹ چیست؟
• نسخه‌های آسیب‌پذیر PHP
• سطح خطر و پیامدهای احتمالی
• کدام وب‌سرورها و محیط‌ها در معرض خطرند؟
• تأثیر آسیب‌پذیری بر وردپرس و ووکامرس
• چطور نسخه PHP را بررسی کنیم؟
• وضعیت cPanel و EasyApache ۴
• وضعیت CloudLinux و PHP Selector
• چرا شماره نسخه قدیمی همیشه به معنی آسیب‌پذیر بودن نیست؟
• روش به‌روزرسانی PHP
• اقدامات موقت در صورت نبود وصله
• اطلاعیه تکمیلی PHP در ۲۳ اکتبر
• آیا Cloudflare و WAF جلوی حمله را می‌گیرند؟
• چگونه نشانه‌های حمله را بررسی کنیم؟
• اگر سرور قبلاً آلوده شده باشد چه کنیم؟
• اقدامات کاربران هاست اشتراکی
• چک‌لیست فوری مدیران سرور
• سوالات متداول
• جمع‌بندی

خلاصه فوری؛ برای رفع آسیب‌پذیری PHP چه کنیم؟

اگر سرور یا سایتی دارید که از PHP استفاده می‌کند، اقدامات ضروری عبارت‌اند از:

1. تمام نسخه‌های PHP مورد استفاده در سرور را شناسایی کنید.
2. نسخه‌های آسیب‌پذیر را به انتشار اصلاح‌شده همان شاخه یا نسخه جدیدترِ پشتیبانی‌شده ارتقا دهید.
3. اگر از cPanel، CloudLinux یا بسته‌های توزیع لینوکس استفاده می‌کنید، وضعیت Backport وصله را از تأمین‌کننده بررسی کنید.
4. پس از اعمال وصله، Workerها و سرویس‌های مربوط به PHP را با روش مناسب راه‌اندازی مجدد کنید.
5. از اصلاح شدن نسخه‌ای که واقعاً درخواست‌های وب را پردازش می‌کند مطمئن شوید.
6. تا زمان تکمیل Patch، دسترسی عمومی به سرویس‌های آسیب‌پذیر را محدود و اقدامات دفاعی موقت را بررسی کنید.
7. لاگ‌ها، تغییر فایل‌ها، فرآیندهای غیرمعمول و حساب‌های کاربری را برای یافتن نشانه‌های احتمالی نفوذ بررسی کنید.

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

PHP2Shell چیست؟

PHP2Shell نامی است که برای اشاره به دو آسیب‌پذیری بحرانی اجرای کد از راه دور در PHP استفاده شده است:

• CVE-2026-109618 — فساد حافظه هنگام رسیدگی به خطاهای کمبود حافظه (Out-of-Memory).
• CVE-2026-109619 — استفاده از وضعیت داخلی باقی‌مانده پس از آزاد شدن حافظه (Stale Global State / Use-After-Free).

این نام، شناسه رسمی یک آسیب‌پذیری مستقل نیست. شناسه‌های رسمی همان دو CVE بالا هستند.

در یک حمله Remote Code Execution یا RCE، مهاجم ممکن است بتواند دستوراتی را روی سیستم هدف با سطح دسترسی فرآیند آسیب‌پذیر اجرا کند.

در سرویس‌های وب PHP، سطح دسترسی اجرای کد معمولاً به کاربر و مجوزهای PHP Worker وابسته است. بنابراین RCE لزوماً به معنی دسترسی فوری root نیست؛ بااین‌حال دسترسی به فایل‌های سایت، تنظیمات برنامه، اطلاعات اتصال دیتابیس و سایر منابع مجاز برای فرآیند PHP می‌تواند پیامدهای جدی داشته باشد.

چرا این دو نقص امنیتی با مشکلات معمول PHP متفاوت‌اند؟

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

اما این دو CVE به پردازش داخلی PHP مربوط هستند.

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

آسیب‌پذیری CVE-۲۰۲۶-۱۰۹۶۱۸ چیست؟

آسیب‌پذیری CVE-2026-109618 به مدیریت وضعیت کمبود حافظه در PHP مربوط است.

PHP برای مدیریت مصرف حافظه از سازوکارهایی استفاده می‌کند که هنگام رسیدن به محدودیت حافظه می‌توانند اجرای یک درخواست را متوقف کنند.

در شرایط خاص، خطای Out-of-Memory ممکن است زمانی رخ دهد که ساختارهای داخلی مرتبط با درخواست هنوز به‌طور کامل مقداردهی اولیه نشده‌اند.

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

اگر این فرض درست نباشد، امکان بروز Memory Corruption وجود دارد.

OOM چیست؟

OOM مخفف Out of Memory است و به شرایطی اشاره می‌کند که یک برنامه قادر به تأمین حافظه موردنیاز خود نیست یا از محدودیت تعیین‌شده عبور کرده است.

در PHP، تنظیم memory_limit یکی از مکانیسم‌های کنترل مصرف حافظه است.

مشکل CVE-۲۰۲۶-۱۰۹۶۱۸ زمانی خطرناک می‌شود که مسیرهای رسیدگی به خطای حافظه با داده داخلی ناقص یا نامعتبر مواجه شوند.

پیامد احتمالی CVE-۲۰۲۶-۱۰۹۶۱۸

پیامدهای احتمالی شامل موارد زیر است:

• خرابی فرآیند PHP
• اختلال یا توقف درخواست‌ها
• فساد حافظه
• اجرای کد از راه دور در شرایط قابل بهره‌برداری

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

آسیب‌پذیری CVE-۲۰۲۶-۱۰۹۶۱۹ چیست؟

CVE-2026-109619 به مدیریت وضعیت داخلی PHP میان درخواست‌ها و استفاده از ارجاع‌های حافظه‌ای نامعتبر مربوط است.

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

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

اگر همان PHP Worker در ادامه از این وضعیت باقی‌مانده استفاده کند، احتمال وقوع Use-After-Free وجود دارد.

Use-After-Free چیست؟

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

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

چرا Workerهای PHP اهمیت دارند؟

در محیط‌هایی مانند PHP-FPM و برخی مدل‌های اجرای Apache، فرآیندهای Worker می‌توانند چندین درخواست را در طول عمر خود پردازش کنند.

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

برای درک معماری Workerها، Poolها و ارتباط PHP با وب‌سرور، مقاله آموزش نصب و پیکربندی PHP-FPM با Nginx در Ubuntu را مطالعه کنید.

مقایسه فنی دو آسیب‌پذیری PHP

کدام نسخه‌های PHP آسیب‌پذیر هستند؟

تیم توسعه PHP در ۲۱ اکتبر ۲۰۲۶ برای چهار شاخه فعال، انتشارهای امنیتی جدید ارائه کرد.

این جدول مربوط به انتشارهای اصلی PHP است. بسته‌های توزیع‌های Linux، cPanel و CloudLinux ممکن است اصلاحیه را با همان شماره نسخه قدیمی و Release Number جدید ارائه کنند.

وضعیت PHP ۷.۴ و PHP ۸.۱ چگونه است؟

این شاخه‌ها دیگر تحت پشتیبانی عادی پروژه اصلی PHP نیستند.

بااین‌حال برخی ارائه‌دهندگان Extended Lifecycle Support و توزیع‌های Linux اصلاحیه‌ها را به شاخه‌های قدیمی Backport می‌کنند.

تیم توسعه PHP نیز به‌صورت استثنایی برای شاخه‌های ۷.۴، ۸.۰ و ۸.۱ وصله‌های حداقلی در سطح کد منبع منتشر کرده است.

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

پایان پشتیبانی PHP ۸.۲

طبق اعلام PHP، شاخه ۸.۲ در ۳۱ دسامبر ۲۰۲۶ به پایان دوره پشتیبانی امنیتی رسمی می‌رسد. بنابراین حتی پس از نصب PHP ۸.۲.۳۵ نیز بهتر است برای مهاجرت به شاخه جدیدتر برنامه‌ریزی کنید.

خطر این آسیب‌پذیری‌ها چقدر جدی است؟

هر دو آسیب‌پذیری امتیاز ۹.۲ در CVSS v4.۰ دارند.

شدت Critical به این معنی است که نقص‌ها از نظر اثر بالقوه امنیتی بسیار مهم‌اند؛ بااین‌حال شرایط بهره‌برداری در همه محیط‌ها لزوماً یکسان نیست.

پیامدهای احتمالی یک بهره‌برداری موفق

• اجرای کد: اجرای عملیات مخرب با مجوزهای PHP Worker.
• افشای اطلاعات: دسترسی به داده‌های قابل مشاهده برای فرآیند آسیب‌پذیر.
• تغییر فایل‌ها: دستکاری فایل‌های قابل نوشتن برای کاربر PHP.
• اختلال سرویس: Crash یا توقف فرآیندهای PHP.
• نفوذ بیشتر: امکان حرکت به سایر اجزای زیرساخت در صورت وجود دسترسی یا آسیب‌پذیری‌های تکمیلی.

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

آیا حمله در دنیای واقعی مشاهده شده است؟

بله. watchTowr اعلام کرده از ۲۱ اکتبر ۲۰۲۶ تلاش‌های بهره‌برداری مرتبط با PHP2Shell را در شبکه Honeypot خود مشاهده کرده است.

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

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

کدام محیط‌های اجرای PHP در معرض خطر هستند؟

طبق اطلاعیه رسمی PHP، محیط‌های زیر باید بررسی شوند:

• PHP-FPM
• Apache با mod_php
• php-cgi
• LiteSpeed و محیط‌های مرتبط با PHP
• FrankenPHP
• محیط‌های کانتینری و سرویس‌های ابری که PHP اجرا می‌کنند

Apache با mod_php

تیم PHP ریسک mod_php را از نظر مسیر بهره‌برداری تأییدشده، بالاتر از سایر پیکربندی‌ها ارزیابی کرده است.

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

Nginx و PHP-FPM

استفاده از Nginx به‌جای Apache مصونیت ایجاد نمی‌کند.

اگر Nginx درخواست را به یک PHP-FPM آسیب‌پذیر ارسال کند، همچنان باید وضعیت آن Runtime بررسی و اصلاح شود.

LiteSpeed

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

صرف استفاده از وب‌سرور متفاوت به معنی رفع آسیب‌پذیری هسته PHP نیست.

سرورهای Docker و Podman

اگر PHP داخل کانتینر اجرا می‌شود، به‌روزرسانی PHP روی Host الزاماً Image کانتینر را اصلاح نمی‌کند.

باید Base Image و Runtime استفاده‌شده در کانتینر نیز بررسی، بازسازی و دوباره Deploy شوند.

برای شناخت معماری کانتینرها می‌توانید مقالات Docker چیست؟ و Podman چیست؟ را مطالعه کنید.

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

بله؛ اگر سایت وردپرسی یا ووکامرسی روی Runtime آسیب‌پذیر PHP اجرا شود، باید احتمال تأثیرپذیری آن بررسی شود.

موضوع مهم این است که این دو CVE مستقیماً مربوط به یک افزونه خاص نیستند.

بنابراین حتی اگر:

• هسته WordPress به‌روز باشد؛
• تمام افزونه‌ها به‌روزرسانی شده باشند؛
• قالب سایت معتبر باشد؛
• رمزهای عبور قوی باشند؛

باز هم ممکن است زیرساخت اجرای PHP نیازمند وصله امنیتی باشد.

آیا به‌روزرسانی وردپرس این دو CVE را رفع می‌کند؟

خیر. رفع این دو نقص نیازمند اصلاح PHP Runtime است.

به‌روزرسانی WordPress و افزونه‌ها همچنان ضروری است، اما جایگزین نصب وصله PHP نمی‌شود.

کاربران هاست وردپرس چه کنند؟

ابتدا نسخه PHP فعال را از پنل هاست بررسی کنند و سپس از ارائه‌دهنده سرویس درباره وضعیت امنیتی آن نسخه و نصب Backport احتمالی سؤال کنند.

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

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

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

نکته: دستور php -v معمولاً نسخه PHP خط فرمان یا CLI را نمایش می‌دهد. در سرورهای MultiPHP، cPanel یا محیط‌های کانتینری ممکن است نسخه PHP وب‌سایت متفاوت باشد.

۱. بررسی PHP CLI

php -v

خروجی نمونه:

PHP 8.3.35 (cli)

در نصب خام Upstream، این نسخه قبل از انتشار اصلاحی ۸.۳.۳۶ قرار دارد؛ اما در بسته‌های دارای Backport باید Release Package نیز بررسی شود.

۲. مشاهده PHP Binaryهای نصب‌شده

command -v php

ls -l /usr/bin/php*

در بعضی توزیع‌ها چند نسخه هم‌زمان نصب هستند.

۳. بررسی فرآیندهای PHP-FPM

ps aux | grep '[p]hp-fpm'

و:

systemctl list-units --type=service --all |
grep -Ei 'php.*fpm'

نام سرویس به توزیع و روش نصب وابسته است.

۴. بررسی نسخه PHP-FPM

اگر Binary مربوط نصب شده باشد:

php-fpm8.3 -v

یا نسخه متناظر محیط خود را بررسی کنید.

۵. بررسی نسخه در محیط وب

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

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

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

وضعیت CVE-۲۰۲۶-۱۰۹۶۱۸ و CVE-۲۰۲۶-۱۰۹۶۱۹ در cPanel و WHM

cPanel در ۲۱ اکتبر ۲۰۲۶ اطلاعیه امنیتی اختصاصی برای این دو CVE منتشر کرده و نسخه‌های اصلاح‌شده EasyApache ۴ را معرفی کرده است.

نسخه‌های اصلاح‌شده EasyApache ۴

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

آموزش بررسی و به‌روزرسانی EasyApache ۴

ابتدا از اطلاعات و تنظیمات مهم سرور Backup بگیرید و وضعیت سرویس‌ها را بررسی کنید.

سپس طبق راهنمای cPanel می‌توان Metadata مخازن را تازه کرد:

yum clean all && yum makecache

و بسته‌های EasyApache و RPM را با سازوکار رسمی cPanel به‌روزرسانی کرد:

/scripts/rpmup

این دستور برای محیط cPanel/WHM است، نه هر سرور لینوکسی.

چطور از نصب شدن وصله روی PHP قدیمی مطمئن شویم؟

cPanel بررسی Changelog بسته RPM را پیشنهاد می‌کند.

برای نمونه:

rpm -q --changelog ea-php81-php-cli |
grep -m1 CVE-2026-109618

اگر اطلاعات اصلاحیه در Changelog مشاهده شد، نشانه مهمی است که Package دارای اصلاح امنیتی اعلام‌شده توسط Vendor است.

برای شاخه‌های دیگر، نام Package را متناسب با نسخه جایگزین کنید.

آیا فقط به‌روزرسانی WHM کافی است؟

نباید صرفاً براساس نسخه رابط WHM نتیجه گرفت همه PHP Runtimeها اصلاح شده‌اند.

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

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

وضعیت CloudLinux و ALT-PHP

در CloudLinux باید میان بسته‌های alt-php و بسته‌های ea-php تفاوت قائل شد.

CloudLinux اعلام کرده برای برخی شاخه‌ها وصله‌های CVE-۲۰۲۶-۱۰۹۶۱۸ و CVE-۲۰۲۶-۱۰۹۶۱۹ به نسخه موجود Backport شده‌اند.

برای مثال ممکن است یک بسته اصلاح‌شده همچنان شماره نسخه‌ای مانند PHP ۸.۳.۳۵ را نمایش دهد، اما Release Package و Changelog آن حاوی وصله امنیتی باشد.

بررسی Changelog در CloudLinux

برای نمونه:

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

یا برای بسته EasyApache ارائه‌شده توسط CloudLinux:

rpm -q --changelog ea-php84-php-cli |
grep -E 'CVE-2026-(109618|109619)'

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

آیا Imunify360 مشکل را حل می‌کند؟

CloudLinux اعلام کرده Ruleset نسخه ۸.۸۳ در Imunify360 با ModSecurity فعال، الگوی مشخصی از درخواست‌های بهره‌برداری عمومی را شناسایی و مسدود می‌کند.

بااین‌حال این روش یک Virtual Patch موقت است و کد آسیب‌پذیر PHP را اصلاح نمی‌کند.

بنابراین حتی با فعال بودن Imunify360 نیز باید اصلاحیه PHP نصب شود.

چرا شماره نسخه PHP به‌تنهایی کافی نیست؟

در بعضی توزیع‌های Linux، توسعه‌دهنده بسته، اصلاحیه امنیتی را به نسخه قدیمی‌تر نرم‌افزار اضافه می‌کند؛ بدون اینکه شماره نسخه اصلی محصول الزاماً تغییر کند.

به این فرآیند Security Backport گفته می‌شود.

برای مثال، دو سرور ممکن است ظاهراً PHP ۸.۳.۳۵ را نمایش دهند، اما یکی از آن‌ها Package اصلی آسیب‌پذیر و دیگری بسته اصلاح‌شده Vendor را اجرا کند.

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

• شماره نسخه PHP
• Release Number بسته
• Changelog رسمی Package
• Security Advisory تأمین‌کننده
• وضعیت Runtime فعال سایت

این موضوع به‌ویژه در CloudLinux، توزیع‌های Enterprise Linux و بسته‌های دارای Extended Support اهمیت دارد.

روش رفع کامل آسیب‌پذیری‌های PHP2Shell

نصب اصلاحیه معتبر مهم‌ترین اقدام برای رفع این دو CVE است.

سرور Ubuntu یا Debian

ابتدا مخازن و بسته‌های موجود را بررسی کنید:

sudo apt update

apt list --upgradable 2>/dev/null |
grep -Ei 'php|fpm'

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

در محیطی که Package مربوط به PHP از مخزن پشتیبانی‌شده نصب شده است، می‌توان به‌روزرسانی آن را با APT انجام داد؛ اما باید دقت کرد که نسخه اصلاح‌شده یا Backport موردنظر واقعاً در Repository موجود باشد.

صرف اجرای apt upgrade تضمین نمی‌کند آسیب‌پذیری رفع شده باشد؛ به‌خصوص اگر مخزن هنوز اصلاحیه را ارائه نکرده باشد.

بررسی نسخه‌های نصب‌شده در Debian/Ubuntu

dpkg -l | grep -E '^ii  php'

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

apt-cache policy php8.3-fpm

در صورت استفاده از نسخه دیگری، نام Package باید تغییر کند.

راه‌اندازی مجدد PHP-FPM

پس از نصب اصلاحیه، Workerهای قدیمی نباید همچنان Runtime آسیب‌پذیر قبلی را اجرا کنند.

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

sudo systemctl restart php8.3-fpm

و سپس:

sudo systemctl status php8.3-fpm

این دستور فقط نمونه است؛ نام سرویس باید با نسخه واقعی و روش نصب شما مطابقت داشته باشد.

سرورهای Docker

اگر PHP در Docker اجرا می‌شود:

1. Base Image حاوی PHP را بررسی کنید.
2. Image اصلاح‌شده را دریافت یا Build کنید.
3. Image تولیدشده را از نظر نسخه و اصلاحیه بررسی کنید.
4. کانتینرهای جدید را از Image اصلاح‌شده Deploy کنید.
5. Replicaها و Workerهای قدیمی را از چرخه اجرا خارج کنید.

برای مشاهده کانتینرها:

docker ps

برای بررسی PHP داخل کانتینر مشخص:

docker exec CONTAINER_NAME php -v

نام کانتینر را با مقدار واقعی جایگزین کنید.

توجه داشته باشید که این دستور PHP CLI داخل کانتینر را بررسی می‌کند و در ساختارهای چندسرویسی باید Runtime وب نیز مشخص شود.

سرورهای مدیریت‌شده

در سرویس‌های مدیریت‌شده باید از ارائه‌دهنده هاست یا پلتفرم ابری درباره زمان و وضعیت اعمال وصله سؤال کنید.

همچنین باید بررسی شود که آیا Deployment یا Container اختصاصی شما نیازمند بازسازی دستی است یا خیر.

اگر فعلاً امکان به‌روزرسانی PHP نداریم چه کنیم؟

تیم PHP چند اقدام موقت برای کاهش خطر مسیرهای شناخته‌شده پیشنهاد کرده است.

هشدار: این موارد راهکار کامل نیستند و ممکن است اثر عملیاتی داشته باشند. روی سرورهای Production باید پس از بررسی نیاز برنامه و با هماهنگی مدیر زیرساخت اجرا شوند.

۱. غیرفعال کردن Session Upload Progress

یکی از تنظیمات مهم:

session.upload_progress.enabled = Off

این تنظیم برخی مسیرهای تأییدشده مربوط به پردازش Session Upload Progress را مسدود می‌کند.

اما برای اثرگذاری باید در Configurationی اعمال شود که قبل از پردازش درخواست فعال است؛ مانند php.ini یا تنظیمات مناسب FPM Pool.

تیم PHP هشدار داده اتکا به ini_set() یا فایل .user.ini در PHP-FPM برای این هدف کافی نیست.

پس از تغییر نیز باید Workerهای مربوط راه‌اندازی مجدد شوند.

۲. محدود کردن حجم درخواست‌ها

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

برای برنامه‌هایی که Upload لازم ندارند، PHP نمونه‌ای از تنظیم زیر را پیشنهاد کرده است:

post_max_size = 8M

و برای برنامه‌های نیازمند Upload، مقدار 32M را به‌عنوان یکی از پیشنهادهای موقت مطرح کرده است.

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

محدودیت باید متناسب با نیاز برنامه و همچنین در سطح وب‌سرور یا Reverse Proxy بررسی شود.

۳. ملاحظات memory_limit

برای CVE-۲۰۲۶-۱۰۹۶۱۸، تیم PHP گزینه موقت memory_limit=-1 را برای حذف یک مسیر مشخص از خطای محدودیت حافظه مطرح کرده است.

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

به همین دلیل نباید آن را کورکورانه روی هاست اشتراکی یا سرور پرترافیک اعمال کرد. چنین تغییری باید فقط به‌عنوان اقدام اضطراری کنترل‌شده، همراه با محدودیت منابع در سطح Container یا cgroup و با درک پیامدهای عملیاتی بررسی شود.

حتی در این حالت نیز امکان رسیدن به سایر مسیرهای شکست تخصیص حافظه باقی می‌ماند.

۴. محدود کردن اثر خرابی فرآیند

جداسازی Workerها، محدودسازی دسترسی کاربران، استفاده از cgroup و تنظیمات مناسب Process Manager می‌توانند در کاهش اثر بعضی خطاها کمک کنند.

این اقدامات از نظر Availability و محدود کردن سطح دسترسی اهمیت دارند، اما اصلاحیه امنیتی را جایگزین نمی‌کنند.

۵. ملاحظات اختصاصی PHP ۸.۵

در PHP ۸.۵، تیم PHP غیرفعال‌سازی موقت fatal_error_backtraces را نیز برای یک مسیر تأییدشده پیشنهاد کرده است:

fatal_error_backtraces = Off

این مورد به‌طور مشخص برای PHP ۸.۵ مطرح شده و باید قبل از استفاده، مستندات و نسخه واقعی Runtime بررسی شود.

اطلاعیه تکمیلی PHP در ۲۳ اکتبر ۲۰۲۶

در ۲۳ اکتبر ۲۰۲۶، تیم PHP اطلاعیه جدیدی درباره Session Upload Progress منتشر کرد.

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

این شرایط شامل استفاده از بعضی Session Serializerها، تغییر Runtime تنظیم session.serialize_handler و فعال بودن Session Upload Progress است.

تیم PHP توصیه کرده تا زمان انتشار اصلاحیه بعدی، برای کاهش این خطر نیز:

session.upload_progress.enabled = Off

حفظ شود.

این اطلاعیه یک موضوع تکمیلی و متمایز از دو CVE اصلی است. تیم PHP اعلام کرده قصد دارد اطلاعات کامل آسیب‌پذیری مرتبط با شناسه CVE-۲۰۲۶-۱۱۵۵۶۰ را همراه انتشار اصلاحیه بعدی ارائه کند.

بنابراین حتی پس از نصب اصلاحیه ۲۱ اکتبر، مدیران سرور باید اطلاعیه‌های تکمیلی PHP را دنبال کنند.

آیا WAF و Cloudflare جلوی PHP2Shell را می‌گیرند؟

WAF یا Web Application Firewall می‌تواند بعضی الگوهای حمله را در سطح HTTP شناسایی و مسدود کند.

برای مثال، CloudLinux اعلام کرده Ruleset ۸.۸۳ در Imunify360 برای مقابله با یک الگوی عمومی بهره‌برداری مرتبط با درخواست‌های Multipart طراحی شده است.

بااین‌حال WAF با PHP Runtime تفاوت دارد.

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

آیا فعال بودن Cloudflare کافی است؟

خیر.

Cloudflare یا هر WAF دیگری را نباید به‌صورت پیش‌فرض معادل اصلاح کامل CVE در نظر گرفت.

اگر یک سرویس پشت CDN قرار دارد، باید بررسی شود:

• کدام قواعد WAF واقعاً فعال‌اند؛
• آیا درخواست‌ها از همان مسیر عبور می‌کنند؛
• آیا Origin مستقیماً از اینترنت قابل دسترس است؛
• آیا محافظت در برابر الگوهای جدید حمله کافی است؛
• آیا Runtime PHP اصلاح شده است.

WAF یک لایه دفاعی مکمل است، نه جایگزین به‌روزرسانی.

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

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

وجود یک PHP قدیمی به‌تنهایی اثبات نمی‌کند سرور هک شده است.

همچنین نبود خطا در لاگ‌ها تضمین نمی‌کند بهره‌برداری انجام نشده باشد.

۱. بررسی لاگ‌های PHP و وب‌سرور

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

نمونه بررسی لاگ PHP-FPM با systemd:

sudo journalctl -u php8.3-fpm \
  --since "2026-10-20" --no-pager

نام سرویس را متناسب با محیط واقعی جایگزین کنید.

۲. بررسی فایل‌های تازه تغییرکرده

در مسیر برنامه:

find /var/www \
  -type f \
  -mtime -3 \
  -print

این دستور فایل‌های تغییرکرده طی سه روز اخیر را نمایش می‌دهد.

فهرست خروجی باید با Deploymentها و تغییرات مجاز مقایسه شود.

۳. بررسی فرآیندهای غیرمعمول

ps auxf

بررسی کنید آیا فرآیندهای ناشناخته یا فرزندهای غیرمنتظره زیر حساب کاربری PHP اجرا شده‌اند یا خیر.

۴. بررسی ارتباط‌های شبکه

sudo ss -tunap

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

۵. بررسی فایل‌های حساس

به تغییرات غیرمنتظره در موارد زیر توجه کنید:

• فایل‌های Configuration
• فایل‌های اصلی برنامه
• پوشه‌های Upload
• حساب‌های کاربری جدید
• Scheduled Taskها
• کلیدها و Credentialهای ذخیره‌شده روی سرور

لاگ‌ها و نشانه‌های بالا شاخص‌های عمومی بررسی Incident هستند، نه امضای قطعی PHP2Shell.

اگر احتمال می‌دهیم سرور قبلاً هک شده، چه کنیم؟

در شرایطی که شواهد واقعی نفوذ وجود دارد، صرف نصب Patch کافی نیست.

بهتر است فرآیند Incident Response با ترتیب مشخص اجرا شود.

مرحله اول: کاهش دسترسی مهاجم

در صورت لزوم سرویس آسیب‌پذیر را موقتاً از دسترس عمومی خارج کنید یا دسترسی آن را محدود کنید.

مرحله دوم: حفظ شواهد

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

مرحله سوم: بررسی محدوده نفوذ

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

مرحله چهارم: اصلاح آسیب‌پذیری

PHP Runtime و سایر اجزای آسیب‌پذیر را به‌روزرسانی کنید.

مرحله پنجم: بازبینی Credentialها

اگر احتمال دسترسی مهاجم به Credentialها وجود داشته باشد، باید براساس سطح دسترسی افشاشده، رمزها و Tokenهای مرتبط را تعویض کرد.

مرحله ششم: بازیابی از وضعیت قابل اعتماد

در نفوذهای جدی، بازسازی سرویس از Image یا Backup معتبر و بررسی‌شده ممکن است مطمئن‌تر از ادامه استفاده از سیستم مشکوک باشد.

مرحله هفتم: افزایش مانیتورینگ

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

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

اگر به Root یا WHM دسترسی ندارید، احتمالاً امکان نصب مستقیم Patch هسته PHP برایتان فراهم نیست.

اما می‌توانید اقدامات زیر را انجام دهید:

1. نسخه PHP فعال سایت را از کنترل‌پنل بررسی کنید.
2. از شرکت هاستینگ درباره وضعیت CVE-۲۰۲۶-۱۰۹۶۱۸ و CVE-۲۰۲۶-۱۰۹۶۱۹ سؤال کنید.
3. بپرسید آیا بسته دارای Backport اصلاحیه نصب شده است.
4. در صورت امکان و سازگاری برنامه، نسخه PHP اصلاح‌شده یا جدیدتر را انتخاب کنید.
5. از فایل‌ها و دیتابیس سایت Backup مستقل تهیه کنید.
6. رفتار غیرمعمول سایت و لاگ خطاها را بررسی کنید.

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

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

چک‌لیست فوری امنیت PHP برای مدیران سرور

• تمام PHP Runtimeهای نصب‌شده شناسایی شوند.
• نسخه PHP وب‌سایت از CLI تفکیک شود.
• تمام FPM Poolها و VirtualHostها بررسی شوند.
• نسخه یا Backport اصلاح‌شده نصب شود.
• Workerهای قدیمی پس از Patch جایگزین شوند.
• کانتینرهای PHP از Image اصلاح‌شده بازسازی شوند.
• در cPanel وضعیت EasyApache بررسی شود.
• در CloudLinux وضعیت ALT-PHP و EA-PHP بررسی شود.
• از WAF فقط به‌عنوان دفاع مکمل استفاده شود.
• تنظیم Session Upload Progress براساس اطلاعیه تکمیلی بررسی شود.
• لاگ‌ها و فرآیندها از نظر نشانه‌های احتمالی حمله بررسی شوند.
• Backup مستقل و قابل Restore وجود داشته باشد.
• برای نسخه‌های End-of-Life برنامه ارتقا تهیه شود.

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

PHP2Shell چیست؟

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

شدت CVE-۲۰۲۶-۱۰۹۶۱۸ چقدر است؟

امتیاز آن ۹.۲ در CVSS v4.۰ و سطح شدت آن Critical است.

CVE-۲۰۲۶-۱۰۹۶۱۹ چیست؟

نقصی در مدیریت وضعیت داخلی و حافظه PHP است که می‌تواند باعث Use-After-Free و در شرایط قابل بهره‌برداری، اجرای کد از راه دور شود.

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

اولین نسخه‌های اصلاح‌شده Upstream شامل PHP ۸.۵.۱۲، ۸.۴.۲۷، ۸.۳.۳۶ و ۸.۲.۳۵ هستند. نسخه‌های بعدی همان شاخه‌ها نیز باید اصلاحیه را حفظ کرده باشند.

آیا PHP ۷.۴ همچنان آسیب‌پذیر است؟

نسخه‌های قدیمی فاقد وصله در معرض خطرند. برخی Vendorها برای PHP ۷.۴ اصلاحیه Backport ارائه کرده‌اند؛ بنابراین وضعیت دقیق Package و پشتیبانی آن باید بررسی شود.

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

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

آیا نصب آخرین نسخه WordPress مشکل را حل می‌کند؟

خیر. باید PHP Runtime یا Package مربوط اصلاح شود.

آیا PHP-FPM هم تحت تأثیر است؟

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

آیا LiteSpeed در معرض خطر است؟

محیط‌های اجرای PHP مرتبط با LiteSpeed نیز می‌توانند تحت تأثیر قرار گیرند. باید نسخه و وصله PHP بررسی شود.

آیا Cloudflare از حمله جلوگیری می‌کند؟

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

آیا غیرفعال کردن session.upload_progress.enabled کافی است؟

خیر. این کار بعضی مسیرهای حمله را محدود می‌کند، اما تمام خطرهای CVE-۲۰۲۶-۱۰۹۶۱۸ و CVE-۲۰۲۶-۱۰۹۶۱۹ را از بین نمی‌برد.

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

نه همیشه. بعضی Vendorها اصلاحیه را Backport می‌کنند. برای تشخیص باید Changelog و Advisory رسمی Package بررسی شود.

آیا با php -v می‌توان امنیت سایت را تشخیص داد؟

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

آیا exploit این آسیب‌پذیری منتشر شده است؟

گزارش‌های امنیتی از انتشار نمونه‌های اولیه و مشاهده تلاش‌های بهره‌برداری خبر داده‌اند. به همین دلیل اعمال اصلاحیه باید با اولویت بالا انجام شود.

آیا نصب Patch به معنی پاک شدن آلودگی قبلی است؟

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

جمع‌بندی؛ برای مقابله با PHP2Shell چه اقداماتی ضروری است؟

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

مهم‌ترین اقدام، نصب نسخه اصلاح‌شده PHP یا وصله معتبر ارائه‌دهنده بسته است. برای انتشارهای اصلی PHP، اولین نسخه‌های اصلاح‌شده ۸.۵.۱۲، ۸.۴.۲۷، ۸.۳.۳۶ و ۸.۲.۳۵ هستند.

در سرورهای cPanel و CloudLinux نیز باید به Package Release و Backport توجه کرد؛ چون مشاهده شماره نسخه خام PHP همیشه تمام اطلاعات لازم را نشان نمی‌دهد.

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

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

برای اجرای سایت‌های PHP و وردپرس، انتخاب زیرساخت به‌روز و مدیریت صحیح به‌اندازه کیفیت کدنویسی اهمیت دارد. اگر قصد انتخاب یا تغییر سرویس میزبانی دارید، می‌توانید سرویس‌های هاست لینوکس و هاست وردپرس پویاسازان را از نظر نیازهای فنی پروژه بررسی کنید.

در نهایت، برای جلوگیری از تکرار چنین رخدادهایی، داشتن فرآیند مدیریت آسیب‌پذیری، Patch Management، Backup مستقل، مانیتورینگ و برنامه Incident Response اهمیت اساسی دارد.

منابع معتبر و مستندات رسمی

• PHP.net – Official Security Advisory, October 2026
• PHP Security Advisory – CVE-2026-109618
• PHP Security Advisory – CVE-2026-109619
• Google Cloud – Responding to Core PHP Vulnerabilities
• CERT-EU – Security Advisory 2026-018
• CERT Coordination Center – VU#763488
• AWS Security Bulletin 2026-143
• watchTowr – PHP2Shell Security FAQ
• CVE.org – CVE-2026-109619
• cPanel – PHP Critical Security Release
• CloudLinux – PHP Security Update Status