PHP2Shell: وجوہات اور تدارک کا رہنما

ذرائع 22 اکتوبر 2026 تک چیک کیے گئے۔ Audience: PHP ایپلیکیشن آپریٹرز، سیکیورٹی ریسپانسرز، اور انجینئرز جو اپنی مرضی کے مطابق PHP تعمیرات کو برقرار رکھتے ہیں۔

اس مضمون میں PHP2Shell خطرے کی وجہ، اثر کی گنجائش، رسمی مرمت کا عمل، عارضی تخفیف کے اقدامات اور سرکاری پیچ کے نفاذ کا خلاصہ کیا گیا ہے۔ مرکزی متن نمبرز جیسے S1 کا استعمال کرتے ہوئے حوالہ دیا گیا ہے۔ تمام سورس لنکس متن کے آخر میں ضمیمہ میں درج ہیں۔ کنفیگریشن فریگمنٹ ایک تعیناتی ٹیمپلیٹ ہے، جسے اصل ورژن، کاروباری صلاحیت، اور کنفیگریشن وراثت کے تعلق کی بنیاد پر ایڈجسٹ کرنے کی ضرورت ہے۔

TL؛ DR: مرمت کے اقدامات اور تجاویز

اپ گریڈ کریں۔ PHP رن ٹائم : کم از کم متعلقہ برانچ کو اپ گریڈ کریں۔ 8.2.35 , 8.3.36 , 8.4.27 یا 8.5.12 . ڈسٹری بیوشن پیکجز کے لیے، پیکج کا مکمل ورژن استعمال کریں جس کی تصدیق وینڈر دونوں CVE کو ٹھیک کرتا ہے۔ S1 S10
تمام پرانے عمل کو تبدیل کریں۔ : دوبارہ شروع کریں یا ہر ایک پر رول کریں۔ PHP worker ، ہوسٹنگ سروس، اور کنٹینر اپ گریڈ کرنے کے بعد، اور تصدیق کریں کہ پرانی مثالیں ختم ہو گئی ہیں۔
اصل Web درخواست پاتھ کے ذریعے تصدیق کریں: Web SAPI، مکمل پیکیج ورژن، اور چلنے والی مثال کو چیک کریں۔ صرف php -v کو چیک کرنے سے یہ ثابت نہیں ہوتا کہ لائیو سروس فکس ہے۔
بزنس ریگریشن چیکس چلائیں اور عام وسائل کے بجٹ کو بحال کریں۔ : ٹیسٹ لاگ ان، سیشن ہینڈلنگ، اپ لوڈز، امپورٹس، اور ایرر ہینڈلنگ۔ اگر PHP میموری کی حد کو عارضی طور پر ہٹا دیا گیا تھا، پیچ کرنے کے بعد ایک مناسب محدود بجٹ کو بحال کریں۔
Iاگر فوری اپ گریڈ کرنا ناممکن ہے: غیر بھروسہ مند ٹریفک کو PHP تک پہنچنے سے پہلے محدود کریں۔ اپ لوڈ کی پیشرفت کو غیر فعال کرنے اور PHP 8.5 مہلک بیک ٹریسز کا اندازہ کریں جیسا کہ سیکشن 5 میں بیان کیا گیا ہے۔ کنفیگریشن میں تخفیف اور WAF قوانین کی کوریج محدود ہے اور وہ اپ گریڈ کی جگہ نہیں لے سکتے۔ S1 S2 S3

1. کمزوری کا جائزہ اور خطرے کا فیصلہ

PHP2Shell اس مضمون میں Critical سطح کی دو کمزوریوں کا حوالہ دیتا ہے جو 21 اکتوبر 2026 کو PHP کی طرف سے باضابطہ طور پر ظاہر کیے گئے تھے۔ دونوں کا تعلق میموری سے ہے اور PHP انجن کی لائف سائیکل مینجمنٹ کی درخواست کرتے ہیں، جس سے دوبارہ کٹوتی کوڈ کا خطرہ لاحق ہوتا ہے۔ S1 S2 S3

پروجیکٹ	CVE-2026-109618	CVE-2026-109619
سرکاری نام	RCE via OOM corruption	RCE via stale global state
بنیادی مسائل	ناکافی یادداشت ایک غیر معمولی چھلانگ کا سبب بنتی ہے، ایسی حالت چھوڑتی ہے جس نے ابھی تک ابتداء مکمل نہیں کی ہے۔	کارکن میں باقی عالمی ریاست جاری کردہ درخواست کی یادداشت کی طرف اشارہ کرتی ہے۔
عام وقوعہ کا وقت	موجودہ درخواست کی ابتدا، عمل درآمد یا صفائی کا عمل	پچھلی درخواست اسٹیٹس کو چھوڑ دیتی ہے، اور اس کے بعد کی درخواستیں اسے پہلے سے استعمال کرتی ہیں۔
کیا OOM ایک ضروری شرط ہے؟	کمزوری کے بنیادی محرک میکانزم سے تعلق رکھتا ہے۔	نہیں؛ دیگر مہلک غلطیاں اور تشخیص کے بعد صفائی بھی شامل ہو سکتی ہے۔
بنیادی مرمت کی سمت	مختص کی ناکامیوں کو محفوظ طریقے سے ہینڈل کریں اور ختم کرنے کی درخواست کریں۔	ریاست کی ملکیت، صفائی کا وقت اور ابتدائی آغاز کو درست کریں۔
ضائع کرنے کی ضروریات	مرمت کرنا ضروری ہے	ایک ہی وقت میں مرمت کرنا ضروری ہے

بنیاد: دو سرکاری سیکیورٹی بلیٹن اور فکس گذارشات۔ S2 S3 S4

1.1 متاثرہ تعیناتیوں کو سمجھنا

