پی اچ پی امنیت زنجیره تامین را به خاطر قرار دادن بخش های بزرگ وب در معرض خطر مقصر می داند.

توسعه دهندگان PHP فروشگاه امنیت زنجیره تامین نرم افزار Chainguard را متهم کرده اند که به طور موثر باگ های مهم را در زبان برنامه نویسی منبع باز پیش از افشای رسمی برنامه ریزی شده آشکار می کند.

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

آنها به محققان کالیف، OpenAI و Wiz اعتبار دادند که حفره های امنیتی را بین ماه های آگوست و سپتامبر پیدا کردند. هر سه شرکت گفته‌اند که از مدل‌های هوش مصنوعی برای یافتن آسیب‌پذیری‌ها استفاده کرده‌اند، که اکنون به‌عنوان CVE-2026-109618 و CVE-2026-109619 ردیابی می‌شوند و می‌توانند به مهاجمی که احراز هویت نشده اجازه اجرای کد را روی سرورهایی که PHP دارند، بدهند.

این امر به ویژه جدی است زیرا PHP بخش های عظیمی از وب عمومی را تامین می کند. همچنین طعنه‌ای به بخش «نشت و افشای مختل‌شده» وبلاگ اضافه می‌کند که Chainguard - شرکتی که قصد دارد زنجیره‌های تامین نرم‌افزار را با سخت‌کردن کد منبع باز ایمن کند - را برای افشای نامرتب مقصر می‌داند.

به گفته توسعه‌دهندگان PHP، مشکل از روز سه‌شنبه حدود ساعت 15:00 UTC آغاز شد، زمانی که «دو شناسه CVE در انجمن‌های آنلاین و رسانه‌های اجتماعی به‌همراه اطلاعات نادرست درباره زمان انتشار و رتبه‌بندی شدت CVSS شروع به گردش کردند». در آن مرحله، هیچ جزئیات فنی به بیرون درز نکرد.

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

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

به گفته ما، چند ساعت بعد، کالیف "به اشتباه" ویدیویی را منتشر کرد که در آن یک سوء استفاده اثبات مفهوم و اطلاعات "اضافی، هرچند محدود" در مورد باگ ها نشان داده شد.

وبلاگ PHP می‌گوید: «ممکن است توصیه‌های کاهشی که در حدود 20 اکتبر ساعت 23:00 UTC به چند ارائه‌دهنده زیرساخت‌های حیاتی ارائه می‌کردیم نیز فاش شده باشد،» اما نامی از این ارائه‌دهندگان نمی‌برد. و سپس Chainguard را به زیر اتوبوس می اندازد:

"در 21 اکتبر در ساعت 07:41 UTC، بیش از شش ساعت قبل از انتشار هماهنگ شده، Chainguard به طور یکجانبه تحریم را شکست و تصاویر ساخته شده حاوی اصلاح را منتشر کرد. مانند سایر توزیع کنندگان، Chainguard وصله را از قبل دریافت کرده بود تا کاربرانش بتوانند لحظه افشای آسیب پذیری ها را به روز کنند. هر مهاجمی که در PH منتظر انتشار بود، اکنون می تواند در حال بررسی از طریق binP باشد تا رفع شود. هفته‌ها کار بسیاری از طرف‌ها برای افشای هماهنگ نادیده گرفته شد.»

مدیر عامل Chainguard: ما تماس گرفتیم

مدیر عامل Chainguard، Dan Lorenc، روز چهارشنبه با The Register صحبت کرد، و اگرچه او در مورد جدول زمانی بحثی ندارد، گفت که شرکت او "نشت افشانی نکرده است."

لورنک گفت: «این چیزها به هم ریخته است.

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

لورنک در پست بعدی لینکدین نوشت: تنها چیزی که لازم بود یک «پیشنهاد اساسی برای یافتن آسیب‌پذیری‌های بد در PHP» بود.

روز شنبه، Chainguard شروع به کار با نگهبانان PHP کرد، تأیید کرد که برخی از یافته‌های آن با گزارش‌های باگ مطابقت دارد و به آزمایش وصله‌ها کمک کرد.

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

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

