منابع از 22 اکتبر 2026 بررسی شدند. Aمخاطب: اپراتورهای برنامه PHP، پاسخ دهندگان امنیتی و مهندسانی که ساخت‌های سفارشی PHP را حفظ می‌کنند.

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

TL;DR: مراحل و پیشنهادات تعمیر

  1. PHP زمان اجرا را ارتقا دهید: شاخه مربوطه را به حداقل 8.2.35، 8.3.36، 8.4.27 ارتقا دهید 8.5.12. برای بسته‌های توزیع، از نسخه بسته کاملی استفاده کنید که فروشنده تأیید می‌کند هر دو CVE را برطرف می‌کند. S1S10
  2. جایگزینی همه فرآیندهای قدیمی: پس از ارتقا، هر PHP worker، سرویس میزبانی و کانتینر را مجددا راه اندازی یا جابجا کنید و تأیید کنید که نمونه های قدیمی خارج شده اند.
  3. از طریق مسیر درخواست واقعی Web تأیید کنید: Web SAPI، نسخه بسته کامل و نمونه در حال اجرا را بررسی کنید. بررسی php -v به تنهایی ثابت نمی کند که سرویس زنده ثابت است.
  4. بررسی های رگرسیون کسب و کار را اجرا کنید و بودجه های منابع عادی را بازیابی کنید: تست ورود به سیستم، مدیریت جلسه، آپلود، واردات و مدیریت خطا. اگر محدودیت حافظه PHP به طور موقت حذف شد، پس از وصله کردن، یک بودجه محدود مناسب را بازیابی کنید.
  5. اگر ارتقاء فوری غیرممکن است: ترافیک غیرقابل اعتماد را قبل از رسیدن به PHP محدود کنید. غیرفعال کردن پیشرفت آپلود و بک ردیابی های مرگبار PHP 8.5 را همانطور که در بخش 5 توضیح داده شد، ارزیابی کنید. اقدامات کاهشی پیکربندی و قوانین WAF پوشش محدودی دارند و نمی توانند جایگزین ارتقاء شوند. S1S2S3

1. بررسی اجمالی آسیب پذیری و قضاوت ریسک

PHP2Shell در این مقاله به دو اشاره شده است Critical آسیب پذیری های سطح رسما توسط PHP در 21 اکتبر 2026. هر دو مربوط به حافظه و مدیریت چرخه عمر درخواست هستند PHP موتور، خطر اجرای کد از راه دور تایید نشده را به همراه دارد. S1 S2 S3

پروژهCVE-2026-109618CVE-2026-109619
نام رسمیRCE via OOM corruptionRCE via stale global state
مسائل اصلیحافظه ناکافی باعث پرش غیرعادی می شود و حالتی باقی می ماند که هنوز مقداردهی اولیه را کامل نکرده است.حالت جهانی باقی مانده در کارگر به حافظه درخواست آزاد شده اشاره می کند.
زمان وقوع معمولیفرآیند اولیه سازی، اجرا یا پاکسازی درخواست فعلیدرخواست قبلی از وضعیت خارج می شود و درخواست های بعدی آن را از قبل مصرف می کنند.
آیا OOM شرط لازم است؟متعلق به مکانیسم اصلی تحریک آسیب پذیری استخیر؛ سایر خطاهای کشنده و پاکسازی پس از تشخیص نیز ممکن است دخیل باشند
جهت تعمیر اساسیبه طور ایمن با شکست های تخصیص و خاتمه درخواست رسیدگی کنیدتصحیح مالکیت دولتی، زمان بندی پاکسازی و اولیه سازی اولیه
الزامات دفعباید تعمیر شودباید همزمان تعمیر شود

اساس: دو بولتن رسمی امنیتی و موارد ارسالی ثابت. S2S3S4

1.1 درک استقرارهای تحت تأثیر

PHP رسما در نظر می گیرد همه PHP مدیریت استقرار Web درخواست ها در معرض خطر، از جمله PHP-FPM , Apache mod_php , php-cgi , FrankenPHP ، و LiteSpeed . نشان داد mod_php حمله ممکن است قبل از اجرای کد برنامه اتفاق بیفتد، بنابراین بررسی های ورود، میان افزار چارچوب و اعتبارسنجی آپلود برنامه نمی توانند آن مسیر را پوشش دهند. S1

لازم است بین “استقرار باید اصلاح شود” و “زنجیره حمله خاصی کاملاً اثبات شده است” تمایز قائل شد. اعلام CVE-2026-109618: FPM پس از شکست راه‌اندازی درخواست از فرآیند فرزند خارج می‌شود و مسیر پاکسازی مربوطه mod_php را پس از شکست راه‌اندازی مسدود می‌کند. با این حال، مسیر OOM پس از راه اندازی موفقیت آمیز هنوز در معرض خطر است. در این اطلاعیه همچنین اشاره شده است که اکسپلویت کامل FPM برای این CVE هنوز نشان داده نشده است. از این محدودیت نمی توان برای استنباط اینکه FPM ایمن است استفاده کرد، به خصوص CVE-2026-109619 را نمی توان نادیده گرفت. S2S3

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

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

