آسیب‌پذیری بحرانی PHP2Shell

مقدمه

در اکتبر ۲۰۲۶، افشای دو آسیب‌پذیری امنیتی بحرانی در هسته PHP با نام مشترک PHP2Shell توجه جامعه امنیت سایبری را به خود جلب کرد. این آسیب‌پذیری‌ها با شناسه‌های CVE-2026-109618 و CVE-2026-109619 ثبت شده‌اند و می‌توانند در شرایط مناسب، امکان اجرای کد از راه دور (Remote Code Execution یا RCE) را برای مهاجم بدون نیاز به احراز هویت فراهم کنند.

اهمیت این رخداد در آن است که مشکل صرفاً به یک افزونه، سامانه مدیریت محتوا یا فریم‌ورک خاص محدود نمی‌شود؛ بلکه به نحوه مدیریت درخواست‌های HTTP و حافظه در موتور PHP مربوط است. به همین دلیل، بسیاری از وب‌سرورها و برنامه‌های مبتنی بر PHP ممکن است در معرض خطر قرار گیرند. آژانس امنیت سایبری سنگاپور نیز در هشدار خود در ۲۱ اکتبر ۲۰۲۶، این دو نقص را بحرانی ارزیابی کرد و در به‌روزرسانی ۲۳ اکتبر، از ادامه تلاش‌های گسترده برای بهره‌برداری از آن‌ها خبر داد.

PHP2Shell چیست و چرا اهمیت دارد؟

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

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

عبارت «بدون نیاز به ورود» به این معناست که مهاجم برای آغاز حمله لزوماً به نام کاربری، گذرواژه یا حساب معتبر نیاز ندارد. البته این موضوع به معنای موفقیت قطعی حمله روی هر سرور آسیب‌پذیر نیست؛ قابلیت بهره‌برداری به نسخه PHP، پیکربندی سرور، شیوه پردازش درخواست‌ها و شرایط اجرایی بستگی دارد.

جزئیات فنی دو آسیب‌پذیری

۱. آسیب‌پذیری CVE-2026-109618؛ خرابی حافظه هنگام اتمام حافظه

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

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

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

۲. آسیب‌پذیری CVE-2026-109619؛ استفاده از حافظه آزادشده

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

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

یکی از مسیرهای تأییدشده مرتبط با این آسیب‌پذیری به قابلیت ثبت پیشرفت بارگذاری نشست‌ها (Session Upload Progress) مربوط است. در صورت فراهم بودن شرایط لازم، سوءاستفاده از این وضعیت می‌تواند به اجرای کد از راه دور منجر شود.

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

چه سرورهایی در معرض خطر هستند؟

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

- Apache با mod_php: در ارزیابی‌های منتشرشده، این شیوه اجرا از پرخطرترین حالت‌ها محسوب می‌شود.

- PHP-FPM: این روش نیز باید بررسی شود؛ امکان و شرایط بهره‌برداری به نسخه، پیکربندی و مسیر پردازش درخواست بستگی دارد.

- php-cgi: نصب‌هایی که از این روش برای اجرای PHP استفاده می‌کنند نیز باید ارزیابی شوند.

- FrankenPHP و LiteSpeed: این محیط‌ها نیز در هشدارهای امنیتی به‌عنوان محیط‌های بالقوه آسیب‌پذیر مطرح شده‌اند.

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

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

شدت خطر و پیامدهای احتمالی

هر دو آسیب‌پذیری بر اساس معیار CVSS نسخه ۴، امتیاز ۹٫۲ از ۱۰ دریافت کرده‌اند؛ امتیازی که نشان‌دهنده شدت بسیار بالای خطر است. همچنین، گزارش‌هایی درباره تلاش‌های گسترده برای بهره‌برداری از این نقص‌ها منتشر شده است. <Cite refs={["turn323344search2","turn323344search3"]}/>

در صورت بهره‌برداری موفق، پیامدهای احتمالی عبارت‌اند از:

