اگر آپ کی کمپنی کی ویب سائٹ یا آن لائن اسٹور WordPress، Magento، Laravel یا PHP پر بنے کسی اور سسٹم پر چلتا ہے، تو آج ہی اپنے ہوسٹنگ فراہم کنندہ یا تکنیکی ٹیم سے کہیں کہ PHP کو ورژن 8.5.12، 8.4.27، 8.3.36 یا 8.2.35 پر اپ ڈیٹ کریں اور پھر سرور دوبارہ شروع کریں۔ PHP پروجیکٹ نے یہ ورژن 21 اکتوبر 2026 کو جاری کیے تاکہ PHP2Shell نامی دو سنگین خامیاں بند کی جا سکیں۔ دونوں کو 10 میں سے 9.2 درجہ دیا گیا ہے، اور یہ حملہ آور کو کسی پاس ورڈ کے بغیر آپ کے سرور پر کمانڈز چلانے دیتی ہیں۔ سعودی عرب کی نیشنل سائبر سیکیورٹی اتھارٹی (NCA) نے اسی دن اپ ڈیٹ کی سفارش کرتے ہوئے «انتہائی سنگین» درجے کا انتباہ جاری کیا، اور سیکیورٹی کمپنیوں نے درستی جاری ہونے سے کئی گھنٹے پہلے ہی حملے کی کوششیں دیکھیں۔

اصل میں کیا ہوا؟

دونوں خامیاں CVE-2026-109618 اور CVE-2026-109619 ہیں، اور یہ کسی پلگ ان یا تھیم میں نہیں بلکہ خود PHP زبان میں ہیں۔ یہی سب سے بڑا فرق ہے: حملہ آوروں کا نقشہ بن جانے والی WordPress کی درستیوں پر ہمارے پچھلے مضمون میں خرابی اس سافٹ ویئر میں تھی جو PHP کے اوپر چلتا ہے۔ یہاں خرابی اس بنیاد میں ہے جس پر وہ سارا سافٹ ویئر کھڑا ہے۔ اس لیے تازہ ترین WordPress یا کم پلگ ان آپ کو محفوظ نہیں رکھتے۔

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

Wiz Research نے AI ماڈلز کی مدد سے یہ خامیاں دریافت کیں۔ اس کی رپورٹ کہتی ہے کہ ٹیم نے انہیں 19 اگست 2026 کو دریافت کیا، 24 اگست کو PHP ٹیم کو اطلاع دی، اور 5.4 سے اب تک کا ہر PHP ورژن ان میں سے کم از کم ایک سے متاثر ہے۔ Wiz کا اندازہ ہے کہ تقریباً 70% ویب سائٹس PHP پر چلتی ہیں۔

کیا میری سائٹ متاثر ہے؟

اگر وہ PHP پر چلتی ہے اور اس کا ورژن اوپر دیے گئے ورژنز سے پرانا ہے، تو غالب امکان ہے کہ ہاں۔ Wiz نے ڈیفالٹ سیٹ اپ والے WordPress، Drupal اور Joomla پر بغیر لاگ ان ریموٹ کوڈ چلا کر دکھایا۔ Sansec نے اپنے تجزیے میں فہرست کو 11 پلیٹ فارمز تک بڑھایا، جن میں Magento 2.4.9، WordPress 7.1.2، Laravel 13.11، Symfony 8.1، phpMyAdmin، Nextcloud اور WHMCS شامل ہیں۔