2. تجزیه و تحلیل علت

2.1 ابتدا دو چرخه زندگی را درک کنید

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

بنابراین، موتور باید دو محدودیت را حفظ کند:

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

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

2.2 CVE-2026-109618: OOM به‌روزرسانی وضعیت ناتمام را قطع کرد

پیاده‌سازی قدیمی از یک پرش غیرمحلی از نوع longjmp() برای مدیریت OOM استفاده می‌کند و مسیر مرتبط از طریق zend_bailout() از زمینه اجرای فعلی خارج می‌شود. خطر این است که یک قطعه از کد C ممکن است یک شی، آرایه یا وضعیت درخواست جدید را به کد دیگری منتشر کرده باشد، اما هنوز تمام مقداردهی اولیه فیلد را تکمیل نکرده باشد. در این زمان، هر گونه شکست تخصیص در زمان مربوطه ممکن است باعث شود مراحل بسته شدن عادی نادیده گرفته شوند. S2

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

  1. ساختار داخلی درخواست را ایجاد یا به روز کنید و آن را در دسترس قرار دهید.
  2. تخصیص حافظه بعدی با شکست مواجه می شود و OOM فعال می شود.
  3. جریان اجرا از تابع فعلی دور می‌شود و کدی که در ابتدا برای تکمیل مقداردهی اولیه یا بازیابی حالت استفاده می‌شد، اجرا نمی‌شود.
  4. پاکسازی درخواست به پردازش این ساختارها ادامه می دهد و محتوای نامعتبر را به عنوان فیلدها یا آدرس های معتبر در نظر می گیرد.

مشکل این نیست که تمام شدن حافظه همیشه باعث RCE می شود. در عوض، تخلیه حافظه جریان کنترل را تغییر می دهد و مفروضات موتور در مورد ساختارهای معتبر را نقض می کند. لازم نیست تخصیص ناموفق مستقیماً ساختاری را که در نهایت اشتباه خوانده می شود، درگیر کند. S2

چرا درخواست های کوچکتر نیز ممکن است حافظه آنها تمام شود

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

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

دو نتیجه حفاظتی را می توان از این نتیجه گرفت:

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

چرا احراز هویت برنامه ممکن است خیلی دیر باشد

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

2.3 CVE-2026-109619: حافظه درخواست آزاد شد، مرجع جهانی هنوز زنده است

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

تجزیه و تحلیل رسمی شرایط بهره برداری را به “تولید کنندگان” و “مصرف کنندگان” تقسیم می کند:

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

این شرایط باید به صورت ترکیبی برآورده شوند. هر گونه گزارش خطا به خودی خود ثابت نمی کند که آسیب پذیری با موفقیت مورد سوء استفاده قرار گرفته است. S3

نیازی به OOM به عنوان پیش نیاز ضروری ندارد

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

بنابراین، تغییر memory_limit به نامحدود، این مجموعه از آسیب‌پذیری‌ها را پوشش نمی‌دهد.

”قبل از مقداردهی اولیه” باید جداگانه مورد بررسی قرار گیرد

زمان دو نوع مصرف کننده تایید شده متفاوت است:

  • Early INI diagnostics: برخی از پیکربندی‌ها در صورت اخطار مشکل، اطلاعیه یا منسوخ شدن درخواست قبل از مقداردهی اولیه مجری عادی اعمال می‌شوند و پردازش تشخیصی ممکن است به حالت خطای قدیمی دسترسی پیدا کند.
  • پیشرفت آپلود جلسه: جلسه ممکن است از قبل در طول فرآیند تجزیه بدن درخواست پردازش شود، اما ماژول معمولی RINIT هنوز تکمیل نشده است. نمی توان استنباط کرد که مسیر وجود ندارد زیرا برنامه به طور صریح session_start() را فراخوانی نمی کند. S3

نه همه INI پیکربندی‌ها زمان‌بندی ریسک یکسانی دارند. پیکربندی در سطح دایرکتوری mod_php و PHP_VALUE / PHP_ADMIN_VALUE گذشت توسط FPM قسمت جلویی باید از معمولی متمایز شود php.ini , FPM pool پیکربندی راه اندازی و FPM .user.ini . دومی‌ها زمان‌بندی پیکربندی متفاوتی دارند و نمی‌توان آنها را در مجموع همان مصرف‌کنندگان اولیه نامید. S3