PHP سرکاری طور پر سمجھتا ہے تمام PHP تعیناتی ہینڈلنگ Web درخواستیں خطرے میں، بشمول PHP-FPM , Apache mod_php , php-cgi , FrankenPHP ، اور LiteSpeed . نے مظاہرہ کیا۔ mod_php حملہ ایپلیکیشن کوڈ کے چلنے سے پہلے ہوسکتا ہے، لہذا لاگ ان چیک، فریم ورک مڈل ویئر، اور ایپلیکیشن اپ لوڈ کی توثیق اس راستے کا احاطہ نہیں کرسکتی ہے۔ S1

“تعینات کو طے کرنے کی ضرورت ہے” اور “ایک مخصوص حملے کا سلسلہ مکمل طور پر ثابت ہو چکا ہے” کے درمیان فرق کرنا ضروری ہے۔ CVE-2026-109618 کا اعلان: FPM درخواست کے سٹارٹ اپ کے ناکام ہونے کے بعد چائلڈ پروسیس سے باہر ہو جائے گا، سٹارٹ اپ کی ناکامی کے بعد mod_php کے متعلقہ صفائی کے راستے کو مسدود کر دے گا۔ تاہم، کامیاب آغاز کے بعد OOM راستہ اب بھی خطرے میں ہے۔ اعلان یہ بھی نوٹ کرتا ہے کہ اس CVE کے لیے مکمل FPM استحصال کا ابھی تک مظاہرہ نہیں کیا گیا ہے۔ اس پابندی کا استعمال یہ اندازہ لگانے کے لیے نہیں کیا جا سکتا کہ FPM محفوظ ہے، خاص طور پر CVE-2026-109619 کو نظر انداز نہیں کیا جا سکتا۔ S2 S3

کامیاب استحصال کے لیے فوری اجازت کی حدود PHP کی میزبانی کرنے والے عمل کی شناخت اور اس کی رسائی کے وسائل پر منحصر ہے۔ عام طور پر، ویب سائٹ کوڈ، اپ لوڈ ڈائرکٹری، ڈیٹا بیس کی اسناد، سروس ٹوکن اور اندرونی نیٹ ورک تک رسائی کی صلاحیتوں پر توجہ دی جانی چاہیے۔ “ریموٹ کوڈ پر عمل درآمد” کا مطلب قدرتی طور پر روٹ پرمیشن حاصل کرنا نہیں ہے۔ یہاں نتیجہ کا فیصلہ عمل کی اجازت کے ماڈل پر مبنی ہے، اور اصل اثرات کو تعیناتی کی اجازتوں کے ساتھ مل کر جانچنے کی ضرورت ہے۔

عام ایک وقتی CLI اسکرپٹ میں وہی HTTP اندراج نہیں ہوتا ہے۔ لیکن CLI یا ایمبیڈڈ موڈ میں طویل عرصے تک بیرونی کاموں کو سنبھالنے والے عمل کو اب بھی رن ٹائم اور لائف سائیکل انوینٹری میں شامل کیا جانا چاہیے۔ صرف CMS، فریم ورک یا Composer انحصار کو اپ ڈیٹ کیا جاتا ہے اور بنیادی PHP انجن خود بخود تبدیل نہیں ہوتا ہے۔

2. وجہ کا تجزیہ

2.1 پہلے زندگی کے دو چکروں کو سمجھیں۔

PHP worker اکثر یکے بعد دیگرے متعدد درخواستوں کو ہینڈل کرتا ہے۔ درخواست کے دوران مختص کی گئی میموری کو درخواست کے اختتام پر یکساں طور پر جاری کیا جا سکتا ہے، جب کہ خود کارکن اور اس کے کچھ عالمی شعبے موجود رہتے ہیں۔

لہذا، انجن کو دو رکاوٹوں کو برقرار رکھنا چاہیے:

ابتدائی رکاوٹ: دوسرے کوڈز کو دکھائی دینے والا ڈیٹا ایسی حالت میں ہونا چاہیے جسے محفوظ طریقے سے پڑھا جا سکے، اس کو عبور کیا جا سکے اور تباہ کیا جا سکے۔
Lifecycle constraint: ایک بار درخواست کی میموری کو آزاد کر دیا گیا ہے، طویل عرصے تک رہنے والے فیلڈز کو اس میموری کے اندر موجود پتوں کو درست حالت کے طور پر علاج کرنا جاری نہیں رکھنا چاہیے۔

یہ دونوں رکاوٹیں کمزوریوں کے دو گروہوں کی ناکامی کے بنیادی طریقوں سے مطابقت رکھتی ہیں۔ مندرجہ ذیل عمل ایک طریقہ کار کی تفصیل ہے جو اعلانات اور پیچ کی تالیف کو یکجا کرتی ہے۔ اس کا یہ مطلب نہیں ہے کہ ہر تعیناتی کا بالکل وہی راستہ ہے جو قابل رسائی ہے۔ S2 S3 S5

2.2 CVE-2026-109618: OOM نے ایک نامکمل اسٹیٹس اپ ڈیٹ میں خلل ڈالا

پرانا نفاذ OOM کو ہینڈل کرنے کے لیے longjmp() قسم کی غیر مقامی چھلانگ کا استعمال کرتا ہے، اور متعلقہ راستہ zend_bailout() کے ذریعے موجودہ ایگزیکیوشن سیاق و سباق سے باہر نکلتا ہے۔ خطرہ یہ ہے کہ C کوڈ کے ایک ٹکڑے نے ایک نیا آبجیکٹ، سرنی، یا دوسرے کوڈ کی درخواست کی حیثیت شائع کر دی ہے، لیکن ابھی تک تمام فیلڈ کی ابتداء مکمل نہیں کی ہے۔ اس وقت، متعلقہ وقت پر کسی بھی مختص کی ناکامی عام بند ہونے کے مراحل کو چھوڑنے کا سبب بن سکتی ہے۔ S2

ناکامی کے عمل کو چار مراحل میں تقسیم کیا جا سکتا ہے:

