کارشناسان یکی دیگر از باگ های بزرگ PHP2Shell را فاش می کنند – و این بار یک پچ اضطراری دریافت نمی کند

PHP یک آسیب‌پذیری جدید RCE را فاش کرد، اما بهره‌برداری به یک پیکربندی نادر و خاص نیاز دارد.

برخلاف php2shell، این نقص در نسخه معمولی بعدی به جای یک پچ اضطراری برطرف خواهد شد

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

این سازمان اخیرا یک هشدار امنیتی جدید به کاربران درباره یک اشکال پیشرفت آپلود جلسه در PHP منتشر کرده است که با نام CVE-2026-115560 ردیابی می شود. در این مشاوره، این سازمان گفت که این باگ تنها می‌تواند «تحت ترکیب غیرمعمولی از پیکربندی و کد برنامه» مورد سوء استفاده قرار گیرد.

"یک برنامه باید session.serialize_handler را در پیکربندی خود روی php_binary یا php_serialize تنظیم کند و سپس آن را در زمان اجرا با ini_set() قبل از فراخوانی session_start() به php تغییر دهد. پیشرفت آپلود جلسه نیز باید همچنان فعال باشد. برنامه هایی که هرگز کنترل کننده سریال سازی را در زمان اجرا تغییر نمی دهند، می توانند این ویژگی را en.

بنابراین، مگر اینکه تنظیمات شما دقیقا این تنظیمات را داشته باشد، در خطر نیستید. تیم امنیتی PHP همچنین به کاربران پیشنهاد می‌کند تا session.upload_progress.enabled=0 را تا نسخه رفع اشکال بعدی بعدی تنظیم کنند تا به طور کامل از این بردار RCE محافظت کنند، که آنها آن را "بعید" توضیح دادند. آنها همچنین گفتند که این تنظیم به عنوان یک کاهش برای CVE-2026-109619 ذکر شده است، بنابراین کاربرانی که آن را اعمال کرده اند باید آن را حفظ کنند و هیچ کار دیگری انجام ندهند.

PHP2Shell

CVE-2026-109619 یکی از دو آسیب‌پذیری RCE با شدت بحرانی است که اخیرا کشف شده و «php2shell» نامیده شده است، که کشف آن باعث وحشت گسترده‌ای شد، زیرا پیامدهای آن، به بیان خفیف، چشمگیر بودند.

PHP یک زبان برنامه نویسی بسیار محبوب است که برای ساخت وب سایت ها و برنامه های وب استفاده می شود. برخی از تحلیلگران ادعا می کنند که تقریبا 70٪ از تمام وب سایت های موجود در اینترنت دارای PHP هستند، از جمله سایت های بانکی، آموزشی، بهداشت و درمان و سایت های دولتی. فاش شد که تیم امنیتی PHP در حال کار بر روی یک اصلاح برای php2shell بود و تعداد انگشت شماری از سازمان های امنیتی می دانستند یا در این کار دخیل بودند. باگ ها به عوامل تهدید اجازه می دادند تا کنترل کامل وب سایت ها را در دست بگیرند.

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

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

تیم امنیتی PHP سعی کرد با صدور یک هشدار "heads up" آسیب را کاهش دهد - به تیم‌های فناوری اطلاعات می‌گفت که آماده شوند و منتظر بمانند که برای 21 اکتبر برنامه ریزی شده بود.

ذخیره شده توسط ASLR

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

همانطور که مشخص است - بهره برداری از php2shell آنقدرها هم که به نظر می رسد آسان نیست، احتمالا به لطف قابلیتی به نام Address Space Layout Randomization (ASLR). این ویژگی امنیتی به طور تصادفی جایی که کد و داده های برنامه در هر بار اجرا در حافظه ذخیره می شود تغییر می کند و ظاهرا شرایط را برای مهاجمان پیچیده می کند:

Yotam Perkal، مدیر تحقیقات امنیتی در Pluto Security گفت: "PHP2Shell برای بهره برداری بی اهمیت به نظر نمی رسد. من معتقدم بخشی از دلیلی که ما هنوز شاهد بهره برداری موفقیت آمیز نبوده ایم این است که اجرای کد قابل اعتماد نیاز به پشت سر گذاشتن ASLR دارد، یک حفاظت از حافظه که مکان هایی را که کد در حافظه قرار می گیرد تصادفی می کند." انجام این کار از راه دور سخت است، و اکثر PoC های عمومی که در اطراف شناور هستند (بسیاری از آنها با کدهای Vibe) به سادگی روی سیستم های واقعی کار نمی کنند.

این خبر خوبی است، اما پرکال معتقد است بهترین کاری که ASLR می‌تواند انجام دهد این است که تیم‌های امنیتی را کمی زمان بخرد: "هرچند من روی ماندن آن حساب نمی‌کنم. اکسپلویت‌ها بهتر می‌شوند و اکثر سرورهای PHP موجود در آنجا هنوز وصله‌نشده هستند، بنابراین تیم‌ها باید کارگران PHP خود را هم‌اکنون وصله و راه‌اندازی مجدد کنند. اما در مقایسه با تمام درام‌ها قبل و بعد از انتشار، بسیار محدود به نظر می‌رسد."

از طریق Bleeping Computer