اپنا PHP ورژن جاننے کے لیے ہوسٹنگ پینل (cPanel، Plesk یا اسی طرح کا کوئی) کھولیں اور «PHP Version» تلاش کریں، یا اپنی ٹیم سے پوچھیں۔ دو باتوں کا خیال رکھیں:

  • ورژن 8.1 اور اس سے پرانے اب سپورٹ میں نہیں ہیں اور انہیں کوئی درستی نہیں ملے گی۔ PHP کے سپورٹ شدہ ورژنز کے جدول کے مطابق، اس وقت صرف 8.2، 8.3، 8.4 اور 8.5 برانچز سپورٹ میں ہیں۔
  • خود 8.2 برانچ کی سیکیورٹی سپورٹ 31 دسمبر 2026 کو، یعنی ڈھائی مہینے بعد، ختم ہو جائے گی۔ اگر آپ ابھی اپ ڈیٹ کر رہے ہیں تو 8.4 یا 8.5 پر جائیں اور جلد ہی دوسرے اپ گریڈ سے بچیں۔

آج کیا کریں: پانچ اقدامات

  1. معلوم کریں کہ PHP کہاں کہاں چلتا ہے۔ ویب سائٹ، اسٹور، ایڈمن پینل، اور کوئی بھی اندرونی سسٹم یا کسٹمر پورٹل۔ بہت سی کمپنیاں کسی پرانی سائٹ کو بھول جاتی ہیں جو اب بھی آن لائن ہے۔
  2. درست کیے گئے ورژن پر اپ ڈیٹ کریں۔ 8.5.12، 8.4.27، 8.3.36 یا 8.2.35۔ شیئرڈ ہوسٹنگ پر اپنے فراہم کنندہ سے تحریری طور پر پوچھیں: کیا آپ نے 21 اکتوبر کی اپ ڈیٹ لاگو کر دی ہے؟
  3. اپ ڈیٹ کے بعد PHP دوبارہ شروع کریں۔ PHP ایڈوائزری بتاتی ہے کہ جو پروسیس دوبارہ شروع نہیں کیا گیا وہ پرانے کوڈ پر ہی چلتا رہتا ہے، اس لیے صرف اپ ڈیٹ ڈاؤن لوڈ کرنا کافی نہیں۔
  4. اگر آپ کی سائٹ 8.1 یا اس سے پرانے ورژن پر ہے، تو اسی ہفتے اپ گریڈ کی منصوبہ بندی کریں اور پہلے کسی اسٹیجنگ کاپی پر آزمائیں، کیونکہ کچھ پرانے پلگ ان کام کرنا بند کر سکتے ہیں۔
  5. لاگز چیک کریں۔ Wiz مشورہ دیتا ہے کہ غیر معمولی اپ لوڈ درخواستوں کے بعد آنے والی میموری ختم ہونے کی غلطیاں، بار بار آنے والی HTTP 500 غلطیاں، یا بہت بڑی یا بگڑی ہوئی سیشن کوکیز (PHPSESSID) تلاش کریں۔

اگر آج اپ ڈیٹ نہیں کر سکتے

PHP ایڈوائزریز کچھ عارضی اقدامات تجویز کرتی ہیں جو خطرہ کم کرتے ہیں مگر اپ ڈیٹ کی جگہ نہیں لیتے: session.upload_progress.enabled کو 0 کر کے بند کریں اور تمام پروسیس دوبارہ شروع کریں، اور ورژن 8.5 پر fatal_error_backtraces کو 0 کریں۔ اگر آپ کی سائٹ کبھی فائل اپ لوڈ قبول نہیں کرتی تو فرنٹ اینڈ سرور پر multipart درخواستیں بھی بلاک کر سکتے ہیں۔

اگر آپ کی سائٹ Cloudflare کے پیچھے ہے، تو کمپنی اپنے بلاگ میں کہتی ہے کہ اس نے 21 اکتوبر کو UTC 3:02 سے ان خامیوں کے لیے فائر وال قواعد نافذ کیے، یعنی انکشاف سے تقریباً 9 گھنٹے پہلے، اور مفت سمیت تمام پلانز پر۔ لیکن Cloudflare خود مشورہ دیتی ہے کہ اس تحفظ کے باوجود PHP اپ ڈیٹ کریں، کیونکہ حملہ آور مسلسل اپنے طریقے بدل رہے ہیں۔

Origami کی رائے

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

ذرائع