درخواست کا اندرونی ڈھانچہ بنائیں یا اپ ڈیٹ کریں اور اسے قابل رسائی بنائیں۔
بعد میں میموری مختص کرنا ناکام ہو جاتا ہے اور OOM متحرک ہو جاتا ہے۔
عمل درآمد کا بہاؤ موجودہ فنکشن سے چھلانگ لگاتا ہے، اور کوڈ کو اصل میں شروع کرنے یا حالت کو بحال کرنے کے لیے استعمال کیا جاتا ہے۔
درخواست کی صفائی ان ڈھانچے پر کارروائی جاری رکھتی ہے اور غلط مواد کو درست فیلڈز یا ایڈریس کے طور پر مانتی ہے۔

مسئلہ یہ نہیں ہے کہ میموری ختم ہونا ہمیشہ RCE کا سبب بنتا ہے۔ بلکہ، میموری تھکن کنٹرول کے بہاؤ کو تبدیل کرتی ہے اور درست ڈھانچے کے بارے میں انجن کے مفروضوں کی خلاف ورزی کرتی ہے۔ ناکام مختص میں براہ راست اس ڈھانچے کو شامل کرنے کی ضرورت نہیں ہے جو بالآخر غلط پڑھی جاتی ہے۔ S2

کیوں چھوٹی درخواستیں بھی میموری سے باہر ہو سکتی ہیں۔

درخواست کے باڈی میں بائٹس کی تعداد اور تجزیہ کرنے کے بعد ہیپ کا استعمال ایک ہی چیز نہیں ہے۔ A فیلڈ PHP کے اندر متعدد تاروں، صفوں کے عناصر اور میٹا ڈیٹا آبجیکٹ سے مطابقت رکھتا ہے۔ ان پٹ ساختی پیچیدگی میموری پروردن کی ڈگری کو متاثر کرے گی۔

سرکاری اعلان میں درج ملٹی پارٹ کے مسائل میں شامل ہیں: ابتدائی سائز چیک گیپ جب دستیاب ڈیکلریشن کی لمبائی غائب ہو، کسی ایک حصے کے لیے ہیڈرز کی تعداد کافی حد تک محدود نہیں ہے، اور خالی فائل کنٹرولز اب بھی میٹا ڈیٹا تیار کرتے ہیں، جس میں نیسٹڈ ناموں کے ساتھ سرنی کے کام کا بوجھ مزید بڑھتا ہے۔ ایپلیکیشن کی اپنی ان وائنڈنگ، ڈی کوڈنگ، یا ان پٹ کو دوبارہ تفویض کرنا بھی OOM کا ذریعہ ہو سکتا ہے۔ S2

اس سے دو حفاظتی نتائج اخذ کیے جا سکتے ہیں:

PHP میں داخل ہونے سے پہلے درخواست کی باڈی پابندیوں کو زیادہ سے زیادہ لاگو کیا جانا چاہیے، اور پڑھنے کی اصل لمبائی اور ساختی پیچیدگی پر غور کرنا چاہیے۔
انفرادی طور پر فائل کے سائز، فائلوں کی تعداد، یا صرف ایک اپ لوڈ پورٹل کو بند کرنے سے تمام OOM ذرائع کا احاطہ نہیں کیا جا سکتا۔

درخواست کی تصدیق میں بہت دیر کیوں ہو سکتی ہے۔

mod_php میں، درخواست کے آغاز کے مرحلے کے دوران درخواست کی باڈی خود بخود پارس ہو سکتی ہے۔ یہاں تک کہ اگر اسٹارٹ اپ ناکام ہوجاتا ہے، متعلقہ درخواست کی صفائی اب بھی انجام دی جائے گی۔ اس لیے تصدیق شدہ حملے کے راستے ایپلیکیشن کوڈ سے پہلے ہو سکتے ہیں۔ اس مرحلے پر نمائش کو کم کرنے کے لیے، ریورس پراکسی، Web سرور، یا PHP درخواست کی کارروائی سے پہلے والی دوسری باؤنڈری پر پابندیاں لگانے کی ضرورت ہے۔ S1 S2

2.3 CVE-2026-109619: درخواست میموری جاری کردی گئی ہے، عالمی حوالہ ابھی بھی زندہ ہے

اس مسئلے میں خرابی، سیشن، آبجیکٹ، یا ایکسٹینشن کی حیثیت شامل ہے: فیلڈ کو کارکن کے طویل مدتی رسائی کے مقام میں محفوظ کیا جاتا ہے، لیکن فیلڈ کے ذریعہ حوالہ کردہ ڈیٹا ایک ہی درخواست سے تعلق رکھتا ہے۔ جب تک کہ درخواست کے ڈھیر کے جاری ہونے سے پہلے حوالہ کو صحیح طریقے سے صاف نہیں کیا جاتا ہے، اس کے بعد کی درخواستوں کو ایک لٹکتی ہوئی حالت کا سامنا کرنا پڑ سکتا ہے، جو استعمال کے بعد مفت بنتی ہے۔ S3

سرکاری تجزیہ استحصال کے حالات کو “پیداوار” اور “صارفین” میں تقسیم کرتا ہے:

کردار یا حالت	معنی	تحفظ کے لیے مضمرات
ریاست پروڈیوسر	اس درخواست کی ملکیت والی ریاست کو ایک ایسے مقام پر رکھیں جس تک بعد میں بھی رسائی حاصل کی جا سکے۔	یہ چیک کرنے کے لیے کہ آیا غیر معمولی اخراج کے بعد متعلقہ صفائی مکمل ہو گئی ہے۔
حیثیت باقی ہے۔	اسے صاف نہیں کیا گیا تھا، یا اسے صاف کیا گیا تھا اور پھر دیر سے آپریشن کے ذریعے دوبارہ بھرا گیا تھا۔	شٹ ڈاؤن کے پہلے مرحلے پر صرف ایک بار صاف کرنا کافی نہیں ہو سکتا
کارکن دوبارہ استعمال کریں	وہی کارکن بعد کی درخواستوں پر کارروائی کرتا رہتا ہے۔	ایک سے زیادہ کارکن صرف ایک شیڈولنگ فرق ہے، میموری کی حفاظت کی ضمانت نہیں ہے۔
پیشگی صارف	متعلقہ حالت کو عام طور پر شروع کرنے سے پہلے بقایا قدر کو پڑھیں، جاری کریں یا اس کا تعین کریں۔	شروع کرنے سے پہلے INI، سیشن اور دیگر راستے ضرور چیک کریں۔

