آسیب‌پذیری PHP2Shell چیست؟ آموزش شناسایی و رفع باگ بحرانی PHP

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

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

آسیب‌پذیری PHP2Shell چگونه کار می‌کند؟

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

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

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

CVE-2026-109618؛ سوءاستفاده از خطای اتمام حافظه

اولین آسیب‌پذیری با شناسه CVE-2026-109618 به نحوه مدیریت خطای اتمام حافظه مربوط است. این وضعیت با اصطلاح OOM یا Out of Memory شناخته می‌شود و زمانی رخ می‌دهد که برنامه نتواند حافظه مورد نیاز خود را تخصیص دهد.

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

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

CVE-2026-109619؛ استفاده از حافظه آزادشده

آسیب‌پذیری دوم با شناسه CVE-2026-109619 به مشکلی از نوع Use-After-Free مربوط است. این اصطلاح زمانی به کار می‌رود که برنامه پس از آزاد کردن یک بخش از حافظه، همچنان از ارجاعی استفاده کند که به همان بخش اشاره دارد.

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

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

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

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

بر اساس گزارش منتشرشده درباره PHP2Shell، این مجموعه آسیب‌پذیری‌ و تهدید‌های سایبری دامنه گسترده‌ای از نسخه‌های PHP را تحت تاثیر قرار داده است. نسخه‌های اصلاح‌شده شاخه‌های جدید PHP در ۲۱ اکتبر ۲۰۲۶ منتشر شدند.

نسخه‌های اصلاح‌شده اعلام‌شده عبارت‌اند از:

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

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

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

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

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

برای مشاهده نسخه PHP خط فرمان، دستور زیر را اجرا کنید:

 php -v 

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

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

برای مشاهده فرایندهای فعال PHP-FPM نیز می‌توانید از دستور زیر استفاده کنید:

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

اگر از Debian یا Ubuntu استفاده می‌کنید، این دستور بسته‌های PHP نصب‌شده را فهرست می‌کند:

 dpkg -l | grep -E 'php[0-9.]|php-fpm|libapache2-mod-php' 

در توزیع‌های مبتنی بر RHEL، مانند AlmaLinux و Rocky Linux، می‌توانید از دستور زیر استفاده کنید:

 rpm -qa | grep -i '^php' 

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

چگونه آسیب‌پذیری PHP2Shell را برطرف کنیم؟

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

به‌روزرسانی PHP در Debian و Ubuntu

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

 sudo apt update 

سپس بسته‌های قابل ارتقا را بررسی کنید:

 apt list --upgradable 

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

 sudo apt upgrade 

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

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

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

 sudo systemctl restart php8.4-fpm 

نام سرویس را با نسخه نصب‌شده روی سرور خود تطبیق دهید. این دستور فقط برای نمونه‌ای با PHP 8.4 است و ممکن است روی سرور شما نام دیگری داشته باشد.

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

به‌روزرسانی PHP در سرورهای دارای پنل میزبانی وب

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

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

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

اگر امکان به‌روزرسانی فوری وجود ندارد، چه کنیم؟

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

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

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

همچنین از تغییرهای غیرمستند در تنظیمات حافظه PHP خودداری کنید. برای مثال، تنظیم memory_limit روی -1 محدودیت حافظه PHP را حذف می‌کند و می‌تواند خطر مصرف بیش از حد حافظه و از دسترس خارج شدن سرور را افزایش دهد. این تغییر را نباید به‌عنوان راهکار عمومی و مطمئن برای مقابله با PHP2Shell اجرا کرد.

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

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

گزارش‌های وب‌سرور و PHP-FPM را برای درخواست‌های غیرعادی، خطاهای مکرر HTTP 500، خطاهای اتمام حافظه و توقف غیرمنتظره فرایندها بررسی کنید. ایجاد فایل‌های PHP ناشناس، تغییرات مشکوک در فایل‌های سایت، فرایندهای ناشناخته و اتصال‌های خروجی غیرمنتظره نیز می‌توانند نشانه‌های نفوذ باشند؛ هرچند هیچ‌کدام به‌تنهایی اثبات‌کننده حمله نیستند.

در سیستم‌هایی که از systemd استفاده می‌کنند، برای بررسی اولیه گزارش‌های مرتبط می‌توانید دستور زیر را اجرا کنید:

 sudo journalctl --since "2026-10-21" | grep -Ei 'php|fpm|apache|oom|segfault' 

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

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

نبود نشانه مشکوک در گزارش‌ها نیز به معنای اثبات نشدن نفوذ نیست؛ ممکن است گزارش‌ها ناقص باشند یا آثار فعالیت مهاجم از بین رفته باشند.

نقش هوش مصنوعی در کشف PHP2Shell

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

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

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

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

برای مقابله با PHP2Shell چه اقداماتی ضروری است؟

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

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

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

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