22 ستمبر 2026 کو، قومی دن کی تعطیل سے ایک دن پہلے، WordPress نے CVE-2026-87902 کو بند کرنے کے لیے سیکیورٹی اپ ڈیٹ 7.1.2 جاری کی۔ یہ خامی کسی پلگ اِن یا تھیم میں نہیں ہے۔ یہ WordPress کے کور میں ہے، اور 4.7.0 سے 7.1.1 تک کے ہر ورژن کو متاثر کرتی ہے۔ اسی دن 11:49 UTC پر (ریاض کے وقت کے مطابق دوپہر 2:49 بجے) سیکیورٹی کمپنی Patchstack نے اس سے فائدہ اٹھانے کی پہلی کوشش دیکھی، اور چار گھنٹے سے بھی کم عرصے بعد کسی سائٹ کے سرور پر فائل لکھنے کی پہلی کوشش۔

پانچ دنوں میں حملہ کیسے پھیلا

پھر یہ پھیل گیا۔ آج، 28 ستمبر کو شائع ہونے والی CrowdSec کی رپورٹ کے مطابق، اس کے نیٹ ورک نے 23 سے 27 ستمبر کے درمیان 30,813 مختلف IP ایڈریسز سے اس خامی سے مطابقت رکھنے والے 322,680 حملے کے سگنل ریکارڈ کیے، جو 27 ستمبر کو 124,154 سگنلز کے ساتھ عروج پر پہنچے۔ سعودی عرب کی نیشنل سائبر سیکیورٹی اتھارٹی (NCA) نے 23 ستمبر کو سنگین درجے کا الرٹ، نمبر 2026-7873، جاری کیا، اور امریکی ادارے CISA نے 25 ستمبر کو اس خامی کو معلوم استحصال شدہ کمزوریوں کی اپنی فہرست میں شامل کیا۔

آسان الفاظ میں یہ خامی کیا کرتی ہے

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

یہ سائٹ پر کنٹرول میں تب بدلتی ہے جب WordPress کی ایڈوائزری اور محققین کی رپورٹوں میں بیان کردہ شرائط ایک ساتھ پوری ہوں:

  • تھیم: فعال تھیم میں ایک فولڈر ہے جس کا نام page- سے شروع ہوتا ہے۔ ایڈوائزری ایسی تھیموں میں Twenty Twelve، Twenty Fourteen، Neve، Hestia اور Sydney کا ذکر کرتی ہے۔
  • ایک PHP سیٹنگ: register_argc_argv آن ہے، جو CrowdSec کے مطابق سرکاری PHP Docker امیجز میں اور 8.5 سے پرانے PHP والے cPanel سرورز پر ڈیفالٹ ہے۔
  • ایک معاون فائل: PEAR کی pearcmd.php سرور پر موجود ہے۔ حملہ آور اسے نئی PHP فائلیں لکھنے کے لیے استعمال کرتے ہیں، یعنی ایک بیک ڈور جو اپ ڈیٹ کے بعد بھی باقی رہتا ہے۔

لہٰذا یہ خامی ہر سائٹ کو یکساں طور پر متاثر نہیں کرتی، لیکن Security Affairs اسے یوں سمیٹتا ہے: کوڈ چلانے کے لیے سرور کی ترتیب کا موافق ہونا ضروری ہے، اور بہت سے سرورز میں یہ موافق ہوتی ہے۔ کاروبار کے مالک کو عموماً معلوم نہیں ہوتا کہ کون سی تھیم فعال ہے یا سرور کیسے کنفیگر کیا گیا ہے، اس لیے محفوظ مفروضہ یہی ہے کہ جب تک اس کے برعکس ثابت نہ ہو، سائٹ خطرے میں ہے۔

حملہ ہفتوں میں نہیں بلکہ گھنٹوں میں کیوں آیا

سیکیورٹی اپ ڈیٹ اپنی فطرت کے لحاظ سے ہی ظاہر کر دیتی ہے کہ بگ کہاں ہے، کیونکہ کوڈ میں تبدیلی عوامی ہوتی ہے۔ Patchstack کا کہنا ہے کہ پہلے پے لوڈز بالکل اسی پیٹرن سے مطابقت رکھتے تھے جسے اصلاح نے بند کیا تھا، یعنی انہیں لکھنے والے نے کسی آزادانہ دریافت سے نہیں بلکہ خود اصلاح سے کام شروع کیا۔ پہلی کوششوں میں یہ دیکھنے کے لیے کہ سائٹس کیسا ردعمل دیتی ہیں، wp-login.php اور wp-cron.php جیسی عام WordPress کور فائلیں طلب کی گئیں، اور پھر فائلیں لکھنے کی طرف بڑھا گیا۔

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

کیا آپ کی سائٹ خود بخود اپ ڈیٹ ہوتی ہے؟

شاید، لیکن یہ فرض نہ کریں۔ WordPress میں ورژن 3.7 سے خودکار بیک گراؤنڈ اپ ڈیٹس موجود ہیں، اور 5.6 سے نئی انسٹالیشنز معمولی اور بڑی دونوں ریلیزز کو خود بخود اپ ڈیٹ کرتی ہیں۔ 7.1.2 کے اعلان میں کہا گیا ہے کہ جو سائٹس خودکار بیک گراؤنڈ اپ ڈیٹس کو سپورٹ کرتی ہیں وہ خود بخود اپ ڈیٹ ہونا شروع ہو جائیں گی۔

