21 اکتبر 2026 | PHP | امنیت فناوری اطلاعات
در 21 اکتبر 2026 تیم امنیتی PHP بهروزرسانیهایی را برای همهٔ نسخههای هنوز پشتیبانیشدهٔ PHP منتشر کرد. آنها دو آسیبپذیری بحرانی را میبندند که با نام PHP2Shell شناخته شدهاند. BSI دربارهٔ آن هشداری صادر کرده و میخواهد سیستمهای آسیبدیده بیدرنگ وصله شوند. هر که وبسروری با PHP راه میاندازد، باید همین امروز اقدام کند. این برای همهٔ کسانی هم صدق میکند که «فقط» یک WordPress، Nextcloud یا Joomla راه میاندازند، چون این برنامهها روی PHP اجرا میشوند.
این مطلب خلاصه میکند که چه رخ داد، کدام نسخههای PHP آسیبدیدهاند، اکنون به کدام نسخه نیاز دارید و چگونه در چند دقیقه بررسی کنید که سرورتان ایمن است یا نه.
فهرست مطالب این نوشته
چه رخ داد؟ روند زمانی
تیم امنیتی PHP انتشار اصلاحات را از پیش اعلام کرده بود تا هاستینگها و مدیران زمان آمادهسازی داشته باشند. خودِ انتشار در 21 اکتبر 2026 انجام شد. BSI همان روز هشدار خود (نسخهٔ 1.1) را صادر کرد.
- 20 اکتبر 2026: هشدار پیشین تیم امنیتی PHP مبنی بر اینکه روز بعد بهروزرسانیهای امنیتی منتشر میشود.
- 21 اکتبر 2026، ساعت 14:00 UTC (16:00 به وقت MESZ): وصلههای PHP 8.5، 8.4، 8.3 و 8.2 منتشر میشوند.
- 21 اکتبر 2026: BSI دربارهٔ «آسیبپذیریهای بحرانی که برنامههای وب را در سراسر جهان تهدید میکنند» هشدار میدهد و توصیه میکند بیدرنگ وصله کنید. به گفتهٔ BSI، ارائهدهندگان بزرگ هاستینگ تا حدی سرورها را بهطور احتیاطی آفلاین کردهاند.
دو آسیبپذیری PHP در یک نگاه
این دو خطای جداگانه در هستهٔ PHP است: CVE-2026-109618 و CVE-2026-109619. هر دو بر پایهٔ اظهارات تیم امنیتی PHP میتوانند باعث شوند مهاجم بدون ورود بتواند کد برنامه را روی سرور اجرا کند (unauthenticated Remote Code Execution). این آسیبپذیریها با CVSS v4.0: 9.2 (بحرانی) ارزیابی میشوند.
| ویژگی | معنا |
|---|---|
| شناسهها | CVE-2026-109618 و CVE-2026-109619 |
| ارزیابی | CVSS v4.0: 9.2 — بحرانی |
| پیامد | اجرای کد روی سرور (Remote Code Execution)، بدون ورود |
| علت 1 | حافظهٔ آسیبدیده زمانی که PHP در حین پردازش دیگر حافظهٔ کاری دریافت نمیکند (Out-of-Memory) |
| علت 2 | وضعیت سراسری کهنه که میان درخواستها در حافظه باقی میماند |
| بهویژه در معرض خطر | Apache با mod_php |
به ارزیابی BSI، در زمان انتشار هیچ حملهٔ تأییدشدهای وجود نداشت، اما نشانههایی تأییدنشده از تلاشهای سوءاستفاده وجود داشت. در حفرههای بحرانی نرمافزاری به این گستردگی، طبق تجربه باید انتظار داشت که مهاجمان اصلاحات را تحلیل کنند و حملات خودکار را آماده سازند. بنابراین پنجرهٔ زمانی برای وصلهکردن کوتاه است.
چه کسی آسیبدیده است؟
اساساً هر سروری که PHP روی آن اجرا میشود آسیبدیده است، فارغ از اینکه PHP چگونه متصل شده باشد: PHP-FPM، mod_php در Apache، php-cgi، FrankenPHP یا LiteSpeed. به گفتهٔ تیم امنیتی PHP بیشترین خطر در Apache با mod_php است.
BSI صراحتاً برنامههایی را نام میبرد که بر پایهٔ PHP ساخته شدهاند و از این رو میتوانند آسیبدیده باشند:
- سامانههای مدیریت محتوا: WordPress، Drupal، TYPO3، Joomla
- سامانههای فروشگاهی: Magento
- فضای ابری و ذخیرهٔ فایل: Nextcloud
- رابطهای فایروال: pfSense، OPNsense
برای این منظور خودِ برنامه لازم نیست معیوب باشد. حفره در PHP است، از این رو بهروزرسانی WordPress، Nextcloud & امثال آن بهتنهایی کمک نمیکند. باید نسخهٔ PHP روی سرور بهروزرسانی شود. در فایروالهایی مانند pfSense و OPNsense نسخهٔ PHP اصلاحشده از طریق بهروزرسانی Firmware سازندهٔ مربوطه میآید.
این نسخههای 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 | پشتیبانی در 31 دسامبر 2026 پایان مییابد |
| PHP 8.1 و قدیمیتر | بهروزرسانی رسمی وجود ندارد، ببینید پایین | |
سرورتان را اینگونه بررسی و بهروزرسانی کنید
1. تعیین نسخهٔ نصبشدهٔ PHP
در خط فرمان سرور، php -v نسخهٔ PHP خط فرمان را نشان میدهد. وبسرور میتواند از یک نسخهٔ دیگر PHP استفاده کند. از این رو نسخهٔ PHP-FPM یا ماژول Apache را نیز بررسی کنید، مثلاً با php-fpm8.3 -v یا از طریق صفحهای که phpinfo() را نمایش میدهد (آن را سپس بیدرنگ دوباره حذف کنید).
2. اعمال بهروزرسانی از طریق مدیریت بستهها
در Debian، Ubuntu، RHEL و مشابه آنها نسخهٔ اصلاحشده از طریق مدیریت بستهٔ عادی میآید، مثلاً apt update && apt upgrade یا dnf upgrade. در منابع بیرونی مانند Sury-PPA یا مخزن Remi، بستههای جدید معمولاً بهزودی ظاهر میشوند.
apt changelog php8.3-fpm یا rpm -q --changelog php | grep CVE-2026-1096).
3. راهاندازی مجدد سرویس PHP
بهروزرسانی بسته بهتنهایی کافی نیست: فرایندهای در حال اجرای PHP کد قدیمی را در حافظه نگه میدارند. PHP-FPM (systemctl restart php8.3-fpm) یا Apache (systemctl restart apache2) را دوباره راهاندازی کنید و سپس بررسی کنید که فرایندها پس از بهروزرسانی آغاز شدهاند.
4. وبسایتهای میزبانیشده
در Shared Hosting معمولاً ارائهدهنده بهروزرسانی میکند. در منوی مشتری معمولاً میتوان نسخهٔ PHP را برای هر وبسایت تنظیم کرد. در آنجا یکی از نسخههای امن بالا را انتخاب کنید، یا از ارائهدهنده دربارهٔ وضعیت وصلهها بپرسید. به گفتهٔ BSI، برخی ارائهدهندگان سرورها را بهطور احتیاطی از شبکه خارج کردهاند. اگر وبسایت شما برای مدتی کوتاه در دسترس نبود، این میتواند علت باشد.
PHP 8.1 و قدیمیتر: بهروزرسانی رسمی وجود ندارد
برای PHP 8.1 و قدیمیتر دیگر هیچ بهروزرسانی امنیتی رسمی وجود ندارد. مدیران چنین سیستمهایی دو امکان دارند:
- رفتن به یک نسخهٔ پشتیبانیشده (توصیه میشود). هر چه نسخه قدیمیتر باشد، زحمت سازگارسازی برنامه و افزونهها بیشتر است، از این رو باید پیشتر یک انتقال آزمایش شود.
- بازپورت (Backport) اصلاحات. تیم امنیتی PHP اصلاحات را در شاخههای توسعه روی GitHub در اختیار گذاشته است. هر که PHP را خودش کامپایل میکند، میتواند این تغییرات را در نسخههای قدیمیتر بپذیرد. این یک راهحل موقت است و دانش تخصصی میطلبد.
PHP 8.2 نیز فقط تا 31 دسامبر 2026 پشتیبانی میشود. از این رو همین حالا گذار به PHP 8.4 یا 8.5 را برنامهریزی کنید و آن را به تعویض سال موکول نکنید.
اقدامات موقت و پرسش «سرور را آفلاین کنیم؟»
تیم امنیتی PHP با اعلامیه اقدامات حفاظتی موقت را نیز شرح داده است. اینها خطر را کم میکنند، اما حفرهها را بهطور کامل نمیبندند. جایگزین بهروزرسانی نیستند و فقط برای پر کردن زمان تا بهروزرسانی در نظر گرفته شدهاند.
اینکه یک سرور تا زمان بهروزرسانی باید از شبکه خارج شود یا نه، به اهمیت و دسترسپذیری آن بستگی دارد. BSI توضیح میدهد که ارائهدهندگان بزرگ این گام را برداشتهاند. قاعدهٔ سرانگشتی:
- سرور با دسترسی عمومی، بهروزرسانی اکنون ممکن است: بیدرنگ وصله کنید، خاموشکردن لازم نیست.
- سرور با دسترسی عمومی، بهروزرسانی در کوتاهمدت ممکن نیست: دسترسی را محدود کنید (مثلاً با فایروال فقط برای نشانیهای شناختهشده) یا سرویس را موقتاً خاموش کنید، بهویژه در
mod_php. - سرور فقط با دسترسی داخلی: بهزودی وصله کنید، فوریت کمتر است.
پرسشهای متداول
آیا باید WordPress، Joomla یا Nextcloud را بهروزرسانی کنم؟
بهخاطر این آسیبپذیری نه. این آسیبپذیری در PHP قرار دارد، نه در خود برنامه. نسخهٔ PHP را روی سرور بهروزرسانی کنید. بهروزرسانی برنامه نیز مستقل از این موضوع همچنان توصیه میشود.
از کجا بفهمم که کسی از این آسیبپذیری سوءاستفاده کرده است یا نه؟
اظهارنظر قطعی دشوار است. فایلهای PHP ناشناخته در پوشهٔ وب، فرایندهای غیرعادی زیر کاربر وبسرور، حسابهای کاربری یا Cronjobهای جدید و ترافیک خروجی غیرعادی نشانههای مشکوک هستند. در صورت وجود ظن مشخص، سیستم باید بهصورت فارنزیک بررسی شود و در صورت تردید از نو راهاندازی گردد.
آیا یک Web Application Firewall کافی است؟
یک فایروال میتواند الگوهای حملهٔ شناختهشده را مسدود کند، اما جایگزین بهروزرسانی نیست. دربارهٔ تعامل چند لایهٔ حفاظتی در مقالهٔ ما بخوانید: ایمنسازی Odoo 19: فایروال، 2FA & Web RBL. این اصول برای هر برنامهٔ وب صادق است.
آیا Odoo هم تحتتأثیر است؟
خیر. Odoo با Python نوشته شده و روی PHP اجرا نمیشود. فقط برنامههای PHP که روی همان سرور اجرا میشوند ممکن است تحتتأثیر باشند.
اطلاعات رسمی را کجا پیدا کنم؟
اعلامیهٔ تیم امنیتی PHP را در آرشیو اخبار php.net (مورد مربوط به ۲۰ اکتبر ۲۰۲۶) و نسخهها را در php.net/downloadsپیدا میکنید. هشدار BSI شمارهٔ 2026-297981-1032 را دارد و در bsi.bund.de منتشر شده است.
پشتیبانی از سوی Biricon IT Services
اگر مطمئن نیستید که چه نسخهای از PHP روی سرور شما اجرا میشود یا برای وصلهکردن به کمک نیاز دارید، با کمال میل در کنار شما هستیم: در فهرستبرداری از تمام سیستمهای PHP، در نصب بهروزرسانیها، در مهاجرت به یک نسخهٔ پشتیبانیشدهٔ PHP و در بررسی از نظر نفوذ و آلودگی. ما بهعنوان ارائهدهندهٔ خدمات فناوری اطلاعات، سرورها، فایروالها و برنامههای وب را برای کسبوکارهای کوچک و متوسط پشتیبانی میکنیم.
تاریخ بروزرسانی: ۲۱ اکتبر ۲۰۲۶. وضعیت ممکن است در کوتاهمدت تغییر کند؛ آنچه معتبر است انتشارات تیم امنیتی PHP و BSI است.