خاموش کردن display_errors، log_errors، کاهش error_reporting، یا استفاده از @ تنها بر روی دید تشخیص تأثیر می‌گذارد. ممکن است قبل از تصمیم گیری برای خروجی گزارش به وضعیت داخلی مربوطه دسترسی داشته باشید. S3

3. نسخه تعمیر و انتخاب پچ

3.1 خط پایه رفع رسمی بالادست

شعبه فعلی PHPاولین نسخه ای که شامل این تعمیر رسمی استپیشنهادات
8.28.2.35به این نسخه یا نسخه بعدی حاوی همان اصلاحات ارتقا دهید
8.38.3.36همون بالا
8.48.4.27همون بالا
8.58.5.12همون بالا
8.1 و نسخه های قبلیپشتیبانی عمومی بالادستی به پایان رسیده استاولویت بندی مهاجرت به شعب پشتیبانی شده؛ انتشار چک کوتاه مدت یا پشتیبان سازنده LTS

نسخه و وضعیت پشتیبانی بر اساس اعلام رسمی PHP است و پایه زمانی 22 اکتبر 2026 است. S1

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

3.2 نسخه بسته توزیع کامل را بررسی کنید

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

به عنوان مثال، نسخه بسته رفع مشکل Ubuntu 24.04 LTS که برای Ubuntu USN-8948-1 فهرست شده است:

8.3.6-0ubuntu0.24.04.13

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

3.3 انتخاب پچ مناسب

صحنهطرح اولویتنکات کلیدی برای پذیرش
با استفاده از بسته توزیع PHPبه روز رسانی های امنیتی منتشر شده توسط سازنده را نصب کنیداین اطلاعیه هر دو CVE را پوشش می دهد. نسخه کامل پکیج صحیح است
از ظرف رسمی PHP یا تصویر خود ساخته استفاده کنیدبه روز رسانی پایه اجرا، بازسازی و استقرارنمونه در حال اجرا از تصویر جدید استفاده می کند. تمام نسخه های قدیمی خارج می شوند
خود کامپایل شاخه های پشتیبانی شدهاز نسخه امنیتی رسمی این شعبه یا مجموعه پچ رسمی کامل استفاده کنیدتطبیق شاخه، تکمیل وابستگی، سازگاری پسوند و گذر از رگرسیون
مشمول 7.4، 8.0، 8.1اولویت بندی پشتیبان فروشنده؛ در صورت لزوم، شعبه کد منبع اضطراری رسمی را ارزیابی کنیدتغییرات رفتاری را شناسایی کنید و انتقال به نسخه های پشتیبانی شده را برنامه ریزی کنید

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

4. فرآیند تعمیر رسمی

4.1 موجودی زمان اجرا که در واقع به درخواست ها رسیدگی می کند

توصیه می شود یک دفتر کل مختصر برای ثبت حداقل موارد زیر تشکیل دهید:

  • نام دامنه یا سرویس ورودی، باطن پروکسی معکوس، PHP SAPI.
  • شاخه PHP، نسخه پکیج کامل یا خلاصه تصویر، منبع ساخت.
  • FPM pool، واحد خدمات واقعی، ظرف یا Pod، تعداد ماکت.
  • برنامه‌های افزودنی، پیکربندی اصلی و فایل‌های پیکربندی اضافی بارگیری شده‌اند.
  • آیا نسخه‌های دیگر PHP، نسخه‌های استقرار قدیمی، یا پورتال‌های اصلی وجود دارند که می‌توان مستقیماً به آنها دسترسی داشت؟

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

4.2 به روز رسانی صحیح را انتخاب و اجرا کنید

نسخه ثابت را مطابق با بخش 3، ترجیحاً با استفاده از منبع بسته قابل اعتماد موجود یا زنجیره ساخت کنترل شده تأیید کنید. دامنه به روز رسانی باید شامل مؤلفه ای باشد که واقعاً درخواست را میزبانی می کند، مانند بسته FPM، ماژول Apache PHP، باینری CGI یا ساخت سرویس که PHP در آن تعبیه شده است.

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

4.3 نمونه های در حال اجرا را مجدداً راه اندازی یا جابجا کنید

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

برای mod_php، فرآیند Apache میزبان ماژول را مجددا راه اندازی کنید. سرویس‌هایی که PHP را تعبیه می‌کنند باید فرآیند میزبانی آنها جایگزین شود. برای FPM، پاک کردن OPcache جایگزین به‌روزرسانی زمان اجرا و بازنشستگی کارگران قدیمی نمی‌شود.

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

4.4 تأیید از طریق درخواست های واقعی Web

توصیه می شود به جای تکیه بر یک دستور نسخه واحد، شواهد زیر را ترکیب کنید:

