در 21 اکتبر 2026، PHP چهار نسخه را اصلاح کرد؛ اما سرورهای میزبانی 16 نسخه اجرا می‌کنند
سه‌شنبه 20 اکتبر، ساعت 21:33 به وقت CEST، PHP پیشاپیش خبر از دو آسیب‌پذیری بحرانی داد و اعلام کرد اصلاحیه‌ی آن‌ها بعدازظهر روز بعد منتشر می‌شود. یک ارائه‌دهنده‌ی میزبانی که سرورهای cPanel را اداره می‌کرد، این اطلاعیه را خواند و بلافاصله متوجه مشکل شد. اصلاحیه فقط PHP 8.2 تا 8.5 را پوشش می‌داد، اما سایت‌های روی سرورهای او همه‌ی نسخه‌های PHP از 5.2 به بالا را اجرا می‌کنند؛ چون هر سایت روی همان نسخه‌ای می‌ماند که اپلیکیشنش برای آن ساخته شده است.
انتشار PHP چهار شاخه را اصلاح می‌کرد. روی آن سرورها 16 شاخه در حال اجراست.
توصیه‌ی رایج امنیتی PHP این است که از نسخه‌ای تحت پشتیبانی استفاده کنید و منتظر فروشنده‌ی خود بمانید. تا وقتی TechCrunch آن هفته را «PHP-ocalypse» نامید، ایراد این توصیه روشن شده بود: کسی باید مسئولیت شاخه‌هایی را بپذیرد که توسعه‌دهندگان اصلی رهایشان کرده‌اند. در ماجرای PHP2Shell (CVE-2026-109618 و CVE-2026-109619)، CloudLinux این مسئولیت را پذیرفت.
CloudLinux نسخه‌های اصلاح‌شده‌ی ea-php (بیلدهای EasyApache PHP در cPanel) و alt-php (بیلدهای PHP خود CloudLinux که PHP Selector از آن‌ها استفاده می‌کند) را برای هر 16 شاخه، از 5.2 تا 8.5، منتشر کرد. بسته‌های بومی PHP را هم برای همه‌ی نسخه‌های آسیب‌پذیر عرضه کرد.
فایروال اپلیکیشن وب (WAF) در Imunify360 از صبح 21 اکتبر، یعنی ساعت‌ها پیش از اصلاحیه‌ی PHP، جلوی اکسپلویت عمومی را می‌گرفت.
PHP2Shell چیست (CVE-2026-109618 و CVE-2026-109619)
PHP2Shell شامل دو نقص اجرای کد از راه دور در خود PHP است. امتیاز هر دو در CVSS v4.0 برابر 9.2 است و هیچ‌کدام به ورود به سیستم نیاز ندارد.
در CVE-2026-109618، حافظه‌ی PHP وسط پردازش یک درخواست تمام می‌شود و مرحله‌ی پاک‌سازی، داده‌های نیمه‌کاره را معتبر فرض می‌کند. در CVE-2026-109619، وضعیت یک درخواست پس از آزاد شدن حافظه‌اش باقی می‌ماند و درخواست بعدی روی همان worker ممکن است از آن استفاده کند.
PHP2Shell در لایه‌ای پایین‌تر از اپلیکیشن قرار دارد. PHP درخواست را پیش از اجرای کد سایت می‌خواند، پس وجود هر اسکریپت PHP روی سرور کافی است، چه با فرم کار کند و چه نکند. تدابیر امنیتی خود اپلیکیشن PHP هیچ‌وقت فرصت عمل پیدا نمی‌کنند، چون نقص پیش از شروع اجرای آن کد فعال می‌شود.
PHP همه‌ی پیکربندی‌های رو به وب را آسیب‌پذیر اعلام کرده است (PHP-FPM، mod_php، php-cgi، FrankenPHP و LiteSpeed) و Apache همراه با mod_php را پرخطرترین حالت دانسته است.
ابزار اکسپلویت از همه زودتر رسید.
جزئیات در 20 اکتبر بیرون درز کرد و یک ابزار عمومی، که آن هم PHP2Shell نام دارد، پیش از اصلاحیه منتشر شد. این ابزار از قابلیت session upload progress سوءاستفاده می‌کند که به‌طور پیش‌فرض فعال است. User-Agent برخی درخواست‌ها با php2shell- شروع می‌شود، اما حدود دو سوم درخواست‌هایی که multipart boundary این ابزار را داشتند، User-Agent دیگری داشتند.
| شاخه‌ی PHP | آنچه پروژه‌ی PHP در 21 اکتبر منتشر کرد | نسخه‌ی اصلاح‌شده |
|---|---|---|
| 8.5 | انتشار رسمی | 8.5.12 |
| 8.4 | انتشار رسمی | 8.4.27 |
| 8.3 | انتشار رسمی | 8.3.36 |
| 8.2 | انتشار رسمی | 8.2.35 |
| 8.1، 8.0، 7.4 | backport حداقلی کد منبع در اطلاعیه؛ بدون انتشار رسمی | بدون انتشار در php.net |
| 7.3 و قدیمی‌تر | هیچ | بدون انتشار در php.net |
منابع: اطلاعیه‌ی امنیتی PHP؛ اطلاعیه‌ی CloudLinux درباره‌ی CVE-2026-109618 و CVE-2026-109619.
چرا سرور میزبانی نمی‌تواند به‌سادگی ارتقا پیدا کند
نه راهنمایی که در 26 اکتبر برای عبارت امنیت PHP در نتایج جست‌وجو بالا آمده بودند، همگی به یک توصیه می‌رسند: از نسخه‌ی تحت پشتیبانی استفاده کنید. روی سرور میزبانی اشتراکی، این توصیه خطاب به آدم اشتباهی است.
یک سرور اشتراکی صدها حساب را میزبانی می‌کند و هر کدام روی همان نسخه‌ی PHP مانده‌اند که اپلیکیشنشان برای آن نوشته شده است. ماژول فروشگاهی که روی PHP 8 از کار می‌افتد، کاری به تقویم php.net ندارد.
به همین دلیل PHP Selector، که به هر حساب اجازه می‌دهد نسخه‌ی PHP خودش را انتخاب کند، از PHP 5.2 تا 8.5 را پشتیبانی می‌کند.
ارائه‌دهنده نمی‌تواند همه را به PHP 8.4 مجبور کند. ارتقای اجباری سایت‌ها را از کار می‌اندازد و سایت از کار افتاده یعنی تیکت پشتیبانی و از دست رفتن مشتری. ارائه‌دهندگان همین حالا هم هزینه‌اش را می‌دهند: 53% آن‌ها نرم‌افزار قدیمی یا آسیب‌پذیر را بزرگ‌ترین چالش امنیتی خود می‌دانند و رسیدگی به حوادث امنیتی 35% از زمان پشتیبانی آن‌ها را به خود اختصاص می‌دهد.
پس وقتی PHP می‌گوید «ارتقا دهید»، ارائه‌دهنده‌ی میزبانی در واقع با سؤال دیگری روبه‌روست: چه کسی نسخه‌ای را که مشتری من به آن وابسته است وصله می‌کند، و با چه سرعتی؟
پشت صحنه‌ی واکنش: 20 تا 23 اکتبر
تله‌متری Imunify360 نخستین درخواست ابزار اکسپلویت عمومی را ساعت 01:33 به وقت CEST در 21 اکتبر ثبت کرد؛ چهار ساعت پس از اطلاعیه‌ی PHP و 14 ساعت پیش از اصلاحیه‌ی آن. از حدود ساعت 10:20 اسکن‌ها به‌شدت بالا رفت و تا ساعت 13:00، درخواست‌هایی با نام ابزار اکسپلویت PHP2Shell به بیش از 3,600 سرور در شبکه‌ی Imunify360 رسیده بود.
WAF زودتر وارد عمل شد. ساعت 11:10، مجموعه‌قواعد 8.83 در Imunify360 به نسخه‌ی پایدار رسید و درخواست شناخته‌شده‌ی اکسپلویت را روی ModSecurity و Coraza مسدود کرد؛ حدود 4.5 ساعت پیش از اصلاحیه‌ی PHP. این قاعده ساختار درخواست را تشخیص می‌دهد، نه نام ابزار را؛ به همین دلیل درخواست‌هایی که نام ابزار را پنهان کرده بودند هم مسدود شدند.
حوالی ظهر، یک قاعده‌ی مبتنی بر اعتبار IP روی همه‌ی سرورهای محافظت‌شده، نشانی‌های مهاجم را به CAPTCHA هدایت کرد. طی سه روز، پنج انتشار مجموعه‌قواعد مسدودسازی را به LiteSpeed هم گسترش دادند، گونه‌های تغییرنام‌یافته‌ی ابزار را شناسایی کردند، قاعده‌ای برای ثبت لاگ کوکی‌های نشست نامعتبر افزودند و جلوی شیء سریال‌شده در فیلد upload progress را گرفتند. جدول پوشش Imunify360 به تفکیک وب‌سرور نشان می‌دهد هر پیکربندی از چه زمانی و چه محافظتی داشت.
از 21 تا 26 اکتبر، قواعد اختصاصی PHP2Shell حدود 9 میلیون بار با درخواست‌ها تطبیق یافتند. حدود 6.25 میلیون مورد از این تطبیق‌ها مربوط به قواعد مسدودسازی بود و در 99% آن‌ها WAF درخواست را رد کرد. اثر انگشت ابزار عمومی در 62% کل تطبیق‌ها دیده شد.
PHP ساعت 15:45 نسخه‌های 8.2.35، 8.3.36، 8.4.27 و 8.5.12 را منتشر کرد. حاصل کار، چهار اصلاحیه‌ی آماده برای بسته‌بندی بود، به‌علاوه‌ی backport کد منبع برای 7.4، 8.0 و 8.1، اما برای نه شاخه‌ی 5.2 تا 7.3 هیچ اصلاحیه‌ای در کار نبود. تیم بیلد کارهای دیگر را کنار گذاشت و اصلاحیه‌های ناموجود را خودش نوشت.
نتیجه همه‌ی شاخه‌هایی را که یک سرور میزبانی اجرا می‌کند پوشش داد. ea-php اصلاح‌شده برای هر 16 شاخه، از ea-php52 تا ea-php85، روی CloudLinux 7 تا 10 منتشر شد. alt-php اصلاح‌شده هم برای هر 16 شاخه روی CloudLinux 7، 8 و 9 عرضه شد. پس از آن بسته‌های بومی PHP برای همه‌ی نسخه‌های آسیب‌پذیر آمدند و TuxCare Endless Lifecycle Support (ELS) نیز برای alt-php، PHP توزیع‌ها و PHP for Windows بسته منتشر کرد. همه‌ی این‌ها در قالب یک به‌روزرسانی معمولی بسته ارائه شدند.
آنچه برای PHP2Shell منتشر شد
| بیلد | شاخه‌های اصلاح‌شده | محل |
|---|---|---|
| ea-php (cPanel EasyApache) | 16: ea-php52 تا ea-php85 | CloudLinux 7، 8، 9 و 10 |
| alt-php (PHP Selector) | 16: 5.2 تا 8.5 | CloudLinux 7، 8 و 9 |
| PHP بومی (بسته‌های توزیع) | همه‌ی نسخه‌های آسیب‌پذیر | CloudLinux 7 تا 10 |
| TuxCare ELS for PHP | alt-php، PHP توزیع‌ها و PHP for Windows | مخازن ELS |
| بیلدهای مجدد با شماره‌گذاری php.net | alt-php و ea-php نسخه‌های 8.2 تا 8.5 | alt-php روی CloudLinux 7، 8 و 9؛ ea-php روی CloudLinux 7 تا 10 و CloudLinux for Ubuntu 22.04 |
منبع: اطلاعیه‌ی CloudLinux که همه‌ی بسته‌ها و نسخه‌های اصلاح‌شده را فهرست کرده است.
گاه‌شمار: واکنش به PHP2Shell، 20 تا 23 اکتبر 2026 (CEST)
| زمان (CEST) | مسیر | رویداد |
|---|---|---|
| 20 اکتبر 21:33 | افشا و حمله | اعلام پیشاپیش PHP |
| 21 اکتبر 01:33 | افشا و حمله | نخستین درخواست اکسپلویت |
| 21 اکتبر 10:20 | افشا و حمله | آغاز اسکن گسترده |
| 21 اکتبر 11:10 | Imunify360 WAF | مجموعه‌قواعد 8.83 درخواست شناخته‌شده‌ی اکسپلویت را مسدود کرد |
| 21 اکتبر 12:00 | Imunify360 WAF | CAPTCHA بر پایه‌ی اعتبار IP |
| 21 اکتبر 15:18 | Imunify360 WAF | مجموعه‌قواعد 8.84 پشتیبانی از LiteSpeed را اضافه کرد |
| 21 اکتبر 15:45 | مرجع | PHP اصلاحیه‌اش را منتشر کرد (8.2.35، 8.3.36، 8.4.27، 8.5.12) |
| 21 اکتبر 19:17 | Imunify360 WAF | مجموعه‌قواعد 8.85: گونه‌های تغییرنام‌یافته |
| 21 اکتبر 22:55 | بسته‌های اصلاح‌شده‌ی PHP | ea-php نسخه‌های 5.2 تا 8.5 |
| 22 اکتبر 02:07 | بسته‌های اصلاح‌شده‌ی PHP | alt-php در کانال پایدار |
| 22 اکتبر 07:50 | Imunify360 WAF | مجموعه‌قواعد 8.86: گونه‌های بیشتر |
| 22 اکتبر 21:50 | بسته‌های اصلاح‌شده‌ی PHP | PHP بومی، همه‌ی نسخه‌ها |
| 23 اکتبر 02:08 | بسته‌های اصلاح‌شده‌ی PHP | alt-php با شماره‌نسخه‌های php.net |
| 23 اکتبر 10:40 | Imunify360 WAF | مجموعه‌قواعد 8.88: شیء سریال‌شده |
همه‌ی موارد مسیر WAF پیش از ساعت 15:45 روز 21 اکتبر، یعنی پیش از انتشار اصلاحیه‌ی PHP، اعمال شده بودند.
همه چیز هم بی‌نقص پیش نرفت. نخستین بسته‌های اصلاح‌شده‌ی alt-php و ea-php همان شماره‌نسخه‌های قدیمی را داشتند و در نتیجه اسکنرها سرورهای وصله‌شده را آسیب‌پذیر گزارش کردند. در 21 اکتبر هم انتشار alt-php اصلاح‌شده برای CloudLinux را اعلام کردیم، در حالی که بسته فقط در مخزن TuxCare ELS بود؛ رفع این مشکل حدود سه ساعت طول کشید (و این فاصله پیش از انتشار اصلاحیه، دامن مشتریان را گرفت).
سرورهایی که WAF آن‌ها خاموش یا در حالت فقط ثبت لاگ بود، یا ImunifyAV (اسکنر بدافزار Imunify) را اجرا می‌کردند، محافظت WAF نداشتند. تا 26 اکتبر، قواعد مسدودسازی همچنان روی مسیر upload progress تمرکز دارند که اکسپلویت عمومی از آن استفاده می‌کند. مسیر کمبود حافظه در CVE-2026-109618 با قواعد ثبت لاگ پوشش داده می‌شود که شکل‌های محتمل درخواست را می‌سنجند، اما هنوز قاعده‌ی مسدودسازی برای آن وجود ندارد.
یک اصلاح هم انجام شده است: alt-php و ea-php برای نسخه‌های 8.2 تا 8.5 در 23 اکتبر با شماره‌نسخه‌های php.net دوباره بیلد شدند.
رخداد ثبت‌شده در صفحه‌ی وضعیت سابقه‌ی کامل ماجرا را در خود دارد.
وقتی پشتیبانی PHP تمام می‌شود، چه کسی وصله می‌دهد
سه لایه PHP را وصله می‌کنند و کار هر کدام در نقطه‌ی متفاوتی تمام می‌شود.
- پروژه‌ی PHP اصلاحیه‌ها را برای شاخه‌های تحت پشتیبانی (این بار 8.2 تا 8.5) منتشر می‌کند و برای چند شاخه‌ی قدیمی‌تر فقط backport کد منبع، بدون انتشار رسمی، ارائه می‌دهد.
- توزیع‌های Linux اصلاحیه‌ها را برای نسخه‌های PHP موجود در مخازن خود و با زمان‌بندی خودشان منتشر می‌کنند.
- لایه‌ی سوم فروشنده‌ای است که مسئولیت شاخه را بر عهده می‌گیرد: برای نسخه‌هایی که توسعه‌دهندگان اصلی سراغشان نمی‌روند اصلاحیه می‌نویسد، آن را بیلد و آزمایش می‌کند و از طریق مدیر بسته‌ی سرور عرضه می‌کند.
OWASP PHP Configuration Cheat Sheet نکته‌ی منصفانه‌ای را یادآوری می‌کند: پشتیبانی تمدیدشده از سوی توزیع یا فروشنده، یک شاخه را «تحت پشتیبانی» نمی‌کند. ما هم با این حرف موافقیم. PHP 7.4 با یک اصلاحیه‌ی backportشده همچنان بیرون از سیاست php.net است. اما همین اصلاحیه CVE را روی دقیقاً همان نسخه‌ای که سایت اجرا می‌کند می‌بندد تا زمان ارتقا را مشتری تعیین کند، نه CVE.
HardenedPHP، مجموعه‌وصله‌های backportشده‌ای که در CloudLinux و Imunify360 گنجانده شده، اصلاحیه‌های امنیتی را به نسخه‌های پایان‌عمر PHP 5.x، 7.x و 8.x می‌رساند؛ در قالب بسته‌هایی که مستقیماً جایگزین می‌شوند و با PHP Selector کار می‌کنند. اگر از CloudLinux یا Imunify360 استفاده می‌کنید، نسخه‌های پایان‌عمر PHP شما از همین امروز پوشش داده می‌شوند.
ELS for PHP همان فناوری است که به‌صورت مستقل برای بقیه‌ی سرورها روی 20 پلتفرم عرضه می‌شود: EL6 تا EL10، Ubuntu 16.04 تا 26.04، Debian 10 تا 13، Alpine 3.23 و 3.24، و Windows Server 2019، 2022 و 2025.
انتشار PHP چهار شاخه را اصلاح کرد؛ ما برای 16 شاخه اصلاحیه منتشر کردیم.
چرخه‌ی عمر PHP و نسخه‌ی بعدی که پشتیبانی‌اش تمام می‌شود
عمر PHP 8.2 در 31 دسامبر 2026، یعنی نه هفته پس از این نوشته، به پایان می‌رسد.
پس از آن، CVE بعدی PHP، با هر امتیازی، هیچ انتشار رسمی‌ای برای 8.2 در php.net نخواهد داشت. از PHP 8.1 به بعد، هر شاخه حدود دو سال پشتیبانی فعال دارد و دو سال دیگر فقط اصلاحیه‌ی امنیتی می‌گیرد که در 31 دسامبر تمام می‌شود.
| شاخه‌ی PHP | پایان پشتیبانی امنیتی (php.net) | وضعیت در 26 اکتبر 2026 | چه کسی پس از آن وصله می‌کند |
|---|---|---|---|
| 8.5 | 31 دسامبر 2029 | تحت پشتیبانی | پروژه‌ی PHP |
| 8.4 | 31 دسامبر 2028 | تحت پشتیبانی | پروژه‌ی PHP |
| 8.3 | 31 دسامبر 2027 | فقط اصلاحیه‌های امنیتی | پروژه‌ی PHP |
| 8.2 | 31 دسامبر 2026 | فقط اصلاحیه‌های امنیتی؛ نه هفته‌ی دیگر تمام می‌شود | پروژه‌ی PHP تا 31 دسامبر، سپس توزیع‌ها برای بسته‌های خودشان و HardenedPHP / ELS for PHP |
| 8.1 | 31 دسامبر 2025 | پایان عمر | توزیع‌ها برای بسته‌های خودشان؛ HardenedPHP / ELS for PHP |
| 8.0 | 26 نوامبر 2023 | پایان عمر | همان |
| 7.4 | 28 نوامبر 2022 | پایان عمر | همان |
| 7.3 | 6 دسامبر 2021 | پایان عمر | همان |
| 5.6 | 31 دسامبر 2018 | پایان عمر | همان (alt-php و ea-php تا 5.2 را وصله می‌کنند) |
منابع: نسخه‌های تحت پشتیبانی در php.net و شاخه‌های پایان‌عمر، بازدید در 26 اکتبر 2026.
روش‌های امنیتی PHP که روی سرور اشتراکی جواب می‌دهند
بیشتر روش‌های توصیه‌شده‌ی امنیت PHP روی سرور اشتراکی هم کاربرد دارند.
تفاوت در این است که مسئولیت هر کدام با کیست. ارائه‌دهنده برخی را در php.ini برای کل سرورها تنظیم می‌کند و برخی دیگر به کد مشتری مربوط‌اند.
PHP2Shell محک خوبی است: تقریباً هیچ‌کدام جلویش را نگرفتند.
| روش یا پیکربندی PHP | جلوی چه چیزی را می‌گیرد | در برابر PHP2Shell | مسئول آن روی سرور اشتراکی |
|---|---|---|---|
| بیلد وصله‌شده‌ی PHP | خود CVE | تنها اصلاح کامل | ارائه‌دهنده نصبش می‌کند؛ هر کس مسئول شاخه است آن را بیلد می‌کند |
| WAF در حالت مسدودسازی | درخواست‌های شناخته‌شده‌ی اکسپلویت | از مجموعه‌قواعد 8.83 مسیر upload progress اکسپلویت عمومی را مسدود کرد؛ برای مسیر کمبود حافظه‌ی 109618 قاعده‌ای ندارد | ارائه‌دهنده؛ حالت فقط ثبت لاگ هیچ محافظتی نمی‌کند |
| session.upload_progress.enabled = 0 | قابلیت upload progress | راهکار موقت PHP برای 109619. PHP از 23 اکتبر به دلیل CVE-2026-115560 توصیه می‌کند تا انتشار منظم بعدی خاموش بماند | ارائه‌دهنده، در php.ini یا pool مربوط به PHP-FPM؛ نه با ini_set() یا .user.ini |
| محدودیت‌های حافظه و اندازه‌ی درخواست (memory_limit، post_max_size، max_file_uploads) | درخواست‌ها و بارگذاری‌های بیش از حد بزرگ | اطلاعیه‌ی PHP برای نقص کمبود حافظه تنظیماتی پیشنهاد می‌کند؛ آن‌ها را دقیقاً طبق توضیح اعمال کنید | ارائه‌دهنده |
| جداسازی هر حساب (CageFS، یک فایل‌سیستم مجازی‌شده برای هر حساب) | گسترش نفوذ میان حساب‌ها | دامنه‌اش را محدود می‌کند، اما جلویش را نمی‌گیرد | ارائه‌دهنده |
| disable_functions (exec، system، shell_exec، passthru) | دستورهای shell از کد PHP تزریق‌شده | خیر: نقص‌ها وقتی فعال می‌شوند که PHP درخواست را می‌خواند | ارائه‌دهنده، برای هر نسخه‌ی PHP |
| open_basedir | دسترسی اسکریپت‌ها به خارج از مسیرهای مجاز | خیر، به همان دلیل | ارائه‌دهنده، برای هر حساب |
| allow_url_include = Off، allow_url_fopen | درج فایل از راه دور (RFI) | خیر | ارائه‌دهنده |
| expose_php = Off | افشای نسخه در هدرها | خیر: اسکنرها همه‌ی سرورها را هدف گرفتند | ارائه‌دهنده |
| display_errors = Off، log_errors = On | نمایش stack trace به بازدیدکنندگان | خیر | پیش‌فرض ارائه‌دهنده؛ مالک سایت می‌تواند آن را تغییر دهد |
| session.cookie_httponly، session.cookie_secure، session.use_strict_mode | ربایش و تثبیت نشست | خیر | پیش‌فرض ارائه‌دهنده؛ مالک سایت می‌تواند آن را سخت‌گیرانه‌تر کند |
| Prepared statementها | تزریق SQL | خیر | مالک سایت |
| Escape کردن خروجی و Content Security Policy (CSP) | اسکریپت‌نویسی میان‌وبگاهی (XSS) | خیر | مالک سایت |
| توکن‌های CSRF | جعل درخواست میان‌وبگاهی | خیر | مالک سایت |
مرجع کامل دستورها: OWASP PHP Configuration Cheat Sheet. دسته‌های آسیب‌پذیری: راهنمای TuxCare درباره‌ی آسیب‌پذیری‌های رایج PHP.
چطور مطمئن شویم سرور اصلاح شده است
این آزمون امنیتی PHP را برای تک‌تک نسخه‌های PHP که روی سرور ارائه می‌شود اجرا کنید.
گام 1. changelog هر بیلد را از نظر شناسه‌های CVE بررسی کنید (دستورها در ادامه آمده است؛ برای هر نسخه‌ی نصب‌شده‌ی alt-php و ea-php تکرار کنید و برای ea-php روی Ubuntu از dpkg -l استفاده کنید). بسته‌های بومی rebaseشده نامی از CVE نمی‌برند؛ برای آن‌ها بررسی کنید که نسخه‌ی 8.2.35، 8.3.36 یا بالاتر نصب باشد. اگر بسته‌های اصلاح‌شده را نمی‌بینید، مطمئن شوید cloudlinux-release به‌روز است.
rpm -q --changelog alt-php85-common | grep -E 'CVE-2026-(109618|109619)'
rpm -q --changelog ea-php84-php-cli | grep -E 'CVE-2026-(109618|109619)'
dpkg -l ea-php84-php-cli # CloudLinux for Ubuntu: compare the version with the fixed list
rpm -q --changelog php-cli | grep -E 'CVE-2026-(109618|109619)'
rpm -q php-cli # rebased native builds: 8.2.35 or later on 8.2, 8.3.36 or later on 8.3
rpm -q cloudlinux-release # if the update fails or finds nothing to installگام 2. پس از به‌روزرسانی، PHP-FPM یا وب‌سرور را ری‌استارت کنید. نصب بسته‌ی وصله‌شده، workerهایی را که از قبل در حال اجرا هستند اصلاح نمی‌کند. برای ea-php روی cPanel:
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpmگام 3. session upload progress را خاموش نگه دارید. session.upload_progress.enabled = 0 را در php.ini یا pool مربوط به PHP-FPM (php_admin_value) تنظیم کنید، یعنی جایی که حساب‌ها نتوانند تغییرش دهند؛ یک فایل .user.ini می‌تواند آن را دوباره فعال کند. PHP ابتدا این را راهکار موقت PHP2Shell معرفی کرد. در 23 اکتبر این توصیه را به سرورهای وصله‌شده هم تعمیم داد، چون نقص سومی مربوط به نشست، CVE-2026-115560، فقط در انتشار منظم بعدی PHP اصلاح می‌شود. این نقص به پیکربندی غیرمعمولی نیاز دارد: اپلیکیشنی که session.serialize_handler را در زمان اجرا به php تغییر دهد. پس اپلیکیشن‌هایی که هرگز چنین کاری نمی‌کنند، می‌توانند این قابلیت را روشن نگه دارند. PHP را ری‌استارت کنید، مقدار مؤثر را برای هر نسخه در صفحه‌ی phpinfo() تأیید کنید و بعد آن صفحه را حذف کنید؛ php -i تنظیمات خط فرمان را نشان می‌دهد که ممکن است متفاوت باشد. اطلاعیه‌ی PHP برای نقص کمبود حافظه، تنظیمات جداگانه‌ای برای حافظه و اندازه‌ی درخواست پیشنهاد می‌کند.
گام 4. مطمئن شوید WAF در Imunify360 روشن است، در حالت مسدودسازی کار می‌کند و مجموعه‌قواعد 8.88 یا جدیدتر را دارد. مسیر زیر برای cPanel با Apache است؛ دیگر کنترل‌پنل‌ها و LiteSpeed از مسیرهای متفاوتی استفاده می‌کنند. با کاربر root اجرا کنید:
cat /etc/apache2/conf.d/modsec_vendor_configs/imunify360-full-apache/VERSION
imunify360-agent update --force modsec-rules # if older than 8.88, then check againگام 5. بررسی کنید آیا درخواست‌های اکسپلویت پیش از وصله شدن سرور به PHP رسیده‌اند یا نه. لاگ‌های دسترسی پیش‌فرض User-Agent را ثبت می‌کنند، اما multipart boundary یا فیلدهای فرم را ثبت نمی‌کنند؛ پس فقط درخواست‌هایی را نشان می‌دهند که نام ابزار را دارند. در Imunify360، فهرست Incidents تطبیق‌های WAF را به تفکیک قاعده نشان می‌دهد (77830995، 77318849، 77866818، 77236259 و قواعد بعدی PHP2Shell). لاگ ممیزی ModSecurity هم، اگر فعال باشد، ممکن است هدرهای درخواست‌های علامت‌خورده را داشته باشد. درخواستی که WAF مسدود کرده هرگز به PHP نرسیده است، اما برخی درخواست‌ها رسیده‌اند: هر درخواستی پیش از اعمال قواعد (ساعت 11:10 به وقت CEST در 21 اکتبر، یا 15:18 روی LiteSpeed)، هر درخواستی روی سرورهایی که WAF آن‌ها خاموش یا در حالت فقط ثبت لاگ بوده، و گونه‌هایی که قواعد تشخیصشان نمی‌دهند. این‌ها هیچ ردی در فهرست Incidents به جا نمی‌گذارند، پس منتظر دیدن تطبیق نمانید. برای هر حسابی که PHP وصله‌نشده اجرا می‌کرد، اول لاگ‌ها را نگه دارید، بعد اسکن بدافزار برای یافتن web shellها اجرا کنید، فایل‌های PHP را که از 20 اکتبر به بعد در پوشه‌های وب‌سایت نوشته شده‌اند پیدا کنید و فرایندهای غیرمنتظره‌ای را که با کاربر آن حساب (یا در mod_php با کاربر وب‌سرور) اجرا می‌شوند بررسی کنید. پیش از حذف هر فایل، از ماهیتش مطمئن شوید.
بهداشت امنیتی عمومی، فراتر از PHP2Shell: روی اپلیکیشن‌های مبتنی بر Composer دستور composer audit را اجرا کنید؛ ممیزی امنیتی مفسر PHP درباره‌ی کتابخانه‌هایی که روی آن اجرا می‌شوند چیزی نمی‌گوید.
| نشانگر | مقدار |
|---|---|
| User-Agent | با php2shell- شروع می‌شود (برای نمونه php2shell-109618، php2shell-scan/109618)؛ برخی ابزارهای بررسی امنیتی هم از آن استفاده می‌کنند |
| Multipart boundary | B7kQpoc618، B7kQpoc619؛ boundaryهای تغییرنام‌یافته که php2shell یا nphp618 در آن‌ها هست؛ boundaryهایی که با p2s شروع می‌شوند، یا lfi به همراه 16 کاراکتر hex |
| شکل درخواست | یک POST از نوع multipart با فیلد PHP_SESSION_UPLOAD_PROGRESS، یک شناسه‌ی نشست، یک فایل و فیلدهای متنی حاوی داده‌ی باینری، معمولاً بدون Referer |
اینترنت فقط روی PHP 8.xx اجرا نمی‌شود
برگردیم سراغ مدیر عملیات آن ارائه‌دهنده‌ی میزبانی که سه‌شنبه‌شب اطلاعیه‌ی PHP را می‌خواند.
تا جمعه، برای هر شاخه‌ی روی آن سرورها بسته‌ی اصلاح‌شده وجود داشت و چهار نسخه‌ای که php.net هنوز پشتیبانی‌شان می‌کند، شماره‌نسخه‌هایی داشتند که اسکنرها می‌توانستند تشخیص دهند.
مهلت بعدی 31 دسامبر است؛ روزی که 8.2 از فهرست نسخه‌های تحت پشتیبانی خارج می‌شود.
شاخه‌هایی را که حساب‌هایتان اجرا می‌کنند با جدول چرخه‌ی عمر مقایسه کنید. برای هر نسخه‌ی پایان‌عمر، بیلد وصله‌شده روی CloudLinux و Imunify360 همان HardenedPHP است و در هر جای دیگر، ELS for PHP.
پرسش‌های متداول
آیا اجرای PHP 7.4 در سال 2026 امن است؟
روی یک بیلد استاندارد، نه. عمر PHP 7.4 در نوامبر 2022 به پایان رسید و php.net برای PHP2Shell فقط یک backport کد منبع ارائه کرد. تا زمانی که ارتقا را برنامه‌ریزی می‌کنید، آن را روی یک بیلد وصله‌شده مثل HardenedPHP یا ELS for PHP اجرا کنید.
پس از پایان عمر PHP، چه کسی وصله‌های امنیتی آن را ارائه می‌دهد؟
توزیع‌ها نسخه‌های PHP را که خودشان عرضه می‌کنند وصله می‌کنند و بقیه را فروشندگانی که مسئولیت یک شاخه را پذیرفته‌اند. CloudLinux شانزده شاخه، از 5.2 تا 8.5، را پوشش می‌دهد: با HardenedPHP روی CloudLinux و Imunify360 و با ELS for PHP در جاهای دیگر.
آیا disable_functions یا open_basedir در برابر PHP2Shell محافظت می‌کند؟
خیر. هر دو روی اسکریپت‌های در حال اجرا اثر دارند، اما PHP2Shell زمانی فعال می‌شود که PHP هنوز مشغول خواندن درخواست است. خاموش کردن session upload progress یکی از مسیرها را می‌بندد؛ فقط بیلد وصله‌شده هر دو CVE را برطرف می‌کند.
چطور روی سرورم آزمون امنیتی PHP اجرا کنم؟
برای PHP2Shell: changelog یا شماره‌نسخه‌ی هر نسخه‌ی PHP را با فهرست نسخه‌های اصلاح‌شده مقایسه کنید، PHP را ری‌استارت کنید، مطمئن شوید مجموعه‌قواعد WAF نسخه‌ی 8.88 یا جدیدتر است و رخدادهای WAF و لاگ‌های دسترسی را برای یافتن نشانگرهای ابزار بررسی کنید. برای اپلیکیشن‌ها هم composer audit را روی وابستگی‌هایشان اجرا کنید.
تفاوت HardenedPHP و ELS for PHP چیست؟
فناوری یکی است، بسته‌بندی متفاوت. HardenedPHP همراه CloudLinux و Imunify360 ارائه می‌شود. ELS for PHP محصولی مستقل برای دیگر توزیع‌ها و سرورهای بدون Imunify360 است و روی 20 پلتفرم، از جمله Ubuntu، Debian، Alpine و Windows Server، در دسترس است.
منبع: On 21 Oct 2026, PHP fixed four versions. Hosting servers run on 16.، CloudLinux Blog
