ServiceNow کی تین critical خامیاں؛ self-hosted instances فوراً patch کریں

ServiceNow نے 27 اگست 2026 کو AI Platform کی تین critical خامیوں—CVE-2026-18885، CVE-2026-18886 اور CVE-2026-74820—کی اصلاح جاری کی۔ ServiceNow کی August 2026 advisory کے مطابق کمپنی نے hosted instances پر security update تعینات کر دیا ہے اور partners اور self-hosted customers کو بھی update فراہم کیا ہے۔

تینوں خامیاں network کے ذریعے authentication یا صارف کی مداخلت کے بغیر exploit ہو سکتی ہیں اور کامیاب حملہ arbitrary code execution، privilege escalation یا database میں غیر مجاز SQL چلانے تک پہنچ سکتا ہے۔ BleepingComputer کی 28 اگست کی رپورٹ کے مطابق self-hosted منتظمین کو اپنی release family اور branch سے درست patched build ملا کر خود نصب کرنا ہوگا۔

فوری خطرہ کن instances کے لیے ہے

خطرہ ایسے ServiceNow AI Platform deployments کے لیے ہے جو متاثرہ Xanadu، Yokohama، Zurich یا Australia branch پر مقررہ fixed build سے پرانا ورژن چلا رہے ہیں۔ internet-facing ہونا حملے کی سطح بڑھاتا ہے، لیکن صرف public endpoints کو دیکھنا کافی نہیں؛ partner networks یا کسی دوسرے غیر معتبر network سے قابلِ رسائی self-hosted instance بھی جانچ میں شامل ہونا چاہیے۔

تینوں CVEs کا CVSS v4.0 base score 10.0 ہے۔ ان کے metrics میں attack vector network، attack complexity low، attack requirements none، privileges required none اور user interaction none درج ہیں۔ اس کا مطلب یہ نہیں کہ ہر غیر patch شدہ instance compromise ہو چکا ہے: 28 اگست تک ServiceNow نے ان خامیوں کے malicious exploitation سے آگاہ نہ ہونے کی بات کہی تھی۔ NHS England Digital کا 28 اگست کا alert بھی تینوں مسائل، ان کے 10.0 scores اور فوری متعلقہ updates لگانے کی ہدایت کی تصدیق کرتا ہے۔

تینوں CVEs کا administrator matrix

• CVE-2026-18885 — code injection: خامی GraphQL Composite Data API سے متعلق ہے۔ مخصوص حالات میں unauthenticated network attacker arbitrary code چلا کر instance data تک مقررہ حدود سے زیادہ رسائی حاصل یا اسے تبدیل کر سکتا ہے۔ prerequisite کے طور پر account، session یا user interaction درکار نہیں۔ اصلاح: اپنی release family اور branch کے لیے نیچے درج fixed build یا اس کے بعد کا supported release نصب کریں۔ Validation: مکمل build identifier کی تصدیق کے بعد مجاز GraphQL integrations کے regression tests چلائیں اور upgrade کے بعد API یا code-execution errors کا جائزہ لیں۔
• CVE-2026-18886 — improper access control: مسئلہ system configuration image upload processor میں ہے۔ مخصوص حالات میں unauthenticated attacker مقررہ اجازت سے باہر instance data بنا یا تبدیل کر سکتا ہے، جس کے نتیجے میں privilege escalation ممکن ہے۔ login یا صارف کی مداخلت شرط نہیں۔ اصلاح: اسی family اور branch کا متعلقہ fixed build یا نیا supported release لگائیں۔ Validation: مجاز image-upload workflow درست چلنے، anonymous requests مسترد ہونے اور غیر متوقع privileged records یا configuration changes نہ ہونے کی جانچ کریں۔
• CVE-2026-74820 — SQL injection: خامی Dynamic Schema کے ORDER BY clause سے متعلق ہے۔ مخصوص حالات میں unauthenticated attacker underlying database کے خلاف arbitrary SQL statements چلا کر intended controls سے باہر instance data پڑھ یا تبدیل کر سکتا ہے۔ account اور user interaction درکار نہیں۔ اصلاح: متعلقہ branch کا fixed build یا بعد کا supported release نصب کریں۔ Validation: build number کے ساتھ معمول کی Dynamic Schema query operations آزمائیں اور database errors یا غیر معمولی query activity کا جائزہ لیں۔

یہ operational validation exploit کی نقل نہیں ہے۔ production instance پر public proof-of-concept یا غیر منظور شدہ payload چلانے کے بجائے vendor-supported update، منظور شدہ change window اور الگ test environment استعمال کیا جانا چاہیے۔

اپنی release family کے لیے درست fixed build

تینوں CVEs کے لیے fixed-version فہرست یکساں ہے، مگر درست target موجودہ family، patch line اور branch پر منحصر ہے۔ “prior to” threshold کا مطلب ہے کہ درج build یا اس کے بعد کا supported build درکار ہے؛ مختلف branches کے تمام hotfix ایک ہی instance پر سلسلہ وار لگانے کی checklist نہیں ہیں۔

