دو آسیب‌پذیری بحرانی در PHP با شناسه‌های CVE-2026-109618 و CVE-2026-109619 به مهاجمان بدون احراز هویت اجازه می‌دهند روی وب‌سرورهای آسیب‌پذیر کد اجرا کنند. هر دو امتیاز 9.2 در CVSS v4.0 دارند و تلاش‌هایی برای سوءاستفاده از آن‌ها در فضای واقعی اینترنت مشاهده شده است.
PHP نسخه‌های اصلاح‌شده زیر را منتشر کرده است: 8.5.12، 8.4.27، 8.3.36 و 8.2.35.
اگر سرور یا VPS خودتان را مدیریت می‌کنید، فوراً به‌روزرسانی مناسب را نصب کنید. در هاست اشتراکی یا مدیریت‌شده، از ارائه‌دهنده خود بپرسید که نسخه وصله‌شده PHP را اعمال کرده است یا نه.
CVE-2026-109618 و CVE-2026-109619 چیست؟
هر دو آسیب‌پذیری به نحوه پردازش داده‌های داخلی درخواست در PHP مربوط می‌شوند. این ضعف‌ها در خود PHP هستند، نه در افزونه، قالب یا برنامه‌ای مشخص.
آسیب‌پذیری CVE-2026-109618 به شرایط کمبود حافظه (out-of-memory) مربوط است که می‌تواند PHP را وقتی داده‌های درخواست فقط تا حدی مقداردهی شده‌اند متوقف کند. سپس فرایند پاک‌سازی PHP ممکن است این داده‌های ناقص را معتبر فرض کند و باعث خرابی حافظه و در نهایت اجرای کد از راه دور شود.
آسیب‌پذیری CVE-2026-109619 به وضعیت داخلی منسوخ‌شده مربوط است. یک پردازشگر (worker) PHP ممکن است پس از آزاد شدن حافظه، همچنان ارجاعی به داده‌های درخواست نگه دارد. درخواست بعدی که توسط همان worker پردازش می‌شود، می‌تواند پیش از بازنشانی PHP به این اطلاعات کهنه دسترسی پیدا کند و این موضوع ممکن است به افشای اطلاعات یا اجرای کد از راه دور منجر شود.
همه نصب‌های PHP که درخواست‌های وب را پاسخ می‌دهند باید بالقوه در معرض خطر در نظر گرفته شوند؛ از جمله PHP-FPM، آپاچی با mod_php، php-cgi، FrankenPHP و LiteSpeed. به گفته PHP، بیشترین ریسک مربوط به mod_php است، چون یک درخواست بدون احراز هویت می‌تواند پیش از اجرای کد برنامه، اکسپلویت اثبات‌شده را فعال کند.
به‌روزرسانی CMS، افزونه‌ها، قالب‌ها یا کد برنامه این آسیب‌پذیری‌ها را برطرف نمی‌کند. باید نسخه وصله‌شده PHP روی سرور اجرا شود.
آیا PHP2Shell در فضای واقعی مورد سوءاستفاده قرار گرفته است؟
بله. کد اثبات مفهوم (PoC) پیش از انتشار اصلاحیه‌های رسمی منتشر شد و چند شرکت امنیتی از تلاش برای سوءاستفاده خبر داده‌اند.
شرکت Hadrian اعلام کرد: «اکنون مشاهده می‌کنیم که php2shell در مقیاس گسترده در فضای واقعی مورد سوءاستفاده قرار می‌گیرد.»
Hadrian افزود بیشتر فعالیت‌های مشاهده‌شده از مسیر آپلود پیشرفت نشست (session upload-progress) در PHP سوءاستفاده می‌کردند و هشدار داد احتمالاً مسیرهای حمله بیشتری ظاهر خواهند شد. WatchTowr، Patchstack، Cloudflare و Vega نیز فعالیت یا تلاش‌های مخرب مرتبط با این آسیب‌پذیری‌ها را گزارش کرده‌اند.
هر تلاش لزوماً به نفوذ موفق نمی‌انجامد، اما حجم فعالیت‌ها و در دسترس بودن ابزارهای اکسپلویت عمومی، وصله سریع را ضروری می‌کند. مدیران باید سرورها را از نظر فایل‌های PHP ناشناس، وظایف زمان‌بندی‌شده غیرمنتظره، حساب‌های مدیریتی ناشناخته، اتصالات خروجی مشکوک و درخواست‌های غیرعادی مرتبط با آپلود بررسی کنند.
چگونه PHP را به‌روزرسانی کنم؟
این مراحل را در اولویت قرار دهید:
- یکی از نسخه‌های PHP 8.5.12، 8.4.27، 8.3.36 یا 8.2.35 را با سیستم‌عامل، کنترل پنل هاست، ارائه‌دهنده بسته یا روش استقرار معمول خود نصب کنید.
- در صورت نیاز، workerهای PHP و سرویس‌های مرتبط را ری‌استارت یا ریلود کنید تا از نسخه وصله‌شده استفاده کنند.
- نسخه PHP را که واقعاً وب‌سایت زنده با آن اجرا می‌شود بررسی کنید. نسخه‌ای که دستور php -v در خط فرمان نشان می‌دهد ممکن است با نسخه مورد استفاده وب‌سرور متفاوت باشد.
- عملکردهای حیاتی مانند ورود به سایت، پرداخت، فرم‌ها، آپلود، وظایف زمان‌بندی‌شده، APIها و صفحات مدیریتی را آزمایش کنید.
در هاست اشتراکی، کنترل پنل را برای انتخاب نسخه PHP بررسی کنید. اگر نسخه وصله‌شده در دسترس نیست، با ارائه‌دهنده تماس بگیرید و بپرسید آیا اصلاحیه backport شده را اعمال کرده یا چه زمانی نسخه اصلاح‌شده در دسترس خواهد دی بلاگ بود.
درباره PHP 8.1 و نسخه‌های قدیمی‌تر چه باید کرد؟
PHP 8.1 و نسخه‌های قدیمی‌تر خارج از چرخه پشتیبانی عادی پروژه هستند و نسخه‌های به‌روزرسانی استاندارد دریافت نمی‌کنند. با این حال، به دلیل شدت این آسیب‌پذیری‌ها، PHP برای نسخه‌های 7.4، 8.0 و 8.1 backport اضطراری سورس منتشر کرده است. توزیع‌های لینوکس و ارائه‌دهندگان پشتیبانی بلندمدت (LTS) نیز ممکن است بسته‌های وصله‌شده ارائه دهند.
باز هم باید یک نسخه وصله‌شده PHP نصب کنید؛ یعنی ارتقا به نسخه پشتیبانی‌شده، نصب بسته‌ای که صراحتاً وصله شده از سوی سیستم‌عامل یا ارائه‌دهنده LTS، یا اعمال backport اضطراری سورس در صورت لزوم.
فقط با تکیه بر شماره نسخه نمایش‌داده‌شده فرض نکنید نصب قدیمی شما ایمن است. گاهی فروشندگان اصلاحیه‌های امنیتی را بدون تغییر شاخه PHP backport می‌کنند. مطمئن شوید بسته مورد نظر به‌طور مشخص هر دو آسیب‌پذیری CVE-2026-109618 و CVE-2026-109619 را پوشش می‌دهد.
این backportها اصلاحیه‌های اضطراری‌اند و به معنای بازگشت پشتیبانی بلندمدت نیستند. مهاجرت به شاخه پشتیبانی‌شده PHP همچنان گزینه ایمن‌تر در بلندمدت است.
فایروال Sucuri (WAF) چه کمکی می‌کند؟
قوانین موجود WAF شرکت Sucuri پیش‌تر بخشی از الگوهای درخواست مخرب مرتبط با این آسیب‌پذیری‌ها را مسدود می‌کردند. اکنون قوانین دقیق‌تری برای وصله مجازی (virtual patching) اضافه شده تا محافظت در برابر مسیرهای شناخته‌شده اکسپلویت PHP2Shell در کل شبکه WAF بهتر شود.
این قوانین برای شناسایی و مسدود کردن درخواست‌های اکسپلویت شناخته‌شده پیش از رسیدن به محیط اجرای آسیب‌پذیر PHP طراحی شده‌اند. با تغییر روش مهاجمان و پیدایش مسیرهای جدید، پایش ترافیک حمله و بهبود پوشش ادامه خواهد داشت.
مزیت مهم وصله مجازی این است که مشتریان می‌توانند تا زمان تکمیل به‌روزرسانی توسط مدیران سرور و ارائه‌دهندگان هاست، یک لایه محافظتی فوری داشته باشند.
با این حال، WAF جایگزین وصله نیست. فایروال درخواست‌های مخربی را که تشخیص دهد مسدود می‌کند، اما نسخه وصله‌شده PHP رفتار آسیب‌پذیر را از بین می‌برد. صاحبان وب‌سایت باید از هر دو استفاده کنند.
پیشگیری از دور زدن فایروال: اجازه ندهید مهاجمان لایه محافظتی شما را دور بزنند
محافظت WAF فقط زمانی کار می‌کند که درخواست‌ها از فایروال عبور کنند. اگر مهاجمان بتوانند مستقیماً به سرور مبدأ متصل شوند، ممکن است قوانین وصله مجازی را دور بزنند و ترافیک اکسپلویت را مستقیم به PHP بفرستند.
راهنمای پیشگیری از دور زدن فایروال را دنبال کنید و موارد زیر را بررسی کنید:
- دسترسی مستقیم IPv4 و IPv6 به سرور مبدأ محدود شده باشد.
- سرور مبدأ فقط ترافیک وب را از آدرس‌های تأییدشده فایروال Sucuri بپذیرد.
- نام‌های میزبان جایگزین و رکوردهای DNS قدیمی، سرور مبدأ را آشکار نکنند.
- محیط‌های staging، توسعه، تست
