فهرست مطالب
در این پست، توضیح می‌دهیم که چگونه هوش مصنوعی مرزی به ما در یافتن و رفع آسیب‌پذیری‌هایی که بیش از یک دهه در کد PHP پنهان مانده بودند، کمک کرد. مسائلی که در زیر شرح داده شده‌اند، همگی ناشی از تصمیمات کلیدی معماری هستند که برخی از آنها بیش از یک دهه پیش گرفته شده‌اند و تحت دو CVE گروه‌بندی شده‌اند که شدت آنها به CVSS 9.2 می‌رسد. این کار به یک تلاش بین صنعتی برای محافظت از مشتریان، یافتن انواع مختلف، استقرار روش‌های تشخیص و کاهش آسیب‌پذیری و تأیید وصله به موقع برای افشای هماهنگ تبدیل شد.
تقریباً هر نسخه PHP حداقل تحت تأثیر یکی از این مشکلات قرار دارد، از جمله نسخه‌های PHP 5.4. این آسیب‌پذیری‌ها می‌توانند به مهاجمان غیرمجاز اجازه دهند تا کدی را روی سرورهای آسیب‌دیده اجرا کنند یا حافظه فرآیند حساس را بخوانند. این حافظه ممکن است حاوی رمزهای عبور، توکن‌های احراز هویت، کلیدهای API و گواهی‌های متعلق به درخواست‌های دیگر یا خود سرور باشد.
پی‌اچ‌پی زبان برنامه‌نویسی پشت بخش عمده‌ای از وب است که وردپرس، دروپال و مدیاویکی، نرم‌افزاری که ویکی‌پدیا را اجرا می‌کند، از آن پشتیبانی می‌کنند. یک نقص در موتور اصلی آن می‌تواند وب‌سایت‌های سراسر این اکوسیستم را تحت تأثیر قرار دهد، حتی زمانی که کد برنامه خودشان امن باشد.
برخی از آسیب‌پذیری‌ها به نقاط عطف تبدیل می‌شوند، زیرا فرضیات اساسی در مورد امنیت را به چالش می‌کشند. در سال ۲۰۱۴، Heartbleed شکنندگی زیرساخت‌های مشترک تأمین امنیت اینترنت را آشکار کرد. در سال ۲۰۲۱، Log4Shell نشان داد که وابستگی‌های عمیق نرم‌افزاری چگونه می‌توانند باعث افشای گسترده شوند که سازمان‌ها برای شناسایی آن تلاش می‌کردند. ما معتقدیم PHP2Shell می‌تواند نقطه عطف مشابهی برای دوران هوش مصنوعی باشد و نشان دهد که چگونه هوش مصنوعی می‌تواند قابلیت بهره‌برداری عملی از آسیب‌پذیری‌های قدیمی را تغییر دهد. ایجاد این بهره‌برداری مستلزم زنجیره‌سازی چندین نقص و تطبیق با طرح حافظه هر هدف از طریق آزمایش و اشکال‌زدایی مکرر بود. مدل‌های Frontier برای عملی کردن این فرآیند حیاتی بودند و ما را قادر ساختند تا بهره‌برداری‌های کاری را در چندین برنامه در عرض چند ساعت توسعه داده و تطبیق دهیم. با کاهش زمان و تخصص مورد نیاز برای این کار، پیچیدگی ممکن است دیگر مانع معناداری ایجاد نکند و نحوه تعریف ما از آنچه در عمل آسیب‌پذیر است را تغییر دهد.
آسیبپذیریهاتمام آسیب‌پذیری‌های افشا شده، مسائل مربوط به ایمنی حافظه هستند که از اشکالاتی در نحوه مدیریت خطاهای مهلک PHP هنگام پردازش درخواست‌ها، به ویژه خطاهای خارج از حافظه، ناشی می‌شوند. این اشکالات می‌توانند پس از پایان غیرمنتظره یک درخواست، یک وضعیت داخلی PHP خراب را به جا بگذارند. یک درخواست یا worker بعدی می‌تواند از آن وضعیت قدیمی دوباره استفاده کند و منجر به افشای حافظه یا خرابی شود.
در زیر می‌توانید جدولی را مشاهده کنید که نشان می‌دهد هر یک از اشکالات گزارش‌شده به PHP چه نوع تأثیری را نشان داده‌اند. برنامه‌های فهرست‌شده در زیر، اهدافی هستند که ما برای نمایش RCE انتخاب کرده‌ایم. آنها اهداف نمونه هستند - بهره‌برداری از این آسیب‌پذیری به هیچ‌کدام از این CMSها نیاز ندارد، زیرا کد آسیب‌پذیر در خود PHP قرار دارد.
شناسه ردیابیاشکالآنچه یک مهاجم می‌تواند به دست آوردآنچه ما نشان دادیمCVE-2026-109618
استفاده پس از آزادسازی، فرآیند آپلود و حذف سریالایزر را انجام می‌دهد
افشای حافظه-پردازش از راه دور
حافظه فرآیند را خراب کرده و کد را اجرا می‌کند
افشای غیرمجاز حافظه‌ی کارگر PHP
اجرای کد از راه دور (RCE) پیش از احراز هویت در وردپرس، دروپال و جوملا
افشای حافظه از راه دور بدون وابستگی به برنامه
CVE-2026-109619
ردیابی معکوس خطای مهلک پس از آزادسازی
سردرگمی در نوع OPcache
حافظه فرآیند را خراب کرده و کد را اجرا می‌کند
خراب شدن وضعیت مشترک PHP و اجرای کد
اجرای کد از راه دور (RCE) پیش از احراز هویت در دروپال
RCE پیش از احراز هویت در وردپرس
اگرچه این وبلاگ تنها چهار نمونه از اشکالات قابل سوءاستفاده (که تحت دو CVE گروه‌بندی شده‌اند) را که از این الگوی مشکل‌ساز پیروی می‌کنند، پوشش می‌دهد، اما انواع ردیابی‌شده و احتمالاً ردیابی‌نشده‌ی دیگری از این مشکل در کد پایه PHP وجود دارد. این انواع الزامات متفاوتی برای سوءاستفاده دارند و می‌توانند منجر به انواع مختلفی از تأثیرات شوند. در هر صورت، وصله‌ای که توسط تیم PHP ارائه شده است، مشکل را در هسته خود برطرف می‌کند و تمام انواع موجود در نسخه وصله‌شده را از بین می‌برد.
تأثیرما این آسیب‌پذیری‌ها را در یک اسکریپت بهره‌برداری واحد، php2shell، ترکیب کردیم و نشان دادیم که می‌تواند کد را از راه دور و بدون احراز هویت روی نسخه‌های وردپرس ( wordpress:latest)، دروپال ( drupal:latest) و جوملا ( joomla:latest)، با استفاده از آخرین تصاویر کانتینر آنها در زمان آزمایش، اجرا کند.
این پلتفرم‌ها تأثیر این آسیب‌پذیری را نشان می‌دهند، اما آسیب‌پذیری‌ها در خود PHP هستند. بهره‌برداری به نقص در کد برنامه بستگی ندارد: حتی یک برنامه ساده "Hello World" که روی یک نسخه PHP آسیب‌پذیر اجرا می‌شود، می‌تواند آسیب‌پذیر باشد.
به طور جداگانه، ما نشان دادیم که مهاجمان می‌توانند داده‌های حساس از حافظه فرآیند PHP، از جمله رمزهای عبور، توکن‌ها و کلیدهای API را بدون نیاز به اجرای کد از راه دور، بخوانند.
نمایش PHP2Shell با وردپرس، جوملا و دروپال:
نقطه عطف هوش مصنوعیکد آسیب‌پذیر بیش از یک دهه وجود داشت. تبدیل این نقص‌ها به سوءاستفاده‌های عملی، نیازمند زنجیره‌سازی چندین باگ و در نظر گرفتن نحوه تخصیص و استفاده مجدد PHP از حافظه در بین درخواست‌ها بود. باگ‌های حافظه به طور مشهوری پیچیده هستند؛ تفاوت در نسخه‌های PHP، پیکربندی‌ها و رفتار برنامه می‌تواند فرضیاتی را که سوءاستفاده به آنها وابسته است، نقض کند. حمله‌ای که علیه یک پیاده‌سازی کار می‌کند، ممکن است برای کار علیه دیگری نیاز به تنظیمات اساسی داشته باشد که هر کدام نیاز به تجزیه و تحلیل، آزمایش و اشکال‌زدایی بیشتر دارند. قبل از هوش مصنوعی، پیاده‌سازی این کار دستی دشوار و مقیاس‌پذیری آن حتی دشوارتر خواهد بود.
با هوش مصنوعی، این دیگر یک مانع نیست. LLMها می‌توانند به تطبیق یک اکسپلویت با نسخه‌های مختلف PHP، پیکربندی‌ها و طرح‌بندی‌های حافظه کمک کنند. با ابزارهای تست و اشکال‌زدایی، مدل‌ها می‌توانند شکست‌ها را تجزیه و تحلیل کرده و تنظیمات را تکرار کنند و تلاش متخصص مورد نیاز برای هر هدف را کاهش دهند. این امر به طور قابل توجهی مانع مقیاس‌بندی حملات در استقرارهای مختلف را کاهش می‌دهد.
این امر، اقتصاد کشف و بهره‌برداری را تغییر می‌دهد. از آنجایی که هوش مصنوعی تلاش مورد نیاز برای توسعه و تطبیق سوءاستفاده‌های پیچیده را کاهش می‌دهد، آسیب‌پذیری‌هایی که زمانی بهره‌برداری از آنها غیرممکن به نظر می‌رسید، به اهداف مناسبی تبدیل می‌شوند.
اشکال: آپلود-پیشرفت unserializer با استفاده از free-use
ماژول Session در PHP می‌تواند داده‌های session را در حین مدیریت پیشرفت آپلود در همان پنجره‌ی پیش از مقداردهی اولیه، رمزگشایی کند. این رمزگشا، حسابداریِ متعلق به درخواست را در ذخیره می‌کند BG(unserialize). یک خطای تخصیصِ مهلک می‌تواند این مسیر را قطع کند، هیپ درخواست را از بین ببرد و وضعیت سراسریِ unserializer را منتشر شده باقی بگذارد.
در درخواست بعدی که توسط همان worker مدیریت می‌شود، PHP می‌تواند حافظه‌ی بازیابی‌شده توسط مهاجم را به عنوان حسابداری unserializer زنده مصرف کند. حالت stale به یک عامل قدرتمند تخریب حافظه تبدیل می‌شود. ما آن را با افشای حافظه ترکیب کردیم تا عدم قطعیت آدرس را حذف کنیم و به اجرای کد از راه دور بدون احراز هویت در وردپرس، دروپال و جوملا دست یافتیم.
زنجیره‌های وردپرس، دروپال و جوملا نمونه‌هایی از این آسیب‌پذیری هستند. موارد اولیه‌ی زیربنایی در سطح موتور PHP وجود دارند و می‌توانند بر هر برنامه‌ی PHP که روی یک نسخه آسیب‌پذیر اجرا می‌شود، تأثیر بگذارند.
این مشکلات در زیر لایه برنامه اجرا می‌شوند، بنابراین گزارش‌های برنامه ممکن است حاوی اطلاعات کمی باشند. تا زمانی که سیستم‌ها وصله نشوند، مدافعان باید توجه ویژه‌ای به درخواست‌های چندبخشی غیرمعمول و به دنبال آن خطاهای محدودیت حافظه یا پاسخ‌های مکرر HTTP 500، PHPSESSIDکوکی‌های پاسخ غیرمنتظره بزرگ یا ناقص و ریزش کارگر PHP بدون دلیل داشته باشند. این سیگنال‌ها می‌توانند تحقیقات را هدایت کنند. اعمال به‌روزرسانی امنیتی PHP تنها راه حل کامل است.
اشکال: افشای حافظه-پردازش از راه دور
PHP درخواست‌های چندبخشی RFC1867 را در هنگام راه‌اندازی درخواست، قبل از تکمیل مقداردهی اولیه ماژول معمولی، تجزیه می‌کند. مدیریت پیشرفت آپلود جلسه می‌تواند وضعیت جلسه را در این مرحله اولیه مقداردهی اولیه کند و یک شناسه جلسه در ... منتشر کند PS(id). یک خطای کمبود حافظه می‌تواند درخواست را قبل از اتمام پاکسازی لغو کند. سپس PHP پشته درخواست را از بین می‌برد و ممکن است PS(id)به تخصیص آزاد شده اشاره کند.
یک درخواست چندبخشی بعدی که توسط همان worker مدیریت می‌شود، می‌تواند قبل از اینکه مقداردهی اولیه Session، آن اشاره‌گر را بازنشانی کند، به مسیر پاکسازی پیشرفت آپلود برسد. PHP به اشاره‌گر قدیمی و length به عنوان یک متغیر زنده اعتماد می‌کند zend_stringو محتوای heap بازیابی شده را در یک PHPSESSIDکوکی پاسخ، با استفاده از URL رمزگذاری می‌کند. این حمله حتی زمانی که برنامه هرگز فراخوانی نمی‌کند session_start()، کار می‌کند و این باعث می‌شود که این مشکل مستقل از برنامه باشد. ما افشای غیرمجاز یک ناحیه به اندازه مهاجم از حافظه worker زنده را که حاوی داده‌هایی از خارج از درخواست مهاجم است، نشان دادیم.
اشکال: ردیابی معکوس خطای مهلک در استفاده پس از آزادسازی
در نسخه‌های آسیب‌دیده، PHP ردپای آخرین خطای مهلک در را حفظ می‌کند EG(last_fatal_error_backtrace). یک خطای مهلکِ خارج از حافظه می‌تواند بدون از تعریف خارج کردن آن مقدار سراسریِ اجراکننده، هیپ درخواست را از بین ببرد. کارگر با یک سراسری که هنوز از درخواست قبلی به حافظه اشاره می‌کند، زنده می‌ماند.
اگر همان worker در اوایل درخواست بعدی یک تشخیص ارسال کند، می‌تواند قبل از اینکه اجراکننده آن حالت را دوباره مقداردهی اولیه کند، به اشاره‌گر دسترسی پیدا کند. سپس PHP backtrace معلق را از بین می‌برد یا به‌روزرسانی می‌کند و حافظه بازیابی شده توسط مهاجم را دنبال می‌کند. درخواست متقابل حاصل از use-after-free می‌تواند به تخریب کنترل‌شده حافظه تبدیل شود. ما با استفاده از این روش اولیه، اجرای کد از راه دور غیرمجاز علیه Drupal را نشان دادیم.
اشکال: سردرگمی در نوع OPcache
OPcache ساختارهای کامپایل شده PHP را در حافظه مشترک حفظ می‌کند و شاخص‌ها را به نقشه‌های اشاره‌گر زمان اجرا برای هر کارگر اختصاص می‌دهد. کارگران این شاخص‌ها را از طریق یک مرز مشترک هماهنگ می‌کنند. در طول zend_accel_script_persist()، PHP مرز محلی-فرآیند را پیش می‌برد CG(map_ptr_last). مرز مشترک مربوطه را تنها پس از تکمیل ماندگاری منتشر می‌کند. یک شکست در تخصیص بین این دو رویداد، پیشروی محلی-فرآیند را در جای خود باقی می‌گذارد و اشیاء تا حدی پایدار شده به اسلات‌هایی اشاره می‌کنند که حالت مشترک هنوز در دسترس می‌داند.
وقتی یک worker دیگر بعداً یکی از آن اسلات‌ها را برای یک شیء زمان اجرای متفاوت استفاده مجدد می‌کند، متادیتای اشتراکی قدیمی به یک اشاره‌گر از نوع اشتباه تبدیل می‌شود. این عدم تطابق باعث ایجاد سردرگمی در نوع cross-worker می‌شود و وضعیت OPcache مشترک را خراب می‌کند. ما از این اولیه برای ساخت یک زنجیره RCE احراز هویت نشده علیه وردپرس استفاده کردیم.
انواع دیگری غیر از این چهار اشکال نیز وجود دارد. در حالی که ما در ابتدا این چهار مورد را به PHP گزارش دادیم، از طریق این تحقیق متوجه شدیم که این آسیب‌پذیری عمیقاً در کدنویسی PHP ریشه دارد و نیاز به یک اصلاحیه جامع دارد. انواع دیگر نیز باید تحت همین دو CVE قرار گیرند.
نتیجهگیریبا توجه به اینکه ۷۰ درصد از اینترنت تحت تأثیر قرار گرفته است، نمی‌توان تأثیر PHP2Shell را نادیده گرفت. این یک نقطه عطف در هوش مصنوعی است. کد آسیب‌پذیر بیش از یک دهه وجود داشته است - چیزی که هوش مصنوعی تغییر داد، توانایی درک نقاط ضعف و تبدیل آنها به یک اکسپلویت کارآمد بود. با مدل‌های هوش مصنوعی پیشرو و ابزارهای مناسب، یک محقق به تنهایی در عرض یک هفته کاری را انجام داد که قبلاً ماه‌ها کار یک تیم در سطح جهانی طول می‌کشید.
این امر، هم از نظر اقتصادی و هم از نظر کشف و بهره‌برداری، تغییر ایجاد می‌کند. آسیب‌پذیری‌هایی که زمانی بهره‌برداری از آنها غیرممکن به نظر می‌رسید، به اهدافی قابل اجرا تبدیل می‌شوند. همین قابلیت‌ها به مدافعان شبکه نیز فرصتی برای کشف و رفع نقص‌هایی می‌دهند که سال‌ها از بررسی دقیق جان سالم به در برده‌اند.
ویز در طول این تحقیق از Wiz Atlas، Gemini 4 Argon و GPT-5.6 Sol استفاده کرد و آرگون سهم بسزایی در یافتن و کمک به رفع این آسیب‌پذیری داشت.
فرصت این است که این کار را به یک روال تبدیل کنیم: یافتن سیستماتیک نقص‌ها در نرم‌افزارهای موجود و شناسایی نقص‌های جدید قبل از رسیدن به مرحله تولید. تلاش‌های هماهنگ ما با PHP، OpenAI و Calif این هدف را پیش می‌برد و هوش مصنوعی را برای تقویت بنیان‌های نرم‌افزاری که همه ما به اشتراک می‌گذاریم، به کار می‌گیرد.
جدول زمانی افشای مسئولانه۱۹ آگوست ۲۰۲۶: شرکت Wiz Research با استفاده از Wiz Atlas، Gemini 4 Argon و GPT-5.6 Sol اولین آسیب‌پذیری PHP را کشف کرد.
۲۰ آگوست ۲۰۲۶: اجرای کد از راه دور غیرمجاز علیه دروپال تأیید شد.
۲۱ آگوست ۲۰۲۶: اجرای کد از راه دور احراز هویت نشده علیه وردپرس تأیید شد.
۲۴ آگوست ۲۰۲۶: شرکت Wiz Research آسیب‌پذیری‌ها را به تیم امنیتی PHP گزارش داد.
۲۱ سپتامبر ۲۰۲۶: PHP گزارش‌ها را تأیید می‌کند و شروع به توسعه‌ی یک راه‌حل هماهنگ می‌کند.
۲۱ اکتبر ۲۰۲۶: نسخه‌های پچ‌شده‌ی PHP در دسترس قرار گرفتند.
۲۱ اکتبر ۲۰۲۶: افشای عمومی.
