اگر آپ نے PHP2Shell کمزوری کے بعد اپنی کمپنی کی ویب سائٹ کو PHP 8.5.12، 8.4.27، 8.3.36 یا 8.2.35 پر اپ ڈیٹ کر لیا ہے تو آپ نے درست قدم اٹھایا، لیکن اس سے سب کچھ محفوظ نہیں ہوتا۔ 23 اکتوبر 2026 کو PHP پروجیکٹ نے ایک تیسری کمزوری CVE-2026-115560 کے بارے میں نئی وارننگ جاری کی، جسے 21 اکتوبر کا اپ ڈیٹ ٹھیک نہیں کرتا۔ اس کے لیے غیر معمولی کنفیگریشن درکار ہے اور PHP اسے حملے کا کم امکان والا راستہ سمجھتا ہے، لیکن عارضی حل آسان ہے: آج ہی اپنی ٹیم یا ہوسٹ سے کہیں کہ session.upload_progress.enabled کو 0 پر سیٹ کریں اور PHP کو ری اسٹارٹ کریں، پھر تحریری طور پر تصدیق لیں کہ 21 اکتوبر کا اپ ڈیٹ واقعی لاگو ہو چکا ہے۔

PHP نے 23 اکتوبر کو کیا اعلان کیا؟

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

کاروبار کے مالک کے لیے دو باتیں اہم ہیں۔ پہلی، یہ ایک الگ کمزوری ہے، اس لیے اوپر دیے گئے چار ورژنز میں سے کوئی ایک چلانا اکیلے کافی نہیں۔ دوسری، یہی عارضی اقدام 21 اکتوبر کو CVE-2026-109619 کی ایڈوائزری میں پہلے سے درج تھا۔ اگر آپ کی ٹیم نے اسی وقت اسے لاگو کر دیا تھا تو کچھ نیا کرنے کی ضرورت نہیں: اسے ویسے ہی رہنے دیں۔

کیا آپ کی سائٹ خطرے میں ہے؟

PHP کی وارننگ کے مطابق مسئلہ صرف اس وقت پیدا ہوتا ہے جب تین شرائط ایک ساتھ پوری ہوں:

  • PHP کنفیگریشن session.serialize_handler کو php_binary یا php_serialize پر سیٹ کرتی ہے۔
  • ایپلیکیشن کا کوڈ سیشن شروع ہونے سے پہلے ini_set() کے ذریعے رن ٹائم پر اسے php میں بدل دیتا ہے۔
  • سیشن اپ لوڈ پیش رفت کی ٹریکنگ اب بھی آن ہے، جو بطور ڈیفالٹ آن رہتی ہے۔

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

تین دن بعد: تصدیق کریں کہ 21 اکتوبر کا اپ ڈیٹ واقعی لاگو ہوا

اصل کمزوریاں CVE-2026-109618 اور CVE-2026-109619 اب بھی بڑا خطرہ ہیں۔ سعودی عرب کی نیشنل سائبر سکیورٹی اتھارٹی (NCA) نے ان کے بارے میں وارننگ نمبر 2026-7949 جاری کی، اور امریکی ادارے CISA نے مشورہ دیا کہ تمام PHP سسٹمز کی فہرست بنائیں، انٹرنیٹ سے جڑے سسٹمز کو پہلے پیچ کریں، اور جو سسٹم فوراً پیچ نہ ہو سکے اسے آف لائن کر دیں۔ CISA نے کہا کہ اشاعت کے وقت تک اس نے کوئی کامیاب حملہ نہیں دیکھا تھا، لیکن اس کا مطلب یہ نہیں کہ وقت آپ کے حق میں ہے۔