- اجرای کد دلخواه: اجرای دستورات یا کدهای مخرب با سطح دسترسی فرایند PHP.

- سرقت اطلاعات: دسترسی احتمالی به اطلاعات برنامه، فایل‌های پیکربندی و داده‌های حساس در دسترس حساب سرویس.

- تغییر محتوای وب‌سایت: دست‌کاری فایل‌ها، قراردادن درِ پشتی یا ایجاد وب‌شل در صورت برخورداری از دسترسی لازم.

- اختلال در سرویس: از کار افتادن فرایندهای PHP، افزایش مصرف منابع یا ایجاد اختلال در دسترس‌پذیری وب‌سایت.

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

باید توجه داشت که اجرای کد با دسترسی فرایند PHP لزوماً به معنای دسترسی مستقیم به کاربر ریشه (Root) یا کنترل کامل سیستم‌عامل نیست. میزان خسارت به سطح دسترسی حساب سرویس، جداسازی محیط اجرا و کنترل‌های امنیتی دیگر بستگی دارد.

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

مهم‌ترین اقدام دفاعی، نصب نسخه اصلاح‌شده PHP است. تنظیمات موقت، فایروال یا سامانه تشخیص نفوذ می‌توانند بخشی از خطر را کاهش دهند، اما جایگزین نصب وصله امنیتی نیستند. <Cite refs={["turn323344search1","turn323344search2"]}/>

۱. به‌روزرسانی فوری 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

این شماره‌ها حداقل نسخه‌های اصلاح‌شده برای شاخه‌های یادشده هستند؛ در زمان اجرا باید جدیدترین نسخه امن و پشتیبانی‌شده متناسب با محیط خود را نصب کنید.

برای بررسی نسخه PHP در محیط خط فرمان می‌توان از دستور زیر استفاده کرد:

php -v

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

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

۲. بررسی نسخه‌های قدیمی و پایان‌یافته

نسخه‌های PHP 8.1 و قدیمی‌تر باید با دقت بیشتری بررسی شوند؛ زیرا این شاخه‌ها دیگر از پشتیبانی عادی پروژه PHP برخوردار نیستند. بعضی توزیع‌های لینوکس و ارائه‌دهندگان پشتیبانی بلندمدت ممکن است اصلاحیه‌های بازگردانده‌شده به نسخه‌های قدیمی‌تر (Backport) را ارائه کنند.

در چنین شرایطی، صرف مشاهده شماره نسخه برای تشخیص نصب بودن وصله کافی نیست. مدیر سامانه باید اطلاعیه رسمی توزیع یا فروشنده را بررسی کند و در صورت نبود اصلاحیه معتبر، ارتقا به نسخه پشتیبانی‌شده یا محدودکردن دسترسی سامانه را در اولویت قرار دهد. <Cite refs={["turn323344search0","turn323344search1"]}/>

۳. اعمال اقدامات موقت کاهش خطر

اگر نصب وصله فوراً امکان‌پذیر نیست، توصیه‌های موقت تیم PHP شامل غیرفعال‌کردن قابلیت Session Upload Progress در صورت عدم نیاز، بازبینی محدودیت اندازه درخواست‌ها و اعمال کنترل‌های مناسب بر تعداد بخش‌های درخواست چندبخشی است.

برای نمونه، تنظیم زیر می‌تواند مسیر تأییدشده مرتبط با آسیب‌پذیری دوم را محدود کند:

session.upload_progress.enabled = 0

این تنظیم باید در سطحی اعمال شود که پیش از پردازش درخواست مؤثر باشد؛ سپس فرایندهای PHP باید راه‌اندازی مجدد شوند. اعمال آن در کد برنامه پس از آغاز پردازش درخواست، لزوماً برای جلوگیری از این مسیر حمله کافی نیست.