شواهدچه چیزی قابل اثبات استبه تنهایی نمیشه چیزی رو ثابت کرد
مدیر بسته یا فراداده تصویرمنابع نصب و ساخت کاملترافیک به این نمونه تغییر کرده است
وضعیت فرآیند و استقرارکارگر یا کانتینر تعویض کامل می کندورودی خارجی باید به سمت آن هدایت شود
دسترسی به نتایج تشخیصی محدود از طریق پورتال واقعیWeb SAPI واقعی و پیکربندی در حال اجراآیا پورت پشتی انتشار دو CVE را پوشش می دهد
اعلام فروشنده یا ثبت کامل پچاین رفع اشکال در این ساخت گنجانده شده استهمه کپی ها مستقر هستند

PHP_VERSION، PHP_SAPI، فایل‌های پیکربندی بارگذاری‌شده، و تنظیمات اضطراری را می‌توان از طریق قابلیت‌های تشخیص داخلی موجود، یا پورتال‌های تشخیصی موقت و با کنترل دسترسی بررسی کرد. اطمینان حاصل کنید که درخواست مستقیماً توسط CDN یا حافظه پنهان صفحه بازگردانده نمی شود. پس از تکمیل، ورودی تشخیصی موقت را حذف کنید.

php -v معمولاً فقط باینری CLI را نشان می دهد که در حال حاضر توسط پوسته انتخاب شده است. دستوراتی مانند php-fpm -i معادل تایید کارگر موجودی که ترافیک دریافت می کند نیست. صفحه کامل phpinfo() را برای مدت طولانی در معرض شبکه عمومی قرار ندهید.

4.5 بررسی رگرسیون تجاری و حذف تنظیمات اضطراری

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

اگر memory_limit=-1 به طور موقت تنظیم شود، بودجه محدود مطابق با ظرفیت کسب و کار پس از اعمال وصله رسمی بازیابی می شود. اگر pm.max_requests=1 تنظیم شود، پیکربندی چرخه عمر ارزیابی شده با ظرفیت پس از تأیید تعمیر بازیابی می شود. محدودیت‌های اندازه ورودی و کنترل‌های دسترسی منبع را می‌توان بر اساس نیازهای کسب‌وکار حفظ کرد.

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

5. اقدامات کاهشی زمانی که ارتقاء فوری امکان پذیر نیست

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

5.1 اولویت بندی کنترل های ترافیک قبل از PHP

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

این محدودیت ها شامل تمامی ورودی های PHP می شود. فقط با رهگیری URL به نام “upload” ورودی های دیگری که هنوز به طور خودکار توسط PHP در بدنه درخواست تجزیه می شوند را از دست می دهد. برای مواردی مانند انتقال های تکه تکه شده، عدم وجود طول اعلام شده در دسترس، و غیره، محدودیت باید بر اساس اندازه واقعی خوانده شده باشد. برنامه همچنین باید بودجه اندازه خروجی خود را در هنگام فشرده سازی یا گسترش مجدد محتوا داشته باشد.

الگوی پیکربندی 5.2 FPM pool

تنظیمات زیر را در بخش پیکربندی FPM pool قرار دهید که در واقع به درخواست‌ها پاسخ می‌دهد، نه کلمه به کلمه در php.ini. مقادیر 8M و 4M نمونه هایی برای تنظیم حجم کار هستند. هنگام محدود کردن کل درخواست POST، فضایی را برای فیلدهای فرم و مرزهای چند قسمتی بگذارید. S11S12

; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off

فقط PHP 8.5 به علاوه:

php_admin_flag[fatal_error_backtraces] = off

توابع و مرزهای هر یک به شرح زیر است:

پیکربندیاثر مورد انتظارشرح محدودیت هایی که باید حفظ شوند
memory_limit=-1شرایط ماشه حد بالایی درخواست حافظه قابل پیش بینی PHP را حذف کنیداز شکست تخصیص اساسی جلوگیری نمی کند. لغو بودجه اولیه ممکن است خطر خستگی حافظه و قطع سرویس را افزایش دهد.
post_max_size کوچکترحجم داده‌های وارد شده به فرآیند تجزیه را کاهش دهیدتجزیه کننده ثابت نشده دارای شکاف شناخته شده است. تقویت حافظه به طور مستقل قابل پیشگیری نیست
upload_max_filesize < post_max_sizeاندازه فایل را محدود کنید و فضای سربار درخواست را رزرو کنیدهمه فیلدها، ابرداده ها یا تخصیص های درون برنامه ای را محدود نمی کند
بستن پیشرفت آپلودمسیر تایید شده مربوط به جلسه را مسدود کنیدسایر گونه های دولتی جهانی را پوشش نمی دهد
PHP 8.5 بک ردیاب کشنده را بسته استمسدود کردن تولیدکنندگان وضعیت مرتبط تایید شدهمسیرهای دیگر مانند نشست را پوشش نمی دهد

مرزهای اندازه گیری از اعلام رسمی آمده است. برای نحو استخر و معنایی پیکربندی سطح مدیریت، راهنمای PHP را ببینید. S1S2S3S11

