PHP2Shell چیست؟ بررسی خطاهای حافظهٔ PHP در اکتبر ۲۰۲۶

تیم PHP در ۲۱ اکتبر ۲۰۲۶ دو نقص مهم را با شناسه‌های CVE-2026-109618 و CVE-2026-109619 اعلام کرد. موضوع، رفتار داخلی runtime در مسیرهای خطا و پاک‌سازی حافظه است؛ نه صرفاً یک فرم ناامن یا یک افزونهٔ خاص. این مطلب آموزشی و دفاعی است و مراحل ساخت اکسپلویت را ارائه نمی‌کند.

برای تصمیم عملیاتی، اطلاعات همین صفحه را با اطلاعیهٔ فروشنده و بستهٔ توزیع خود تطبیق دهید. نسخه‌های پایین‌تر ممکن است وصلهٔ backport داشته باشند؛ شمارهٔ نسخهٔ ظاهری به‌تنهایی همیشه کافی نیست. تاریخ بررسی این نوشته ۲۵ اکتبر ۲۰۲۶ است.

CVE-2026-109618: خطای کمبود حافظه می‌تواند مقداردهی داخلی دادهٔ درخواست را نیمه‌کاره قطع کند. سپس مرحلهٔ پاک‌سازی ممکن است دادهٔ نامعتبر را معتبر فرض کند؛ در نتیجه مرز ایمنی حافظه شکسته می‌شود.

CVE-2026-109619: بعضی وضعیت‌های سراسری به حافظهٔ متعلق به درخواست اشاره می‌کنند. اگر آن حافظه آزاد شود و اشاره‌گر باقی بماند، درخواست بعدیِ همان worker ممکن است به وضعیت قدیمی دست بزند. مفهوم کلیدی، طول عمر متفاوت «درخواست» و «worker» است؛ یک خطای درخواست می‌تواند روی درخواست بعدی اثر بگذارد.

PHP در اطلاعیه، نصب‌های پاسخ‌دهنده به وب مانند FPM و mod_php را در دامنهٔ بررسی قرار داده است. برای شاخه‌های قدیمیِ پایان‌پشتیبانی، وضعیت بستهٔ توزیع یا ارائه‌دهندهٔ LTS را مستقیماً بررسی کنید و مسیر ارتقا داشته باشید.

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

php -v
php --ini
# نسخهٔ CLI را با runtime واقعی سرویس وب تطبیق دهید.

اطلاعیهٔ تکمیلی PHP پیشنهاد می‌کند تا انتشار اصلاح بعدی، session.upload_progress.enabled=0 در نظر گرفته شود. این نکته به ترکیب خاصی از تنظیمات و تغییر runtime مربوط است. تنظیم را با نیاز برنامه و اطلاعیهٔ رسمی تطبیق دهید و اعمال شدن آن در workerهای وب را بررسی کنید؛ یک تغییر در CLI یا ini_set دیرهنگام لزوماً همان اثر را ندارد.

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