ان شرائط کو ملا کر پورا کرنے کی ضرورت ہے۔ کسی بھی غلطی کا لاگ بذات خود یہ ثابت نہیں کرتا کہ کمزوری کا کامیابی سے فائدہ اٹھایا گیا ہے۔ S3

اس کے لیے ضروری شرط کے طور پر OOM کی ضرورت نہیں ہے۔

مہلک غلطیاں ریاستی اشاعت اور بحالی میں خلل ڈال سکتی ہیں۔ تالیف یا تصریف کی ناکامیاں، نہ پکڑی گئی غلطیاں، require ناکامیاں، اور عمل درآمد کا ٹائم آؤٹ خاص ریاستوں کو پیچھے چھوڑ سکتا ہے۔ صفائی میں دیر سے غیر مہلک تشخیصات بھی غلطی کی معلومات کو دوبارہ بھر سکتے ہیں جو پہلے ہی صاف کر دی گئی تھی۔ S3

لہٰذا، memory_limit کو لامحدود میں تبدیل کرنے سے کمزوریوں کے اس سیٹ کا احاطہ نہیں ہوتا ہے۔

“شروع کرنے سے پہلے” کو الگ سے علاج کرنے کی ضرورت ہے۔

دو قسم کے تصدیق شدہ صارفین کا وقت مختلف ہے:

Early INI diagnostics: کچھ کنفیگریشنز درخواست کے مسئلے کی وارننگ، نوٹس یا فرسودگی سے پہلے عام ایگزیکیوٹر کی شروعات سے پہلے لاگو ہوتی ہیں، اور تشخیصی پروسیسنگ پرانی خرابی کی حالت تک رسائی حاصل کر سکتی ہے۔
session upload progress: درخواست کے باڈی پارس کرنے کے عمل کے دوران سیشن پیشگی کارروائی کی جا سکتی ہے، لیکن باقاعدہ ماڈیول 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.2	8.2.35	اس ورژن یا اس کے بعد کے ورژن میں اپ گریڈ کریں جس میں وہی اصلاحات ہوں۔
8.3	8.3.36	اوپر کی طرح
8.4	8.4.27	اوپر کی طرح
8.5	8.5.12	اوپر کی طرح
8.1 اور اس سے پہلے کے ورژن	اپ اسٹریم جنرل سپورٹ ختم ہو گئی ہے۔	معاون شاخوں میں منتقلی کو ترجیح دیں؛ قلیل مدتی چیک ریلیز یا LTS مینوفیکچرر بیک پورٹ

ورژن اور سپورٹ کی حیثیت PHP کے سرکاری اعلان پر مبنی ہے، اور ٹائم بیس لائن 22 اکتوبر 2026 ہے۔ S1

یہ ہیں۔ برانچ کے لیے مخصوص حدیں . ان کو کسی ایسے بیان سے تبدیل نہیں کیا جا سکتا جس کے نیچے ہر ورژن 8.5.12 کمزور ہے: ورژن جیسے 8.2.35 اور 8.4.27 دوسری شاخوں میں پہلے سے ہی اصلاحات موجود ہیں۔

3.2 ڈسٹری بیوشن پیکج کا مکمل ورژن چیک کریں۔

Distros اکثر پرانے اپ اسٹریم ورژنز کی بنیاد پر سیکیورٹی فکسز شامل کرتے ہیں۔ قبولیت کو ریلیز ورژن، ریپوزٹری سورس، مکمل پیکیج ورژن اور سیکیورٹی بلیٹن کو بھی چیک کرنا چاہیے۔

مثال کے طور پر، 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 میں کوڈ کے ٹکڑوں کا مقصد ڈیزائن کو واضح کرنا اور جھلکیوں کا جائزہ لینا ہے اور یہ مکمل پیچ نہیں بناتے ہیں جسے آزادانہ طور پر لاگو کیا جا سکتا ہے۔ S1 S4 S6

4. باقاعدہ مرمت کا عمل

4.1 رن ٹائم کی انوینٹری جو درحقیقت درخواستوں کو ہینڈل کرتی ہے۔

کم از کم ریکارڈ کرنے کے لیے ایک مختصر لیجر بنانے کی سفارش کی جاتی ہے:

اندراج ڈومین نام یا سروس، ریورس پراکسی بیک اینڈ، PHP SAPI.
PHP برانچ، مکمل پیکیج ورژن یا امیج ڈائجسٹ، ماخذ بنائیں۔
FPM pool، اصل سروس یونٹ، کنٹینر یا Pod، نقل کی تعداد۔
ایکسٹینشنز، مین کنفیگریشن اور اضافی کنفیگریشن فائلیں لوڈ کر دی گئی ہیں۔
کیا دیگر PHP ورژن، پرانی تعیناتی کاپیاں، یا اصل پورٹلز ہیں جن تک براہ راست رسائی حاصل کی جا سکتی ہے؟

یہ نفاذ کی تجاویز ہیں تاکہ “اپ گریڈ” ہر حقیقی ٹریفک کے اندراج کے مطابق ہو سکے۔ خاص طور پر چیک کریں کہ آیا کمانڈ لائنز PHP اور Web PHP مختلف ورژن استعمال کرتی ہیں، تصویر بنی ہوئی ہے لیکن پرانا کنٹینر ابھی تک چل رہا ہے، پول کا کچھ حصہ یا کاپی تبدیل نہیں ہوئی، وغیرہ۔

4.2 درست اپ ڈیٹ منتخب کریں اور تعینات کریں۔