تنظیمات php_admin_* در سطح مدیریت نمی توانند توسط برنامه های کاربردی از طریق ini_set() لغو شوند. همه پیکربندی‌های ورودی، سطح فهرست و جلویی باید بازبینی شوند تا تأیید شود که مقادیر درخواست‌های واقعی مطابق انتظار هستند. پس از اصلاح، تمام کارگر را بازسازی کنید تا از ادامه روندهای موجود در حالت قبلی جلوگیری کنید.

اگر مستقیماً php.ini را تغییر دهید، نحو باید به:

memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = Off

برخلاف php_admin_value در استخر، صرفاً تنظیم memory_limit=-1 در php.ini مانع از تغییر مجدد برنامه نمی‌شود. چارچوب، کد برنامه و سایر تنظیمات باید بررسی شوند تا ببینیم آیا مقدار محدود را بازنشانی کرده‌اند یا خیر. در صورت نیاز به اجرا، از تنظیمات سطح مدیریت مناسب برای SAPI فعلی استفاده کنید و مقدار واقعی واقعی را بررسی کنید. S11S12

fatal_error_backtraces = Off را فقط برای PHP 8.5 اضافه کنید. از ini_set() در سطح برنامه به عنوان راه حلی برای غیرفعال کردن پیشرفت آپلود استفاده نکنید، و برای موثر کردن آن قبل از تجزیه درخواست، به FPM .user.ini اعتماد نکنید. S1S3

5.3 هزینه حذف محدودیت های حافظه PHP را مدیریت کنید

memory_limit=-1 یک کاهش موقت مسیر برای محیط های ثابت نشده است و نباید به عنوان پیکربندی پیش فرض طولانی مدت کپی شود. هنگامی که یک برنامه یا درخواست از کنترل خارج می شود، می تواند مقدار بیشتری از حافظه میزبان را مصرف کند. بنابراین، قبل از استفاده، باید تعداد همزمانی‌ها، پیک تک کارگر و ظرفیت کل سرویس را ارزیابی کنید و محدودیت‌های ورودی front-end را اعمال کنید. S2

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

استراتژی‌های فوق را با RLIMIT_AS، RLIMIT_DATA یا محدودیت‌های فضای آدرس فرآیند مربوطه جایگزین نکنید. آنها ممکن است مستقیماً باعث شوند که تخصیص اساسی در مسیر هنوز مشکل ساز OOM شکست بخورد. S2

مثال پیکربندی 5.4 Nginx

قابل اجرا برای استقرار که در آن Nginx درخواست ها را به PHP-FPM ارسال می کند. می توان آن را در سطح پیکربندی سرویس میزبانی واقعی تنظیم کرد:

client_max_body_size 8m;
fastcgi_request_buffering on;

client_max_body_size اندازه بدنه درخواست را محدود می کند. fastcgi_request_buffering on به Nginx اجازه می‌دهد ابتدا متن کامل درخواست را بخواند و سپس آن را به باطن FastCGI ارسال کند. اینکه آیا در یک server یا location خاص تأثیر می گذارد، باید در ارتباط با وراثت و روابط پوشش موجود بررسی شود. S13S14

فقط زمانی که کسب و کار نیازی به چندپارت ندارد، می توانید یک قانون رد را به ورودی سرویس مربوطه اضافه کنید:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

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

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

5.5 کاهش اختیاری: یک درخواست برای هر کارگر FPM

برای استقرار FPM که می تواند هزینه های سربار را تامین کند، تنظیمات کوتاه مدت را می توان ارزیابی کرد:

pm.max_requests = 1

و کارگر موجود را بازسازی کنید. این زنجیره درخواست متقابل توصیف شده را در سطح استفاده مجدد کارگر مسدود می کند، اما سربار ایجاد فرآیند و مقداردهی اولیه را افزایش می دهد. در عین حال، نمی تواند همان درخواست OOM و مسائل پاکسازی CVE-2026-109618 را تعمیر کند. وقتی مقدار کوچکتر اما بزرگتر از 1 باشد، هنوز یک پنجره درخواست مجدد وجود دارد. S3S11

محدودیت های پوشش 5.6 WAF و Cloudflare

Cloudflare ترتیبات استقرار را برای محافظت در برابر PHP2Shell، از جمله طرح Free اعلام کرده است. هنگام استفاده از خدمات آن، باید بررسی کنید که آیا ترافیک واقعی از پروکسی عبور می کند، آیا قوانین حفاظتی در حال اجرا هستند، و آیا می توان سایت مبدا را مستقیماً دور زد. برای برنامه های پولی، باید پیکربندی و استثنائات قوانین مدیریت شده مربوطه را نیز بررسی کنید. S16