همچنین، محدودکردن اندازه درخواست‌ها در وب‌سرور یا پراکسی می‌تواند به کاهش مواجهه با برخی ورودی‌های مخرب کمک کند. با این حال، هیچ‌یک از این اقدامات به‌تنهایی سامانه را به‌طور کامل ایمن نمی‌کند و نباید به‌عنوان جایگزین به‌روزرسانی تلقی شود. <Cite refs={["turn323344search1","turn323344search0"]}/>

شناسایی نشانه‌های احتمالی نفوذ

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

موارد زیر می‌توانند در بررسی رخداد امنیتی مفید باشند:

- افزایش غیرعادی خطاهای اتمام حافظه یا توقف ناگهانی فرایندهای PHP.

- درخواست‌های HTTP چندبخشی غیرعادی، به‌ویژه درخواست‌هایی که باعث بروز خطاهای تکراری در پردازش ورودی می‌شوند.

- اجرای فرایندهای فرزند غیرمنتظره از سوی PHP یا وب‌سرور.

- ایجاد یا تغییر غیرمجاز فایل‌های PHP در پوشه‌های وب‌سایت.

- اضافه‌شدن وظایف زمان‌بندی‌شده، حساب‌های کاربری یا فایل‌های ناشناس.

- ارتباطات خروجی غیرمعمول از سرور به مقصدهای ناشناخته.

هیچ‌یک از این نشانه‌ها به‌تنهایی اثبات‌کننده بهره‌برداری از PHP2Shell نیست؛ بررسی هم‌زمان گزارش‌های وب‌سرور، PHP، سامانه تشخیص نقطه پایانی و تغییرات فایل‌ها می‌تواند تصویر دقیق‌تری ارائه دهد.

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

جمع‌بندی

PHP2Shell نمونه‌ای مهم از این واقعیت است که آسیب‌پذیری در لایه زیرساخت می‌تواند بسیاری از برنامه‌ها را بدون توجه به نوع فریم‌ورک یا منطق تجاری آن‌ها در معرض خطر قرار دهد. دو نقص CVE-2026-109618 و CVE-2026-109619 با سوءاستفاده از مدیریت نادرست حافظه در PHP، امکان اجرای کد از راه دور را در شرایط مشخص فراهم می‌کنند؛ آن هم بدون الزام به احراز هویت.

برای مدیران سرور، تیم‌های DevOps و متخصصان امنیت، مسیر مقابله روشن است: شناسایی تمام نصب‌های PHP، اولویت‌دادن به سامانه‌های در معرض اینترنت، نصب نسخه‌های اصلاح‌شده، راه‌اندازی مجدد سرویس‌ها و بررسی احتمال نفوذ پیشین.

در چنین رخدادهایی، سرعت واکنش اهمیت زیادی دارد؛ اما واکنش مؤثر فقط به نصب وصله محدود نمی‌شود. ترکیب به‌روزرسانی، پایش مستمر، محدودسازی دسترسی‌ها و بررسی شواهد نفوذ، رویکردی ضروری برای کاهش خطر PHP2Shell است.

منابع و مراجع

۱. "آژانس امنیت سایبری سنگاپور — هشدار رسمی PHP2Shell" (https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-151/)

۲. "PHP — اطلاعیه امنیتی و نسخه‌های اصلاح‌شده" (https://www.php.net/archive/2026.php#2026-10-21-5)

۳. "Cloudflare — تحلیل فنی آسیب‌پذیری‌ها و اقدامات حفاظتی" (https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)

۴. "Plesk — راهنمای بررسی نسخه‌های آسیب‌پذیر و اصلاح PHP" (https://support.plesk.com/hc/en-us/articles/44397729587351-Vulnerability-CVE-2026-109618-and-CVE-2026-109619-PHP2Shell-Remote-code-execution-in-PHP-shipped-with-Plesk/)

تاریخ تهیه مقاله: ۲۴ اکتبر ۲۰۲۶. توصیه‌های عملیاتی باید با آخرین اطلاعیه‌های رسمی PHP و فروشنده سیستم‌عامل تطبیق داده شوند.