تین باتیں جنہیں بہت لوگ نظر انداز کر دیتے ہیں:

  • ری لوڈ نہیں، ری اسٹارٹ۔ Red Hat کے بلیٹن میں کہا گیا ہے کہ کنفیگریشن میں تبدیلی کے لیے PHP پروسیسز کو ری اسٹارٹ کرنا ضروری ہے اور صرف ری لوڈ کافی نہیں۔
  • Linux سرورز پر ورژن نمبر مختلف ہو سکتا ہے۔ PHP کے اعلان کے مطابق Linux ڈسٹری بیوشنز کو پیچ پہلے ہی مل گئے تھے، اس لیے اصلاح لاگو ہونے کے باوجود آپ کو مثال کے طور پر 8.5.12 سے مختلف نمبر نظر آ سکتا ہے۔ اپنے ہوسٹ سے صرف نمبر نہیں، تحریری تصدیق مانگیں۔ Red Hat بتاتا ہے کہ RHEL 8، 9 اور 10 سب متاثر ہیں۔
  • PHP کس طرح چلتا ہے، اس سے خطرہ بدلتا ہے۔ PHP پروجیکٹ Apache پر mod_php کے لیے خطرہ سب سے زیادہ سمجھتا ہے، جبکہ Red Hat کہتا ہے کہ ڈیفالٹ PHP-FPM کے ساتھ عملی طور پر حملہ کرنا زیادہ مشکل ہے۔ مشکل کا مطلب ناممکن نہیں، اس لیے دونوں صورتوں میں اپ ڈیٹ ضروری ہے۔

آج اپنے ہوسٹ یا ٹیم کو بھیجنے کے لیے 5 سوال

  1. ہماری ہر سائٹ اور ہر سسٹم پر PHP کا کون سا ورژن چل رہا ہے، اور کیا اس میں 21 اکتوبر 2026 کی اصلاحات شامل ہیں؟
  2. کیا اپ ڈیٹ کے بعد PHP پروسیسز کو صرف ری لوڈ نہیں بلکہ ری اسٹارٹ کیا گیا؟
  3. کیا ہم نے session.upload_progress.enabled کو 0 پر سیٹ کیا ہے؟ اگر نہیں، تو کیا ہمیں واقعی اس فیچر کی ضرورت ہے؟
  4. کیا ہماری سائٹ کا کوڈ رن ٹائم پر session.serialize_handler بدلتا ہے؟
  5. کیا ہماری کوئی سائٹ 8.1 یا اس سے پرانے ورژن پر ہے؟ ان شاخوں کو اب سپورٹ نہیں ملتی، اور معاون ورژنز کی جدول دکھاتی ہے کہ 8.2 کی سکیورٹی سپورٹ 31 دسمبر 2026 کو ختم ہو رہی ہے۔

Origami کا نقطۂ نظر

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

سعودی کمپنیوں میں ہم دیکھتے ہیں کہ مشکل سوال «کمزوری کیا ہے؟» نہیں بلکہ «ہمارے ہاں کون جمعہ کی صبح PHP کی وارننگ پڑھتا ہے اور جانتا ہے کہ کون سا سرور ہمارا ہے؟» ہوتا ہے۔ Origami میں ہم ویب سائٹس اور سسٹمز بناتے ہیں اور پہلے دن سے ان کے اپ ڈیٹس کی نگرانی کرتے ہیں۔ اگر آپ اپنی سائٹ کی جانچ کروانا چاہتے ہیں، یا سروس روکے بغیر یہ سیٹنگز لاگو کروانا چاہتے ہیں تو ہم سے رابطہ کریں۔

خلاصہ

21 اکتوبر کا اپ ڈیٹ ناگزیر ہے اور اب بھی سب سے اہم ہے؛ نئی وارننگ اسے نہیں بدلتی۔ آج اس میں ایک سستا قدم شامل کریں: اگر ضرورت نہ ہو تو اپ لوڈ پیش رفت کی ٹریکنگ بند کریں، PHP ری اسٹارٹ کریں اور اپنے ہوسٹ سے تحریری تصدیق لیں۔ پھر PHP کی اگلی باقاعدہ ریلیز پر نظر رکھیں، جو CVE-2026-115560 کی حتمی اصلاح لائے گی۔

ذرائع