برخی از تشخیص‌هایی که توسط فروشنده توضیح داده شده است از سیگنال‌های پاسخ استفاده می‌کنند، بنابراین همه حفاظت‌ها را نمی‌توان به صورت “هر حمله قبل از رسیدن به PHP مسدود شده است” تفسیر کرد. WAF می تواند به کاهش نوردهی و ارائه اطلاعات رصدی کمک کند، اما ارتقاء مداوم به PHP هنوز ضروری است. S16

5.7 چرا اقدامات رایج کافی نیست

اقدامات یا قضاوت هاکاستی ها
فقط file_uploads را ببندیدنمی تواند تمام پردازش های چند بخشی را پوشش دهد و مسیر OOM خودش را اعمال کند
تنظیم enable_post_data_reading=Offتغییر رفتار پر کردن خودکار POST/FILES. بدنه درخواست همچنان توسط برنامه قابل خواندن است و ممکن است کار عادی را مختل کند
نمایش خطا را خاموش کنید، وارد سیستم شوید یا از @ استفاده کنیدممکن است پردازش تشخیصی داخلی همچنان به حالت آویزان دسترسی داشته باشد
افزایش تعداد کارگرانیک مکانیسم پاکسازی حالت ایمن ایجاد نکنید و استفاده مجدد از یک کارگر را حذف نکنید
فقط disable_functions یا open_basedir را پیکربندی کنیداین محدودیت ها خرابی حافظه لایه موتور C را برطرف نمی کند
فقط یک بار یک نسخه یا یک نسخه را بررسی کنیدنمی توان ثابت کرد که تمام ورودی ها و نمونه های در حال اجرا تعویض شده اند
هیچ گزارش استثنایی دیده نمی شودنمی تواند ثابت کند که آسیب پذیری وجود ندارد یا قبلا مورد سوء استفاده قرار نگرفته است.

در میان آنها، اساس مکانیزم پیکربندی و آسیب پذیری PHP را می توان در S2S3S12 یافت. قضاوت در مورد مرزهای پوشش، پذیرش و مجوز بر اساس پیشنهادهای اجرایی ارائه شده توسط این مکانیسم ها است.

6. ایده های اجرایی و نکات بررسی پچ رسمی

6.1 از اصلاحات کامل برای شاخه صحیح استفاده کنید

ارائه رسمی نماینده برای PHP 8.5 به شرح زیر است:

31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout

commit صریحاً دو CVE را به هم مرتبط می‌کند، هم برای تنظیم مکانیسم خروج OOM و هم برای رفع وضعیت جهانی که ممکن است در مرحله اولیه‌سازی به آن دسترسی داشته باشید. ارسال صفحه با تفاوت کامل به S4S5 مراجعه کنید. سایر شعب باید از نسخه‌های امنیتی رسمی یا وصله‌های منطبق استفاده کنند و نمی‌توان تصور کرد که تغییرات 8.5 می‌تواند مستقیماً روی هر نسخه قدیمی‌تری اعمال شود.

6.2 OOM تعمیر: ابتدا وضعیت قابل پردازش را بازیابی کنید و سپس درخواست را خاتمه دهید

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

زیر گزیده ای از کد کلید در تفاوت 8.5 است که برای علامت گذاری OOM معلق استفاده می شود:

EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);

مدیریت وقفه VM و سایر مکان های امن متعاقباً با zend_handle_delayed_oom() تماس می گیرند. زمینه اجرای کد کاربر آن از یک مسیر باز کردن کنترل شده استفاده می کند. مسیر سخت OOM _exit(137) را فراخوانی می کند. S5

از منظر طراحی، تغییرات مهم عبارتند از: avoid به طور خودسرانه از پشته فراخوانی C زمانی که ساختار در حالت میانی است عبور می کند و خروجی را در مکانی قرار می دهد که می تواند محدودیت های حالت را حفظ کند. پس از فعال شدن محدودیت نرم، ممکن است به حافظه اضافی برای تکمیل فرآیند نیاز باشد، بنابراین آستانه نرم جدید را نمی توان به عنوان حد بالایی مطلق برای کل حافظه فرآیند درک کرد.

همچنین نمی توان آن را به عنوان “PHP تمام zend_bailout() حذف کرده است” خلاصه کرد. پچ همچنان از مکانیسم های مرتبط در زمینه های خاص استفاده می کند. آنچه ثابت شده است زمان خروج خطرناک و مدیریت دولتی همراه است. S5

6.3 تماس گیرندگان تخصیص و تجزیه چند قسمتی را با هم به روز کنید

اگر یک تابع تخصیص را فقط به “بازگشت NULL در صورت شکست” تغییر دهید و تماس گیرنده اصلی همچنان فرض کند که یک اشاره گر معتبر همیشه برگردانده می شود، دسترسی های اشاره گر تهی جدید یا پاکسازی ناقص را معرفی خواهید کرد. رابط تخصیص ناموفق در پچ باید همراه با بررسی تماس گیرنده و انتشار استثنا بررسی شود. S5

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