سیکشن 3 کے مطابق فکس ورژن کی تصدیق کریں، ترجیحی طور پر موجودہ قابل اعتماد پیکیج سورس یا کنٹرولڈ بلڈ چین کا استعمال کریں۔ اپ ڈیٹ کے دائرہ کار میں وہ جزو شامل ہونا چاہیے جو درحقیقت درخواست کی میزبانی کرتا ہو، جیسے FPM پیکیج، Apache PHP ماڈیول، CGI بائنری، یا سروس کی تعمیر جس میں PHP سرایت شدہ ہے۔

اپ گریڈ کرنے سے پہلے، کنفیگریشن اور پیکج کی فہرست رکھیں، اور پروڈکشن کی طرح کے ماحول میں اسٹارٹ اپ اور کلیدی خدمات کی تصدیق کریں۔ خود کو برقرار رکھنے والے ایکسٹینشنز کے لیے، ورژن PHP کے مطابق تعمیر اور چلائیں مطابقت کو چیک کریں۔ کسی دوسری شاخ سے صرف بظاہر متعلقہ کمٹ کا انتخاب کرنا اس بات کی ضمانت نہیں دیتا کہ اصلاحات کے پورے سیٹ کو لاگو کر دیا گیا ہے۔

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. تخفیف کے اقدامات جب فوری اپ گریڈ ممکن نہ ہو۔

اس سیکشن کا مقصد نمائش میں قلیل مدتی کمی یا دستیابی میں بہتری کے لیے ہے۔ ہر اقدام صرف ایک مخصوص راستے کا احاطہ کرتا ہے، اور متعدد اقدامات کا مجموعہ مکمل مرمت کے مترادف نہیں ہے۔ S1 S2 S3

5.1 PHP سے پہلے ٹریفک کنٹرول کو ترجیح دیں

اگر سروس اس کی اجازت دیتی ہے، تو عارضی طور پر حساس اینڈ پوائنٹس کو قابل اعتماد ذرائع تک محدود رکھیں یا PHP سے پہلے رسائی کنٹرول کو نافذ کریں۔ اپ لوڈ کام کے بوجھ کے لیے، درخواست کے جسم کا سائز، فیلڈ کی گنتی، حصے کی گنتی، فی حصہ ہیڈر، اور گھونسلے کی گہرائی کو محدود کریں۔ جن خدمات کو ملٹی پارٹ کی ضرورت نہیں ہے وہ فرنٹ اینڈ پر اسے مسترد کر سکتی ہیں۔ S2

یہ پابندیاں PHP کے تمام داخلی راستوں کا احاطہ کرتی ہیں۔ صرف “اپ لوڈ” نامی URL کو روکنے سے دیگر اندراجات چھوٹ جائیں گے جو ابھی بھی درخواست کے باڈی میں PHP کے ذریعہ خود بخود پارس ہیں۔ ٹکڑوں کی منتقلی، دستیاب اعلان شدہ لمبائی کی کمی، وغیرہ جیسے معاملات کے لیے، حد اصل پڑھنے کے سائز پر مبنی ہونی چاہیے۔ مواد کو دوبارہ ڈیکمپریس یا توسیع کرتے وقت ایپلیکیشن کا اپنا آؤٹ پٹ سائز بجٹ بھی ہونا چاہیے۔

5.2 FPM pool کنفیگریشن ٹیمپلیٹ

مندرجہ ذیل سیٹنگز کو FPM pool کنفیگریشن سیکشن میں رکھیں جو درحقیقت کی درخواستیں پیش کرتا ہے، php.ini میں لفظ بہ لفظ نہیں۔ 8M اور 4M قدریں کام کے بوجھ کو ایڈجسٹ کرنے کی مثالیں ہیں۔ پوری POST درخواست کو محدود کرتے وقت فارم فیلڈز اور ملٹی پارٹ باؤنڈریز کے لیے جگہ چھوڑ دیں۔ S11 S12

; 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 دستی دیکھیں۔ S1 S2 S3 S11

مینجمنٹ لیول 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 کے برعکس، صرف php.ini میں memory_limit=-1 سیٹ کرنا ایپ کو دوبارہ ترمیم کرنے سے نہیں روکتا ہے۔ فریم ورک، ایپلیکیشن کوڈ، اور دیگر کنفیگریشنز کو یہ دیکھنے کے لیے چیک کیا جانا چاہیے کہ آیا انھوں نے محدود قدر کو دوبارہ ترتیب دیا ہے۔ جب نفاذ کی ضرورت ہو، موجودہ SAPI کے لیے مناسب انتظامی سطح کی ترتیبات استعمال کریں اور اصل مؤثر قدر کی جانچ کریں۔ S11 S12

fatal_error_backtraces = Off صرف PHP 8.5 کے لیے شامل کریں۔ اپ لوڈ کی پیشرفت کو غیر فعال کرنے کے لیے ایپلیکیشن کی سطح کے ini_set() کو حل کے طور پر استعمال نہ کریں، اور درخواست کی تجزیہ سے پہلے اسے مؤثر بنانے کے لیے FPM .user.ini پر انحصار نہ کریں۔ S1 S3

5.3 PHP میموری کی حدود کو ہٹانے کی لاگت کا انتظام کریں

memory_limit=-1 غیر فکسڈ ماحول کے لیے ایک عارضی راستہ تخفیف ہے اور اسے طویل مدتی ڈیفالٹ کنفیگریشن کے طور پر کاپی نہیں کیا جانا چاہیے۔ جب کوئی درخواست یا درخواست قابو سے باہر ہو جاتی ہے، تو یہ میزبان کی زیادہ میموری استعمال کر سکتی ہے۔ اس لیے، استعمال سے پہلے، آپ کو کنکرنسیوں کی تعداد، چوٹی کے واحد کارکن، اور کل سروس کی گنجائش کا اندازہ لگانا چاہیے، اور فرنٹ اینڈ ان پٹ کی حدیں متعین کرنا چاہیے۔ S2