لیکن خودکار اپ ڈیٹس wp-config.php میں ایک لائن سے بند کی جا سکتی ہیں۔ کچھ ڈویلپرز انہیں جان بوجھ کر بند کرتے ہیں تاکہ کوئی اپ ڈیٹ حسبِ ضرورت تبدیل کی گئی تھیم کو خراب نہ کر دے، اور کچھ ہوسٹنگ کمپنیاں اپ ڈیٹس اپنی طرف سے سنبھالتی ہیں۔ برسوں پہلے کسی فری لانسر کی بنائی ہوئی سائٹ، جس کا معاہدہ کب کا ختم ہو چکا ہو، کسی پرانے ورژن پر پڑی رہ سکتی ہے اور کسی کو پتا بھی نہیں چلتا۔ چیک کرنے کے لیے:

  • سائٹ کے ایڈمن میں لاگ اِن کریں، ڈیش بورڈ مینو کے تحت اپ ڈیٹس کا صفحہ کھولیں، اور وہاں آپ کو موجودہ ورژن نظر آئے گا۔
  • محفوظ ورژن 7.1.2 یا اس کے بعد کا ہے۔ اگر آپ کی سائٹ کسی پرانی برانچ پر ہے تو اصلاح 4.7 تک کی ہر برانچ تک پہنچی ہے، جن میں 7.0.6، 6.9.9، 6.8.10 اور 4.7.37 شامل ہیں؛ مکمل فہرست ذرائع میں دیے گئے لنک والی WordPress ایڈوائزری میں ہے۔
  • نوٹ کریں کہ WordPress کے مطابق صرف تازہ ترین ورژن کو ہی فعال سپورٹ حاصل ہے۔ پرانی برانچ پر چھوڑی گئی سائٹ کو یہ اصلاح تو مل گئی، لیکن وہ ادھار کے وقت پر چل رہی ہے۔ نیا ورژن کسی کمپنی کی ویب سائٹ کے لیے کیا لاتا ہے، یہ ہم نے WordPress 7.1: اہم نئی خصوصیات میں بیان کیا ہے۔

Elementor بھی: ایک لنک کافی ہے

اسی ہفتے، مقبول WordPress پیج بلڈر Elementor نے ایک خامی درست کی جو صرف ورژن 4.3.0 اور 4.3.1 میں تھی۔ اگر کوئی سائٹ ایڈمنسٹریٹر لاگ اِن ہوتے ہوئے خاص طور پر تیار کیا گیا لنک کھولتا ہے تو حملہ آور اپنے کنٹرول والا ایڈمنسٹریٹر اکاؤنٹ بنا سکتا ہے، اور یہ لنک ای میل، چیٹ یا تبصرے کے ذریعے آ سکتا ہے۔ BleepingComputer کے مطابق یہ ورژن 2 ملین تک سائٹس پر چلتے ہیں۔ اصلاح 24 ستمبر کو 4.3.2 میں آئی، اور اشاعت کے وقت اس سائٹ نے کسی فعال استحصال کی اطلاع نہیں دی تھی۔

یقینی بنائیں کہ Elementor ورژن 4.3.2 یا اس کے بعد کا ہو، اور اسے ٹیم کا اصول بنا دیں: سائٹ کے ایڈمن میں لاگ اِن ہوتے ہوئے پیغامات یا تبصروں کے لنک نہ کھولیں۔

اگر آپ کی سائٹ 22 ستمبر سے اپ ڈیٹ نہیں ہوئی

  • ابھی اپ ڈیٹ کریں: اگر ڈویلپر کو ڈر ہے کہ اپ ڈیٹ سے کچھ خراب ہو جائے گا تو Patchstack کے مطابق pagename پیرامیٹر میں ڈائریکٹری ٹریورسل کی کوششوں کو بلاک کر کے، یا register_argc_argv کو بند کر کے یہ راستہ عارضی طور پر بند کیا جا سکتا ہے۔ یہ ہوسٹنگ کمپنی یا ڈویلپر کا کام ہے، اور یہ اپ ڈیٹ کا متبادل نہیں۔
  • فرض کریں کہ آپ کی سائٹ کی ٹوہ لی جا چکی ہے: ڈویلپر یا ہوسٹنگ کمپنی سے ایسی PHP فائلیں تلاش کرنے کو کہیں جو کسی نے شامل نہیں کیں، خاص طور پر /tmp اور /var/tmp میں، جہاں Patchstack نے poc87902.php اور wp-pear-rce-flag.php جیسی فائلوں کو کامیاب کوڈ ایگزیکیوشن کی علامت بتایا ہے۔
  • اگر کچھ ملے: اسے اپ ڈیٹ نہیں بلکہ ایک واقعہ سمجھ کر نمٹائیں۔ ایڈمن اکاؤنٹس، ڈیٹا بیس اور ہوسٹنگ کے پاس ورڈ تبدیل کریں، سائٹ کو کسی صاف بیک اپ سے بحال کریں، پھر اسے اپ ڈیٹ کریں۔
  • اگر سائٹ میں صارفین کا ڈیٹا ہے: یعنی وہ آرڈرز، رابطہ فارم یا اکاؤنٹس محفوظ کرتی ہے، تو سعودی ڈیٹا اینڈ آرٹیفیشل انٹیلیجنس اتھارٹی (SDAIA) کی ذاتی ڈیٹا کی خلاف ورزی کے واقعات سے متعلق رہنما کتاب کے مطابق کنٹرولر پر لازم ہے کہ وہ کسی ایسی خلاف ورزی کا علم ہونے کے 72 گھنٹوں کے اندر متعلقہ اتھارٹی کو مطلع کرے جو ڈیٹا یا اس کے مالکان کو نقصان پہنچا سکتی ہو۔

Origami کا نقطۂ نظر

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

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

خلاصہ: تین اقدامات

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

ذرائع