برای تیم هایی که شعبه های خود را حفظ می کنند، توصیه می شود مسائل زیر در کانون بررسی کد قرار گیرند:

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

اینها سوالات مروری هستند که بر اساس مکانیسم تعمیر خلاصه شده اند و نتیجه حسابرسی نیستند که برای یک پایه کد ارائه نشده تکمیل شده باشد.

6.4 رفع درخواست متقابل: اولیه سازی زودتر، پاکسازی نهایی دیرتر

مربوط به CVE-2026-109619، پچ چندین مرز چرخه عمر را به طور همزمان تنظیم می کند. فایل ها و عملیات فهرست شده در زیر به عنوان مثال از PHP 8.5 رسمی تفاوت دارند. S5

مکانتغییر جهتمشکل حل شد
Zend/zend_execute_API.c و غیرهبازنشانی وضعیت اجرا کننده مانند خطاها، استثناها، کنترل کننده ها، اشیاء و غیره.پس از پایان درخواست، هنوز مراجع قدیمی وجود دارد که با درخواست بعدی قابل دسترسی است.
مسیر راه اندازی main/main.cقبل از فعال شدن SAPI با php_basic_early_rinit() تماس بگیریدهنگامی که یک مصرف کننده اولیه رخ می دهد، وضعیت اساسی مربوطه هنوز مقداردهی اولیه نشده است.
بستن مسیر main/main.cHTTP globals را نابود کرده و آن را به عنوان تعریف نشده علامت گذاری کنیدمقدار آزاد شده همچنان یک شی معتبر در نظر گرفته می شود
قبل از اینکه پشته درخواست در نهایت آزاد شودآخرین پیغام خطا را دوباره پاک کنیدتشخیص دیرهنگام پاکسازی وضعیت خطا را دوباره پر می کند
ext/session/session.cپیشرفت آپلود مسیر اولیه در اولین جلسه جهانی اولیه استماژول معمولی RINIT که قبلاً به وضعیت قدیمی دسترسی داشت
کد مربوط به سریال سازیتجزیه کلاس و تماس های کاربر را در پردازش اولیه محدود کنیددر صورت کامل نشدن مقداردهی اولیه، کد کاربر اضافی را اجرا کنید

به عنوان مثال، دنباله راه اندازی شامل:

zend_activate();
php_basic_early_rinit();
sapi_activate();

پس از نابودی HTTP globals، علامت خرابی وضعیت را اضافه کنید:

zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);

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

6.5 چرا انجام “تعمیر یک خط” خود توصیه نمی شود؟

جایگزینی تمام zend_bailout() با _exit()، یا فقط اضافه کردن یک بررسی نشانگر تهی در یک ورودی خاص، تعداد زیادی از زمینه های اجرایی مختلف را در بر می گیرد. آنها ممکن است سایر فیلدهای وضعیت را حذف کنند، یا ممکن است تخریب، تماس های طولانی، میزبانی پردازش، و درخواست معنای پایانی را تغییر دهند.

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

7. بکپورت اضطراری PHP 7.4, 8.0, 8.1

PHP به طور رسمی حداقل منبع کد پشتیبان سه شاخه قدیمی را بر اساس شدت ارائه می دهد. نام شعب عبارتند از:

PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619

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

7.1 پشتیبان PHP 8.1 را به عنوان مثال در نظر بگیرید

موارد ارسالی مربوطه برای PHP 8.1 عبارتند از:

1d7dec178a094e6e75b229ce22754045f8c6070a

استراتژی آن به نفع شکست سریع است: فراخوانی _exit(1) پس از خروجی تشخیص در مسیر OOM مربوطه، و شامل وضعیت جهانی و سایر اصلاحات مربوطه. در حالی که پردازش مربوط به پیشرفت آپلود جلسه را غیرفعال می کند. برای ارسال کد منبع مربوطه، به S6 مراجعه کنید.

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

7.2 قیمتی که باید هنگام استقرار بپذیرید

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

بنابراین، کاربران نسخه های قدیمی باید به ترتیب موارد زیر را در نظر بگیرند:

  1. به شعبه پشتیبانی شده PHP و نسخه ثابت آن مهاجرت کنید.
  2. از نسخه ای استفاده کنید که صراحتاً CVE یا به روز رسانی سازنده LTS را پوشش دهد.
  3. اگر واقعاً تابع نسخه قدیمی کد منبع است، از پشتیبان اضطراری رسمی نسخه منطبق برای تأیید تغییرات و سازگاری کامل و ترتیب انتقال بعدی استفاده کنید.

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

8. معیارهای پذیرش و بازرسی های بعدی