کنٹینر یا سی گروپ میموری کی حدیں دستیابی کی حدود فراہم کر سکتی ہیں لیکن اس بات کی ضمانت نہیں دیتی کہ مختص کبھی ناکام نہیں ہوں گے۔ مکمل کنٹینر، ماسٹر، اور تمام کارکن کو بھی ختم کیا جا سکتا ہے جب حد کو متحرک کیا جاتا ہے۔ Isolation granularity اور ختم کرنے کی حکمت عملیوں کو تعیناتی کے ساتھ مل کر جانچنے کی ضرورت ہے اور اسے ان دونوں 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 میں اثر انداز ہوتا ہے اسے موجودہ وراثت اور کوریج کے تعلقات کے ساتھ مل کر چیک کرنے کی ضرورت ہے۔ S13 S14

صرف اس صورت میں جب کاروبار کو multipart کی ضرورت نہ ہو، آپ متعلقہ سروس کے داخلے پر مسترد کرنے کا اصول شامل کر سکتے ہیں:

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 سے زیادہ ہے، تب بھی دوبارہ استعمال کی درخواست کی ونڈو موجود ہے۔ S3 S11

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 کی ترتیب اور کمزوری کے طریقہ کار کی بنیاد S2 S3 S12 میں مل سکتی ہے۔ کوریج، قبولیت اور اجازت کی حدود کے بارے میں فیصلے ان میکانزم کے ذریعے پیش کردہ نفاذ کی تجاویز پر مبنی ہیں۔

6. سرکاری پیچ کے نفاذ کے خیالات اور جائزہ کے نکات

6.1 درست برانچ کے لیے مکمل اصلاحات کا استعمال کریں۔

PHP 8.5 کے لیے نمائندہ آفیشل جمع کرانا ہے:

31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout

کمٹ واضح طور پر دو CVEs کو جوڑتا ہے، دونوں OOM ایگزٹ میکانزم کو ایڈجسٹ کرنے اور عالمی حالت کو ٹھیک کرنے کے لیے جس تک ابتدائی مرحلے کے دوران رسائی حاصل کی جا سکتی ہے۔ مکمل فرق کے ساتھ صفحہ جمع کرائیں S4 S5 دیکھیں۔ دیگر برانچوں کو اپنی سرکاری حفاظتی ریلیز یا مماثل پیچ استعمال کرنے چاہئیں، اور یہ فرض نہیں کیا جا سکتا کہ 8.5 میں ہونے والی تبدیلیوں کو براہ راست کسی پرانے ورژن پر لاگو کیا جا سکتا ہے۔

6.2 OOM مرمت: پہلے قابل عمل حالت کو بحال کریں، اور پھر درخواست کو ختم کریں

باضابطہ نفاذ میں نرم اور سخت OOM پروسیسنگ کی دو سطحیں متعارف کرائی جاتی ہیں: جب نرم حد تک پہنچ جاتی ہے، تو زیر التواء حیثیت کو ریکارڈ کیا جاتا ہے، اور ایک محفوظ مقام جیسے VM پر کنٹرول شدہ اخراج انجام دیا جاتا ہے۔ ناکام مختص انٹرفیس کالر کو واضح طور پر ناکامی کو سنبھالنے کی اجازت دیتا ہے۔ ایسے مختص کرنے کے لیے جو براہ راست ناکامی کو واپس نہیں کر سکتے، اگر ایک اعلیٰ سخت حد سے تجاوز کرنے کی توقع کی جاتی ہے، تو اس عمل کو براہ راست ختم کر دیا جائے گا تاکہ غیر محفوظ درمیانی حالت میں درخواستوں پر کارروائی جاری رکھنے سے بچا جا سکے۔ S2 S5

زیر التواء OOM کو نشان زد کرنے کے لیے 8.5 diff میں کلیدی کوڈ کا ایک اقتباس درج ذیل ہے:

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

VM مداخلت ہینڈلنگ اور دیگر محفوظ مقامات بعد میں zend_handle_delayed_oom() کو کال کرتے ہیں۔ اس کے صارف کوڈ پر عمل درآمد کا سیاق و سباق ایک کنٹرول شدہ unwind پاتھ کا استعمال کرتا ہے۔ سخت OOM راستہ _exit(137) کو کال کرتا ہے۔ S5

ڈیزائن کے نقطہ نظر سے، اہم تبدیلیاں یہ ہیں: avoids من مانی طور پر C کال اسٹیک کو عبور کرتے ہیں جب ڈھانچہ درمیانی حالت میں ہوتا ہے، اور ایگزٹ کو ایک ایسے مقام پر رکھتا ہے جو ریاست کی رکاوٹوں کو برقرار رکھ سکتا ہے۔ نرم حد کے متحرک ہونے کے بعد، اس عمل کو مکمل کرنے کے لیے اضافی میموری کی ضرورت پڑ سکتی ہے، اس لیے نئی نرم حد کو عمل کی کل میموری کے لیے مطلق اوپری حد کے طور پر نہیں سمجھا جا سکتا۔

اور نہ ہی اس کا خلاصہ یہ کیا جا سکتا ہے کہ “PHP نے تمام zend_bailout() کو حذف کر دیا ہے”۔ پیچ اب بھی مخصوص سیاق و سباق میں متعلقہ میکانزم استعمال کرتا ہے۔ جو چیز طے کی گئی ہے وہ ہے باہر نکلنے کا خطرناک وقت اور اس کے ساتھ ریاستی انتظام۔ S5

6.3 ایلوکیشن کالرز اور ملٹی پارٹ پارس کو ایک ساتھ اپ ڈیٹ کریں۔