• Xanadu: Patch 11 Hot Fix 7a۔
• Yokohama: Patch 12 branch کے لیے Patch 12 Hot Fix 3b؛ Patch 13 branch کے لیے Patch 13 Hot Fix 4۔
• Zurich: موجودہ branch کے مطابق Patch 7b Hot Fix 3، Patch 8 Hot Fix 5، Patch 9 Hot Fix 6، Patch 10 Hot Fix 2m (m-branch)، Patch 10 Hot Fix 3 (standard)، Patch 11 یا Patch 12۔
• Australia: موجودہ branch کے مطابق Patch 2 Hot Fix 3، Patch 3 Hot Fix 2، Patch 3m، Patch 4 یا Patch 5۔

خصوصاً Zurich Patch 10 میں m-branch اور standard branch کے الگ targets ہیں۔ منتظم کو پہلے installed release، patch، hotfix اور branch کا مکمل identifier لینا چاہیے، پھر عین اسی line کا مساوی یا بعد کا vendor-supported patched release منتخب کرنا چاہیے۔ صرف family کا نام، package کا download یا upgrade job کا کامیاب آغاز remediation کا ثبوت نہیں ہے۔

اگر installed build فہرست سے صاف طور پر match نہ ہو تو قریب دکھائی دینے والا hotfix اندازے سے منتخب نہ کریں۔ branch-specific compatibility اور supported upgrade path کے لیے ServiceNow support سے تصدیق ضروری ہے، بالخصوص جب custom applications یا integrations براہِ راست upgrade کو پیچیدہ بناتی ہوں۔

Patch کے بعد مختصر validation ترتیب

1. Build evidence محفوظ کریں: upgrade سے پہلے اور بعد کا مکمل release، patch، hotfix اور branch identifier change record میں درج کریں۔ نئے identifier کو متعلقہ fixed threshold سے دوبارہ ملائیں۔
2. تمام nodes کی حالت دیکھیں: clustered deployment میں تصدیق کریں کہ ہر application node مطلوبہ build پر واپس آ چکا ہے اور کوئی node نامکمل upgrade، rollback یا پرانے package پر نہیں رہا۔
3. متعلقہ workflows آزمائیں: ادارے میں استعمال ہونے والی GraphQL Composite Data API integrations، مجاز configuration image upload اور Dynamic Schema queries کے focused regression tests چلائیں۔ tests کو business functionality کے ساتھ access controls بھی جانچنے چاہییں۔
4. Audit records کا جائزہ لیں: patch سے پہلے کے ممکنہ exposure period اور maintenance window میں anonymous API requests، غیر متوقع configuration changes، نئے privileged records، database errors اور غیر معمولی query patterns تلاش کریں۔ صاف logs عدمِ compromise کا قطعی ثبوت نہیں، لیکن incident triage کے لیے اہم evidence ہیں۔
5. Exposure inventory دوبارہ ملائیں: reverse proxy، load balancer، firewall اور partner-facing routes کے پیچھے موجود تمام self-hosted nodes کی فہرست بنائیں، تاکہ کوئی بھولا ہوا endpoint پرانے build پر قابلِ رسائی نہ رہ جائے۔

Custom integration کی وجہ سے patch میں تاخیر ہو تو network access محدود کرنا عارضی دفاع ہو سکتا ہے، مگر vendor patch کا مستقل متبادل نہیں۔ اسی طرح patch نصب کرنا پہلے سے حاصل کردہ attacker access یا persistence خود بخود ختم ہونے کی ضمانت نہیں دیتا؛ مشکوک activity ملنے پر incident-response طریقۂ کار الگ چلانا ہوگا۔

Hosted اور self-hosted ذمہ داری کہاں الگ ہے

ServiceNow-hosted instances پر vendor نے security update تعینات کر دیا ہے، اس لیے وہاں package deployment کی بنیادی ذمہ داری ServiceNow کی تھی۔ تاہم customer کو اپنے instance کا موجودہ status، اہم integrations اور relevant audit evidence دیکھنا چاہیے، خصوصاً اگر patch سے پہلے غیر معمولی activity کا کوئی اشارہ موجود ہو۔

Self-hosted اور partner-managed ماحول میں update کا دستیاب ہونا اور production پر نصب ہونا دو الگ حالتیں ہیں۔ remediation تب مکمل سمجھی جا سکتی ہے جب درست branch کا patched build تمام متعلقہ nodes پر چل رہا ہو، اہم workflows کامیاب ہوں اور exposure inventory میں کوئی پرانا قابلِ رسائی instance باقی نہ ہو۔

28 اگست 2026 تک تینوں CVEs شائع شدہ، critical اور بغیر authentication قابلِ استحصال قرار دی گئی تھیں، مگر ServiceNow کو ان کے malicious exploitation کی اطلاع نہیں تھی۔ اگلی اہم تبدیلی active exploitation، technical indicators یا مزید branch-specific guidance کی صورت میں آ سکتی ہے؛ موجودہ شواہد کے مطابق self-hosted administrators کے لیے فوری کام درست fixed release نصب کرنا اور اس کی کامیاب deployment کی تصدیق ہے۔

یہ بھی پڑھیں:

• ServiceNow کے تین flaws کا اسکور 10.0—کون سے instances خطرے میں ہیں؟
• PaperCut zero-day زیرِ حملہ—Release 2 patch کیوں ضروری ہے؟