توصیه می شود که نتایج زیر به عنوان مبنایی برای تکمیل این تعمیر استفاده شود:

موارد پذیرشاستانداردهای تکمیل
پوشش آسیب پذیریاعلامیه ساخت یا فروشنده به صراحت CVE-2026-109618 و CVE-2026-109619 را اصلاح می کند
پوشش استقرارهمه پورتال ها، استخرها، خدمات و ماکت ها از زمان اجرا تعمیر شده استفاده می کنند
فرآیند اثر می گذاردکارگر قدیمی، فرآیند میزبان قدیمی و کانتینر قدیمی همه خارج می شوند
تأیید درخواست معتبرSAPI تأیید شد، با پیوند واقعی Web ساخته و پیکربندی شده است تا جهت گیری نادرست حافظه پنهان را حذف کند.
در دسترس بودن کسب و کارعملکردهای کلیدی مانند جلسه، آپلود، وارد کردن و مدیریت خطا به طور عادی بازگشته اند.
پایان اقدامات موقتحافظه نامحدود و پیکربندی‌های بازیافت شدید کارگر طبق برنامه ظرفیت بازیابی شده‌اند یا دلیل روشنی برای حفظ آن دارند.
شواهد تغییرنسخه بسته یا خلاصه تصویر، دامنه به روز رسانی، زمان تکمیل و نتایج تأیید را ضبط کنید

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

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

پیوست: منابع و پیوندهای ذکر شده

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

S1 — PHP بولتن رسمی امنیتی و نسخه تعمیر

  • منبع: پروژه PHP، 21 اکتبر 2026.
  • هدف: محدوده ریسک، چهار نسخه رسمی تعمیر، اقدامات موقت رسمی و دستورالعمل های پشتیبان اضطراری برای شاخه های قدیمی.
  • مرجع: PHP 2026 This security bulletin در آرشیو بولتن سالانه موجود است

S2 — بولتن فنی رسمی CVE-2026-109618

  • منبع: php/php-src GitHub Security Advisory، 21 اکتبر 2026.
  • شناسایی: GHSA-w8hw-w9fx-j79w.
  • هدف: مرز پوشش برای OOM، تقویت چند قسمتی، تفاوت SAPI و کاهش.
  • مرجع: RCE via OOM corruption

S3 — بولتن فنی رسمی CVE-2026-109619

  • منبع: php/php-src GitHub Security Advisory، 21 اکتبر 2026.
  • شناسایی: GHSA-6wmf-4rv5-p3rp.
  • هدف: حالت آویزان درخواست متقابل، تولیدکنندگان و مصرف کنندگان، اولیه سازی اولیه، کاهش پیکربندی.
  • مرجع: RCE via stale global state

S4 — ارسال رسمی تعمیر PHP 8.5

  • منبع: php/php-src.
  • ارسال: 31c0ea7d7ff1d1fccb6492e52dab544011628065.
  • هدف: تأیید ارسال رسمی برای رفع دو آسیب پذیری همزمان و توضیح جهت کلی تغییر.
  • مرجع: Avoid state corruption via bailout

S5 — PHP 8.5 به طور رسمی بازیابی و تفاوت کامل

  • منبع: متفاوت از همان ارسال رسمی.
  • هدف: اجرای خاص تخصیص دهنده، VM، HTTP globals، جلسه، سریال سازی و چرخه عمر درخواست را بررسی کنید.
  • مرجع: official complete diff

S6 — PHP 8.1 ارسال پشتیبان رسمی اضطراری

S7 — PHP 7.4 شعبه پشتی اضطراری رسمی

S8 — PHP 8.0 شعبه پشتی اضطراری رسمی

S9 — PHP 8.1 شعبه پشتی اضطراری رسمی

S10 — Ubuntu بولتن امنیتی USN-8948-1

  • منبع: Canonical / Ubuntu، 21 اکتبر 2026.
  • هدف: نسخه پشتیبان و نمونه های نسخه کامل بسته را منتشر کنید.
  • مرجع: USN-8948-1: PHP vulnerabilities

راهنمای S11 — PHP-FPM Configuration

  • منبع: سند رسمی PHP.
  • هدف: معناشناسی پیکربندی مانند php_admin_value، php_admin_flag، pm.max_requests، و غیره.
  • مرجع: PHP-FPM Configuration

راهنمای پیکربندی S12 — PHP Core INI

  • منبع: سند رسمی PHP.
  • هدف: تعریف و محدوده بدنه درخواست، آپلود، حافظه و پیکربندی خودکار خواندن POST.
  • مرجع: Description of core php.ini directives

S13 — محدودیت اندازه بدنه درخواست Nginx

S14 — بافر درخواست Nginx FastCGI

S15 — Nginx شرایط و دستورالعمل های بازگشت

دستورالعمل های حفاظتی S16 — Cloudflare PHP2Shell