لورنک گفت: «مردم از قبل تحت تأثیر افشای رسمی PHP قرار می‌گرفتند، بنابراین ما تماس گرفتیم تا رفع‌های مربوط به آن را ارسال کنیم». "این افشای آسیب پذیری هماهنگ است، مگر اینکه شواهدی از سوء استفاده های فعال در طبیعت وجود داشته باشد."

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

وقتی از او پرسیده شد که با توجه به پیامدهای افشای اولیه Chainguard، آیا او کاری متفاوت انجام می دهد، لورنک گفت: نه. او گفت: «این روند و سیاست مبتنی بر تلاش برای هماهنگی هرچه بیشتر است تا زمانی که هوا به هواداران بیفتد و مردم شروع به سلاح‌سازی کنند.» بد است، زیرا ما واقعا همه در یک تیم هستیم و افراد بدی در آنجا کار می کنند.

لورنک افزود: هانی پات های Chainguard آی پی های چین و روسیه را به دام انداختند که آسیب پذیری ها را در روز چهارشنبه هدف قرار دادند.

او به ما گفت: «فقط گفتن یک آسیب پذیری در یک نرم افزار - حتی چیزی به بزرگی PHP - برای یافتن آن کافی است. "من خودم این کار را بدون اطلاع دیگری در روز جمعه انجام دادم."

"من فکر می کنم این یک نوع عادی جدید است. مردم می توانند در چند ساعت یک اکسپلویت بسازند بدون اینکه حتی بدانند آسیب پذیری چیست."

آنچه در مورد CVE ها و نحوه بهره برداری از آنها می دانیم

در حالی که ما هنوز دامنه بهره برداری را نمی دانیم - یا نمی دانیم چه اتفاقی برای سیستم های قدیمی آسیب پذیری می افتد که راه حل های امنیتی ندارند - شکارچیان تهدید پیش بینی می کنند که این موضوع بسیار خطرناک خواهد بود.

Sagi Tzadik، Shir Tamari، Nir Ohfeld و Tomer Schwartz، محققین Wiz، روز چهارشنبه هشدار دادند: «استثمار موفقیت‌آمیز می‌تواند به مهاجمان اجازه دهد تا کنترل سرورهای آسیب‌دیده را در دست بگیرند، داده‌های حساس را سرقت کنند و وب‌سایت‌های در حال اجرا بر روی آن‌ها را تخریب کنند».

بچه‌های Wiz نوشت: «هر نسخه PHP منتشر شده در دهه گذشته حداقل تحت تأثیر یکی از این آسیب‌پذیری‌ها قرار می‌گیرد که به نسخه 5.4 برمی‌گردد. مهاجمان می توانند از راه دور از آنها سوء استفاده کنند، در برخی موارد نسبتا آسان. اصلاح فوری به شدت توصیه می شود.

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

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

CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) از طریق خرابی خارج از حافظه به RCE منجر می شود. نگهدارنده پروژه نوشت: "اگر درخواستی دقیقا در لحظه اشتباه به حافظه_limit PHP برسد، PHP می تواند داده های داخلی نیمه اولیه را پشت سر بگذارد و بعدا آن را به عنوان حافظه معتبر و مخرب تلقی کند." «در آپاچی با mod_php، یک درخواست احراز هویت نشده می‌تواند این را قبل از اجرای کد برنامه‌ای فعال کند.»

CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) به RCE از طریق حالت بیات اجازه می دهد. به گفته بنیاد PGP، "یک خطای مرگبار در نقطه اشتباه می تواند حالت داخلی را به حافظه ای که متعلق به درخواست قبلی است، نشان دهد." "یک درخواست بعدی که توسط همان کارگر انجام می شود می تواند از آن حافظه آزاد شده استفاده کند. خرابی پس از استفاده رایگان و کارگر تایید شد و گزارشگر اجرای کد از راه دور را در برابر یک برنامه واقعی در حال اجرا بر روی Apache با mod_php نشان داد."®