اگر آپ صرف ایک مختص فنکشن کو “ناکامی پر NULL واپس کریں” میں تبدیل کرتے ہیں اور اصل کالر پھر بھی یہ فرض کرتا ہے کہ ایک درست پوائنٹر ہمیشہ واپس کیا جاتا ہے، تو آپ نئے 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.c` کا راستہ بند کریں۔	HTTP 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() کے ساتھ تبدیل کرنا، یا کسی مخصوص اندراج پر صرف ایک null پوائنٹر چیک شامل کرنا، مختلف ایگزیکیوشن سیاق و سباق کی ایک بڑی تعداد پر محیط ہوگا۔ وہ دیگر اسٹیٹس فیلڈز کو چھوڑ سکتے ہیں، یا وہ تباہی، توسیعی کال بیکس، پروسیس ہوسٹنگ، اور اختتامی سیمنٹکس کی درخواست کر سکتے ہیں۔

تعاون یافتہ ورژنز کے لیے، مکمل اصلاحات جو پہلے ہی جاری کی جا چکی ہیں، کو ترجیح دی جاتی ہے۔ اپنی شاخوں کی منتقلی کو پیچ کے ماخذ، قابل اطلاق بیس لائنز، تنازعات سے نمٹنے اور رویے میں تبدیلیوں کو ریکارڈ کرنا چاہیے، اور متعلقہ اپ اسٹریم ریگریشن کے استعمال کے معاملات اور اس کاروباری عمل کی تصدیق کا استعمال کرنا چاہیے۔ یہاں کی تجاویز ایلوکیٹر، VM، سیشن اور درخواست کے لائف سائیکل میں تبدیلیوں کے لیے پیچ کے دائرہ کار کے تجزیہ سے آتی ہیں۔ S4 S5

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

برانچ لنکس کے لیے، S7 S8 S9 دیکھیں۔ یہ اس خطرے کے لیے ہنگامی ترسیل ہیں اور یہ پرانی برانچ کے لیے باقاعدہ اپ اسٹریم سپورٹ کی واپسی کی نمائندگی نہیں کرتی ہیں، اور نہ ہی یہ دیگر سیکیورٹی اپ ڈیٹس کی جگہ لیتی ہیں۔ S1

7.1 مثال کے طور پر PHP 8.1 بیک پورٹ لیں

PHP 8.1 کے لیے متعلقہ گذارشات ہیں:

1d7dec178a094e6e75b229ce22754045f8c6070a

اس کی حکمت عملی تیزی سے ناکام ہونے کی حمایت کرتی ہے: متعلقہ OOM راستے میں تشخیص کو آؤٹ پٹ کرنے کے بعد _exit(1) کو کال کرنا، اور عالمی حیثیت اور دیگر متعلقہ اصلاحات سمیت؛ سیشن اپ لوڈ کی پیشرفت کی متعلقہ پروسیسنگ کو اندرونی طور پر غیر فعال کرتے ہوئے متعلقہ سورس کوڈ جمع کرانے کے لیے، S6 دیکھیں۔

یہ معاون برانچ میں زیادہ مکمل تاخیر والے OOM ڈیزائن سے رویے کا فرق ہے۔ صرف اس لیے کہ کنفیگریشن اب بھی ظاہر کرتی ہے کہ اپ لوڈ کی پیشرفت جاری ہے، اس کا مطلب یہ نہیں ہے کہ اس بیک پورٹ کے بعد اندرونی پروسیسنگ کا رویہ تبدیل نہیں ہوگا۔

7.2 وہ قیمت جو آپ کو تعینات کرتے وقت قبول کرنی ہوگی۔

عمل سے براہ راست باہر نکلنا موجودہ درخواست کے ناکام ہونے کا سبب بن سکتا ہے، عام PHP شٹ ڈاؤن کال بیکس کو چھوڑنا اور ایپلیکیشن بند ہونے کا کچھ حصہ۔ اگر میزبان تھریڈ ماڈل کو اپناتا ہے، تو یہ بھی ضروری ہے کہ دوسرے ہم آہنگی کے کام پر میزبان کے پورے عمل سے باہر نکلنے کے اثرات کا جائزہ لیا جائے۔ آیا پروسیس مینیجر وقت پر تبدیلی کے عمل کو آگے بڑھا سکتا ہے یہ بھی تصدیق میں شامل ہونا چاہیے۔

لہذا، پرانے ورژن کے صارفین کو ترتیب میں غور کرنا چاہئے:

تعاون یافتہ PHP برانچ اور اس کے فکسڈ ورژن میں منتقل کریں۔
ایسی ریلیز کا استعمال کریں جو واضح طور پر CVE یا LTS مینوفیکچرر اپ ڈیٹ دونوں کا احاطہ کرے۔
اگر یہ واقعی سورس کوڈ کے پرانے ورژن سے مشروط ہے تو، مکمل تبدیلیوں اور مطابقت کی تصدیق کے لیے مماثل ورژن کا آفیشل ایمرجنسی بیک پورٹ استعمال کریں، اور بعد میں منتقلی کا بندوبست کریں۔

یہاں “کم سے کم بیک پورٹ” اہلکار کی طرف سے منتخب کردہ مطابقت اور نفاذ کے دائرہ کار کی وضاحت کرتا ہے، اور اسے خود بخود “معلوم نامکمل خطرے سے متعلق اصلاحات” کے طور پر نہیں سمجھا جانا چاہئے۔ آپ کو متعلقہ برانچ کے سورس کوڈ اور مینوفیکچرر کے اعلان کی بنیاد پر فیصلہ کرنا چاہیے، اور خود سے معاون تبدیلیوں کو حذف نہ کریں۔ S1 S6

8. قبولیت کے معیار اور فالو اپ معائنہ

یہ سفارش کی جاتی ہے کہ اس مرمت کو مکمل کرنے کے لیے درج ذیل نتائج کو بنیاد کے طور پر استعمال کیا جائے۔

قبولیت کی اشیاء	تکمیل کے معیارات
خطرے کی کوریج	تعمیر یا وینڈر کا اعلان واضح طور پر CVE-2026-109618 اور CVE-2026-109619 کو ٹھیک کرتا ہے
تعیناتی کی کوریج	تمام پورٹلز، پول، خدمات اور نقلیں مرمت شدہ رن ٹائم کا استعمال کرتی ہیں۔
عمل اثر انداز ہوتا ہے۔	پرانا کارکن، پرانا میزبان عمل اور پرانا کنٹینر سب باہر نکل جاتے ہیں۔
مستند درخواست کی تصدیق	تصدیق شدہ SAPI، کیشے کی غلط سمت کو ختم کرنے کے لیے اصل Web لنک کے ساتھ بنایا اور کنفیگر کیا گیا
کاروبار کی دستیابی	کلیدی فنکشنز جیسے سیشن، اپ لوڈنگ، امپورٹنگ، اور ایرر ہینڈلنگ معمول کے مطابق لوٹ آئے ہیں۔
عارضی اقدامات کا خاتمہ	لامحدود میموری اور انتہائی ورکر ری سائیکلنگ کنفیگریشنز کو صلاحیت کے منصوبے کے مطابق بحال کیا گیا ہے یا برقرار رکھنے کی واضح وجہ ہے
تبدیلی کا ثبوت	پیکیج ورژن یا امیج ڈائجسٹ، اپ ڈیٹ اسکوپ، تکمیل کا وقت اور تصدیقی نتائج ریکارڈ کریں۔

اوپر عمل درآمد کے لیے تجاویز ہیں۔ اگر آپ کو OOM رویے، غیر معمولی اخراج، یا اپنی مرضی کے پیچ کی تصدیق کرنے کی ضرورت ہے، تو آپ کو ایک الگ تھلگ ماحول میں اپ اسٹریم ریگریشن ٹیسٹنگ یا کنٹرولڈ فالٹ انجیکشن کا استعمال کرنا چاہیے تاکہ پیداواری ماحول میں بار بار میموری کی تھکن پیدا کرنے سے بچایا جا سکے۔

تازہ کاری سے پہلے اور بعد میں PHP مہلک، کارکن کریش، غیر معمولی دوبارہ شروع، درخواست کی غلطی کی شرح اور WAF واقعات کو بھی چیک کریں۔ لاگز صرف تفتیشی اشارے فراہم کر سکتے ہیں: OOM کے ہونے کا مطلب یہ نہیں ہے کہ اس کا استحصال کیا گیا ہے، اور الارم کی کمی یہ ثابت نہیں کرتی ہے کہ کوئی استحصال نہیں ہوا ہے۔ اپ گریڈ کمزوری کے راستوں کو ٹھیک کرتا ہے جن تک مستقبل میں پہنچا جا سکتا ہے۔ اگر فائل میں چھیڑ چھاڑ یا اسناد کے اخراج جیسی بے ضابطگیاں پائی جاتی ہیں تو واقعے کی الگ الگ تحقیقات کی جانی چاہئیں۔

ضمیمہ: حوالہ کردہ ذرائع اور لنکس

تمام سورس لنکس ذیل میں جمع کیے گئے ہیں۔ مشورے، پیچ، اور وینڈر کی رہنمائی October 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 آفیشل ایمرجنسی بیک پورٹ جمع کروانا

ماخذ: php/php-src.
جمع کروائیں: 1d7dec178a094e6e75b229ce22754045f8c6070a۔
مقصد: پرانی شاخوں کے فوری اخراج کو چیک کریں اور پیش رفت کے رویے میں تبدیلیاں اپ لوڈ کریں۔
حوالہ: PHP 8.1 Emergency backport submission
حوالہ: corresponds to complete diff

S7 — PHP 7.4 آفیشل ایمرجنسی بیک پورٹ برانچ

ماخذ: php/php-src, PHP سورس کوڈ کی شاخیں آفیشل سیکیورٹی بلیٹن میں درج ہیں۔
حوالہ: PHP-7.4-CVE-2026-109618-109619

S8 — PHP 8.0 آفیشل ایمرجنسی بیک پورٹ برانچ

ماخذ: php/php-src, PHP سورس کوڈ کی شاخیں آفیشل سیکیورٹی بلیٹن میں درج ہیں۔
حوالہ: PHP-8.0-CVE-2026-109618-109619

S9 — PHP 8.1 آفیشل ایمرجنسی بیک پورٹ برانچ

ماخذ: php/php-src, PHP سورس کوڈ کی شاخیں آفیشل سیکیورٹی بلیٹن میں درج ہیں۔
حوالہ: PHP-8.1-CVE-2026-109618-109619

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 کور INI کنفیگریشن دستی

ماخذ: PHP سرکاری دستاویز۔
مقصد: درخواست کے باڈی، اپ لوڈ، میموری اور خودکار POST پڑھنے کی ترتیب کی تعریف اور دائرہ کار۔
حوالہ: Description of core php.ini directives

S13 — Nginx باڈی سائز کی حد کی درخواست کریں۔

ماخذ: Nginx سرکاری دستاویز۔
مقصد: client_max_body_size کا معنی اور دستیاب کنفیگریشن لیولز۔
حوالہ: ngx_http_core_module / client_max_body_size

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

ماخذ: Nginx سرکاری دستاویز۔
مقصد: fastcgi_request_buffering کی پروسیسنگ کی ترتیب اور فنکشن۔
حوالہ: ngx_http_fastcgi_module / fastcgi_request_buffering

S15 — Nginx حالت اور واپسی کی ہدایات

ماخذ: Nginx سرکاری دستاویز۔
مقصد: if اور return کا کنفیگریشن نحو۔
حوالہ: ngx_http_rewrite_module

S16 — Cloudflare PHP2Shell تحفظ کی ہدایات

ماخذ: Cloudflare آفیشل بلاگ۔
مقصد: اس کے WAF کی تعیناتی کے دائرہ کار کی تفصیل، Free منصوبہ بندی اور پتہ لگانے کے طریقہ کار۔
حوالہ: Cloudflare deploys protections against php2shell vulnerability