ذرائع 23 اکتوبر 2026 تک چیک کیے گئے (UTC) کوریج کی مدت: 25 جولائی تا 23 اکتوبر 2026، ستمبر سے اکتوبر تک نئے اعلانات اور اس کے بعد کے پیچ پر توجہ مرکوز کرتے ہوئے۔ سامعین: انجینئرز اور سیکیورٹی جواب دہندگان جو Node.js، Java، Python خدمات، کنٹینرز، پائپ لائنز کی تعمیر اور ترقیاتی ماحول کو برقرار رکھتے ہیں۔

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

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

TL؛ DR: تدارک کی ترجیحات

  1. رن ٹائم کو اپ ڈیٹ کریں جو اصل میں پہلے سروس کی میزبانی کرتا ہے۔ متعلقہ کو اپ ڈیٹ کریں۔ Node.js کم از کم شاخ 22.23.4 / 24.22.1 / 26.12.1 . خدمات کا استعمال کرتے ہوئے Node 24 تک اپ گریڈ کر سکتے ہیں۔ 24.22.1 اسی بڑے ورژن یا بعد کے ورژن کے اندر جس میں وہی اصلاحات شامل ہیں۔ S1 S2
  2. اپڈیٹ کریں۔ Node درخواست پر انحصار الگ سے۔ کے لیے Next.js ، استعمال کریں۔ 15.5.28 / 16.4.1 اپ گریڈ بیس لائن کے طور پر؛ استعمال کرتے وقت React Server Components آزادانہ طور پر، اصل انسٹال کی جانچ پڑتال کریں react-server-dom-* پیکج صرف اپ ڈیٹ کر رہا ہے۔ Node بائنری ان فریم ورک کی کمزوریوں کا احاطہ نہیں کرتا ہے۔ S8 S9 S10 S11 S12
  3. Java : اپ ڈیٹس کے دونوں دور کا احاطہ کریں۔ 20 اکتوبر دونوں پر محیط ایک وینڈر بلڈ انسٹال کریں۔ CPU اور 21 اکتوبر CVE-2026-91403 ہنگامی سرٹیفکیٹ-ٹرسٹ فکس. سیکشن دیکھیں 2.2 کے لیے Oracle JDK 11 -27 آؤٹ آف بینڈ ورژن؛ ان کے اپنے حفاظتی پیکجوں اور مکمل تعمیر نمبروں کے خلاف دیگر تقسیم کی تصدیق کریں۔ متعلقہ کو اپ ڈیٹ کریں۔ Tomcat کی شاخ 9.0.123 / 10.1.61 / 11.0.27 . S16 S17 S18 S20 S21 S22 S23
  4. Python : مترجم، ایپلیکیشن پیکجز اور سرٹیفکیٹ پیکجز کو الگ الگ اپ ڈیٹ کریں۔ سیکشن دیکھیں 2.3 مترجم کی بنیادی خطوط کے لیے؛ certifi سفارش کرتا ہے ≥ 2026.10.19 , pip ≥ 26.2.2 ، استعمال کرتے وقت uv ≥ 0.13.4 . ہر موجودہ venv کو چیک کرنے کی ضرورت ہے۔ کے لیے wrap_bio() متعلقہ کوڈز، درست اور غیر خالی server_hostname میں بھی پاس ہونا ضروری ہے. S29 S30 S31 S33 S35 S36 S37
  5. اگر فوری طور پر اپ گریڈ کرنا ناممکن ہے، تو متعلقہ انٹری پوائنٹس پر نمائش کو کم کریں۔ غیراعتماد کو روکنے کو ترجیح دیں۔ Brotli ضابطہ کشائی، متاثرہ امیج/پیجنگ/آرکائیونگ پروسیسنگ، اور الگ تھلگ مسئلہ LDAP یا تصدیقی اندراجات؛ رکھنا TLS تصدیق شدہ سرٹیفکیٹس اور میزبان نام۔ ان باؤنڈ WAF آؤٹ باؤنڈ راستوں کا احاطہ نہیں کر سکتا جیسے کہ ایپلی کیشنز جو بدنیتی پر مبنی کمپریسڈ ردعمل کو کھینچتی ہیں۔ S3 S11 S25 S27 S30 S32
  6. دوبارہ تعمیر کریں، پرانے عمل کو تبدیل کریں، اور حقیقی خدمت کے راستوں سے تصدیق کریں۔ لاک فائل اور امیج ڈائجسٹ کو محفوظ کریں، ایپلیکیشن اور امیج کو دوبارہ بنائیں، تمام ورکرز کے لیے تبدیلیاں رول آؤٹ کریں/ JVM /کنٹینرز؛ اصل عمل، انحصار کا درخت، ٹرسٹ اسٹور اور بزنس ریگریشن ٹیسٹ چیک کریں۔ اکیلے ایک نیا کمانڈ لائن ورژن یہ ثابت نہیں کرتا ہے کہ تدارک مکمل ہے۔
  7. اگر LiteLLM 1.107.0 انسٹال یا چلایا گیا تھا، واقعے کے جواب کے طریقہ کار پر عمل کریں۔ پروجیکٹ نے 21 اکتوبر کو ریلیز کے سمجھوتے کی تصدیق کی۔ متاثرہ ماحول کو الگ تھلگ کریں، صاف ستھرے ماحول سے تفتیش کریں، بے نقاب اسناد کو دوبارہ بنائیں اور گھمائیں۔ شروع نہ کریں۔ Python/pip پہلے چیک کرنے کے لیے مشکوک ماحول میں۔ تفصیلات کے لیے سیکشن 9 دیکھیں۔ S41

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

1.1 اصل نمائش کے ذریعے علاج کو ترجیح دیں۔

ذیل میں تعیناتی کی ترجیحات نفاذ کی رہنمائی ہیں۔ شدت کے لیبل ہر وینڈر کی پیروی کرتے ہیں، بشمول Apache کی Important ریٹنگ۔ CVSS 3.1 اور 4.0 اسکورنگ کے مختلف نظام ہیں۔ صرف اسکور کے حساب سے مسائل کی درجہ بندی نہ کریں۔

ماحولیاتی نظام / پرتکلیدی مسائلسرکاری گریڈ یا تصدیق شدہ سکورترجیحی تعیناتی۔
Node.js مقامی انحصارCVE-2026-111497: Brotli حد سے باہر لکھا گیا ہے، اور RCE کا خطرہ ہے۔Node：HighBrotli ڈیٹا S1S3 کو خارجی درخواست کے باڈی یا بیرونی جواب میں ڈی کوڈ کریں
Node.js TLS / DNSCVE-2026-105482, 105483, 106069: تجزیہ اور شناخت کی تصدیق متضاد ہیںHighURL کرال، پراکسی، Webhook، متحرک ہدف کا پتہ S1S5S6
Node.js HTTP/2CVE-2026-56846, 56848: یادداشت ختم اور UAFHighNode غیر بھروسہ مند HTTP/2 ٹریفک S7 کو براہ راست ہینڈل کرتا ہے
React / Next.jsRSC / use cache typed arrays RCECritical；CVSS 4.0 9.5سرور RSC، متعلقہ کیشے کے اجزاء اور ڈیٹا پاتھ S9S10
Next.js امیج آپٹیمائزیشنCVE-2026-96889: SVG تصویری پروسیسنگ RCECritical；CVSS 4.0 9.5glibc Linux پر مثالیں جو ناقابل اعتماد تصاویر کو سنبھال سکتی ہیں S11
Next.js Server Actionsخصوصی طور پر تیار کردہ درخواست CPU کے ختم ہونے کا سبب بنتی ہے۔High；CVSS 4.0 8.2App Router اور کم از کم ایک Server Action S12
Java TLS ٹرسٹCVE-2026-91403: متاثرہ انٹرمیڈیٹ CA پر اعتماد کرنا جاری رکھیںCVSS 3.1 9.1TLS/API منظر نامہ S17 متاثرہ ٹرسٹ چین کا استعمال کرتے ہوئے
TomcatJNDIRealm توثیق بائی پاس، HTTP/2 کراس ریکوئسٹ مکس اپس، AJP رسپانس لیکیجImportantRealm / Connector / async Servlet راستے کے مطابق S21S22S23
Spring for GraphQLCVE-2026-59285: صفحہ بندی ڈی سیریلائزیشن RCEHighJackson 2 + Connection پیجنگ + قابل استعمال کلاس پاتھ S25
Spring SecurityCVE-2026-59270: ایمبیڈڈ LDAP معروف انتظامی شناخت بے نقابCriticalایمبیڈڈ LDAP فعال ہے اور سننے والی بندرگاہ حملہ آور S27 کے لیے قابل رسائی ہے
CPython sslCVE-2026-19445: SNI سیاق و سباق کو تبدیل کرنے کے نتیجے میں UAFCriticalPython خود سے TLS کو ختم کرتا ہے، اور سیاق و سباق کی زندگی کی شرط S29 کو پورا کرتا ہے
CPython sslCVE-2026-19553: جب میزبان نام غائب ہو تو تصدیق کو چھوڑ دیں۔Highwrap_bio() / متعلقہ asyncio کال غائب متوقع میزبان نام S30
CPython tarfileCVE-2026-82049: ہارڈ لنک اور علامتی لنک کا امتزاج بائی پاسHighخودکار طور پر ناقابل اعتماد ٹار آرکائیو S32 نکالیں۔
Django / GeoDjangoCVE-2026-15307: مقامی سوال لکھنے کی فائل، SSRF، شرط RCE کے تحتHighمقامی سوالات یا متعلقہ ایڈمنسٹریشن انٹرفیس ناقابل اعتماد ان پٹ S38 کو قبول کرتے ہیں
Python سرٹیفکیٹ انحصارcertifi: emSign متعلقہ سرٹیفکیٹ عدم اعتمادCritical; GHSA، کوئی نہیں معلوم CVETLS کلائنٹ اور پیکیج مینجمنٹ ٹول S36S37 ابھی بھی متاثرہ CA bundle استعمال کر رہا ہے

مخففات: RCE کا مطلب ریموٹ کوڈ پر عمل درآمد، UAF کا مطلب ہے استعمال کے بعد مفت، اور SSRF کا مطلب ہے سرور سائیڈ درخواست کی جعلسازی۔ RCE کی براہ راست اجازتیں عام طور پر درخواست کی میزبانی کرنے والے عمل کی اجازتیں ہوتی ہیں اور خود بخود روٹ پرمیشنز کے مساوی نہیں ہو سکتیں۔

تجویز کردہ ترتیب: پہلے RCE کو ہینڈل کرتا ہے، جو بیرونی طور پر قابل رسائی ہے اور شرائط، تصدیقی بائی پاس، کراس یوزر ڈیٹا لیکیج اور سرٹیفکیٹ کی تصدیق کے مسائل کو پورا کرتا ہے۔ ایک ہی وقت میں، عوام کا سامنا کرنے والے DoS انٹری پوائنٹ کے لیے اپ ڈیٹس کو شیڈول کریں۔ استحصال ثابت کرنے کے لیے پیداوار میں اٹیک پے لوڈ چلانے کی ضرورت نہیں ہے۔ انحصار موجود ہے، کوڈ کے راستے قابل رسائی ہیں، اور حملے کی شرائط پوری ہوتی ہیں۔ یہ تین مسائل ہیں جن کا الگ الگ جائزہ لینے کی ضرورت ہے۔

1.2 تین آسانی سے الجھنے والی حدود

  • رن ٹائمز اور انحصار کو الگ سے اپ گریڈ کریں۔ کے لیے سیکورٹی اپ ڈیٹس Node , JDK , CPython کی اسٹینڈ تنہا تنصیبات کی خود بخود مرمت نہیں کرتا ہے۔ Next.js , Spring , Django , certifi یا مقامی توسیعات۔
  • دی اصلاح کی حد موجودہ تعیناتی بیس لائن سے الگ ہے۔ اگست میں کمزوری کا پہلا پیچ ستمبر سے اکتوبر تک نئے مسائل کا احاطہ کرنے کی ضمانت نہیں دیتا ہے۔ سیکشن 2 عمل درآمد کے ہدف کے طور پر تصدیق شدہ بعد کے اپ ڈیٹس کا استعمال کرتا ہے۔
  • ایک حقیقی سپلائی چین سمجھوتہ سے کمزوری کی تمیز کریں۔ عام کمزوریوں کے لیے، پیچ مستقبل کے حملے کے راستوں کو ختم کرتے ہیں۔ جب بدنیتی پر مبنی پیکجز چلائے جاتے ہیں، تو اسناد اور استقامت کے اثرات کی چھان بین کی ضرورت ہوتی ہے۔ سیکشن 9 LiteLLM سرکاری طور پر تصدیق شدہ واقعہ ہے۔ S41

آیا جنگل میں استحصال کی تصدیق سرکاری انکشافات پر مبنی ہونی چاہیے۔ دکاندار نے استحصالی سرگرمیوں کا ذکر نہیں کیا اور یہ ثابت نہیں کر سکتا کہ کوئی حملہ نہیں ہوا ہے۔ علاج اصل حملے کی سطح کی بنیاد پر کیا جانا چاہئے.

2. فکسڈ ورژن اور تعیناتی بیس لائن کی فوری جانچ

حوالہ: 2.1 Node.js、React、Next.js

جزو/شاختجویز کردہ ورژن بیس لائناستعمال کے لیے ہدایات
Node.js 22.x22.23.421 اکتوبر کو سیکیورٹی ریلیز S1S2
Node.js 24.x24.22.124.x برانچ پر لاگو ہوتا ہے؛ 24.22.0 میں 21 اکتوبر کا سیکیورٹی پیچ S1S2 شامل نہیں ہے۔
Node.js 26.x26.12.1اسی بیچ S1S2 میں سیکیورٹی ریلیز
Node.js 20 اور اس سے پہلے کی اپ اسٹریم برانچزمعاون برانچ میں ہجرت کریں۔Node 20 اس اپ اسٹریم فکس کو قبول نہیں کرتا ہے۔ وینڈر کی توسیعی حمایت کی علیحدہ علیحدہ تصدیق ہونی چاہیے S3
Next.js 15.x15.5.2814 اکتوبر S8 کو اپ ڈیٹ کیا گیا۔
Next.js 16.x16.4.1جیسا کہ اوپر S8 ہے۔
اسٹینڈ اسٹون RSC 19.0 / 19.1 / 19.2 / 19.3 برانچ19.0.9 / 19.1.10 / 19.2.9 / 19.3.1تین react-server-dom-* پیکجوں کو الگ الگ چیک کریں۔ صرف اوپر کی پرت کو نہ دیکھیں react S10
Next نے اصل میں sharp لوڈ کیا ہے۔≥0.35.5SVG خطرے کے لیے سرکاری عارضی فکس شرائط؛ دوسرے Next.js پیچ S11 کو تبدیل نہیں کرتا

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

2.2 Java: اکتوبر CPU پلس آؤٹ آف بینڈ سرٹیفکیٹ اپ ڈیٹ

یہ جدول Oracle JDK پر لاگو ہوتا ہے۔ دوسرا کالم صرف 20 اکتوبر CPU کا احاطہ کرتا ہے۔ تیسرے میں 21 اکتوبر کی آؤٹ آف بینڈ ریلیز شامل ہے۔ صرف CPU ورژنز یہاں زیر بحث تمام Java خطرات کا احاطہ نہیں کرتے ہیں۔ S16S17S18

شاخاکتوبر 20 CPUOracle 21 اکتوبر کو بینڈ سے باہر جاری ہوا۔
1111.0.3311.0.33.0.2
1717.0.2117.0.21.0.2
2121.0.1321.0.13.0.2
2525.0.525.0.5.0.2
2727.0.127.0.1.0.2
88u511پبلک ریلیز ٹیبل اب بھی 8u511 دکھاتا ہے۔ مخصوص سیکیورٹی کی تعمیر اور ٹرسٹ چین کی مرمت کی جانچ ہونی چاہیے، اور صرف مختصر ورژن نمبر کی بنیاد پر اس کا تعین نہیں کیا جا سکتا

**Java 8 کو مکمل تعمیراتی معلومات کے خلاف چیک کرنے کی ضرورت ہے:**Oracle الرٹ 8u511 کو ایک متاثرہ ورژن کے طور پر درج کرتا ہے، اور ریلیز کی فہرست میں اسی مختصر نام کے ساتھ بعد کے اپ ڈیٹس کی فہرست ہے۔ صرف “8u511” مختصر ورژن نمبر کی بنیاد پر پیچ کی حیثیت کی تمیز نہیں کی جا سکتی۔ آپ کو مخصوص سیکیورٹی کی تعمیر اور ٹرسٹ چین کی اصلاحات کی تصدیق کرنی چاہیے۔ S17S18

Temurin , Corretto , Zulu , Microsoft Build of OpenJDK ، ریلیز ورژن OpenJDK وغیرہ، ان کے متعلقہ اعلانات اور مکمل پیکج/بلڈ نمبرز کے مطابق چیک کریں۔ مثال کے طور پر، سرکاری رہائی کا ریکارڈ Adoptium بتاتا ہے کہ متعلقہ تعمیر کو شامل کرنے کے لیے دوبارہ پیک کیا جاتا ہے۔ eMudhra ٹھیک کرنا اپ اسٹریم ورژن کے ایک جیسے نام کا مطلب یہ نہیں ہے کہ پیکیج کا مواد ایک جیسا ہے۔ دی .0.2 لاحقہ قواعد Oracle میکانکی طور پر دوسرے پبلشرز پر لاگو نہیں کیا جا سکتا۔ S20

Java درخواست کے اجزاءتجویز کردہ ورژن بیس لائنریمارکس
Tomcat 9 / 10.1 / 119.0.123 / 10.1.61 / 11.0.27برانچ کی طرف سے برانچ چیک کریں؛ Tomcat 10.0 نے دیکھ بھال روک دی ہے S21S22S23
Spring for GraphQL 2.0.x2.0.5（OSS）تجارتی تعاون بھی 2.0.4.1 S25 ہے
Spring Security 7.1 / 7.07.1.1 / 7.0.7（OSS）اگست میں اعلان کردہ کم از کم فکس ورژن سے مطابقت رکھتا ہے؛ آپ کو تعیناتی سے پہلے بعد کے سیکورٹی بلیٹن S27S28 کو چیک کرنے کی ضرورت ہے
Spring Security 6.5 / 6.4 / 5.8 / 5.76.5.12 / 6.4.19 / 5.8.28 / 5.7.26اعلان تجارتی سپورٹ فکس کے طور پر درج ہے۔ نقل مکانی کا اندازہ اس وقت کیا جاتا ہے جب کوئی متعلقہ معاونت نہ ہو، اور یہ فرض نہیں کیا جا سکتا کہ Maven Central مفت S27 میں دستیاب ہے۔

Spring اپ گریڈز کو پروجیکٹ کے Spring Boot BOM، Java کے کم از کم ورژن اور مطابقت کی لائنوں کا احترام کرنا چاہیے۔ صرف ایک پیچ حاصل کرنے کے لیے تمام Spring ماڈیولز کو ایک ہی نمبر پر براہ راست مجبور نہ کریں۔

2.3 CPython، Django اور سرٹیفکیٹ انحصار

نیچے دیے گئے جدول کا دوسرا کالم اس پر فوکس کرتا ہے۔ TLS ستمبر میں انکشاف کیا گیا مسئلہ؛ برانچ کے فرق tarfile سیکشن میں دکھایا گیا ہے۔ 5.3. 21 اکتوبر کی ریلیز نے بنڈل سرٹیفکیٹ ٹولنگ کو بھی اپ ڈیٹ کیا، لہذا آخری کالم میں بعد میں تعیناتی کی بنیادی لائنیں شامل ہیں۔ S29 S30 S33 S35

CPython برانچستمبر سیکورٹی بیچ کم از کم ورژنتجویز کردہ تعیناتی بیس لائن
3.103.10.22اپ اسٹریم سے آخری ریلیز، EOL؛ منتقلی کا بندوبست کریں یا ریلیز ایکسٹینشن سپورٹ S34 کی تصدیق کریں۔
3.113.11.173.11.17، اور pip/certifi ہر ماحول میں انفرادی طور پر اپ ڈیٹ کریں
3.123.12.153.12.15، اور pip/certifi ہر ماحول میں انفرادی طور پر اپ ڈیٹ کریں
3.133.13.163.13.17
3.143.14.83.14.9
3.15حتمی 3.15.0 ریلیز میں TLS دونوں فکسز S31S47 شامل ہیں3.15.1

3.11 اور 3.12 کے اپ اسٹریم سیکیورٹی ورژن صرف سورس کوڈ میں جاری کیے جا سکتے ہیں۔ آپریٹنگ سسٹم پیکج استعمال کرتے وقت، وینڈر کی بیک پورٹ ایڈوائزری اور مکمل پیکیج ورژن کو چیک کریں، اور سسٹم Python کو زبردستی خود مرتب کردہ ورژن سے تبدیل کرنے کی کوئی ضرورت نہیں ہے۔ S33S34

آزاد انحصارتجویز کردہ ورژن بیس لائنتفصیل
Django 5.2 / 6.0 / 6.15.2.18 / 6.0.9 / 6.1.26 اکتوبر کو بعد کی اصلاح S38S39 شامل کریں
certifi≥2026.10.19GHSA ابتدائی پیچ ہے .18; PSF تجویز کرتا ہے کہ .19 غیر متاثرہ سرٹیفکیٹس کے لیے مطابقت کو محفوظ رکھے S36S37
pip≥26.2.2certifi کی بلٹ ان کاپی الگ سے S35S37 کو اپ ڈیٹ کرنے کی ضرورت ہے
uv (اگر استعمال ہو)≥0.13.4اصل تنصیب کے طریقہ کے مطابق S37 کو اپ ڈیٹ کریں۔

یہ بنیادی خطوط درج کردہ اصلاحات کا احاطہ کرتے ہیں۔ میں درمیانے درجے کی شدت کا ایک اور مسئلہ tar_filter 22 اکتوبر کو انکشاف کیا گیا۔ 23 اکتوبر 2026 تک، اس فکس پر مشتمل ایک آفیشل مینٹیننس ورژن کی ابھی تک تصدیق نہیں ہوئی ہے۔ لہذا، 3.13.17 / 3.14.9 / 3.15.1 یہ نہیں سمجھا جا سکتا کہ تمام ٹارفائل کے مسائل کا احاطہ کیا گیا ہے۔ سیکشن دیکھیں 5.4. S40

2.4 تقسیم کے بیک پورٹ کی تصدیق کر رہا ہے۔

Ubuntu، Debian، RHEL اور دیگر سافٹ ویئر پیکجوں پر لاگو ہونے کے اصول:

  1. آپریٹنگ سسٹم ورژن، ریپوزٹری سورس، مکمل پیکیج ورژن، اور وینڈر سیکیورٹی بلیٹن نمبر ریکارڈ کریں۔
  2. تصدیق کریں کہ ایڈوائزری مخصوص CVE کا احاطہ کرتی ہے اور متعلقہ ڈسٹری بیوشن ریلیز کے لیے ایک مقررہ پیکیج کی نشاندہی کرتی ہے۔
  3. بائنریز/لائبریریوں کا موازنہ کریں جو اصل چلانے کے عمل سے بھری ہوئی ہیں، نہ صرف اپ اسٹریم شارٹ ورژن سے۔
  4. جب وینڈر پیچ کا کوئی ثبوت نہیں ہے، تو اسے “تصدیق کے لیے چھوڑ دیں” اور اسے صرف اس نتیجے کے طور پر نہ لیں کہ ورژن نمبر پرانا یا نیا لگتا ہے۔

apt/RPM پیکج ورژنز اور مختلف ڈسٹری بیوشنز کی بیک پورٹ حکمت عملی میں فرق ہے۔ سیکیورٹی بلیٹن اور ہر تقسیم کا مکمل پیکیج ورژن غالب ہونا چاہیے۔

3. Node.js / JavaScript ماحولیاتی نظام: وجوہات اور تدارک کا تجزیہ

3.1 CVE-2026-111497: Brotli مقامی ڈیکوڈر حد سے باہر لکھیں

انکشاف: 21-10-2026; Node آفیشل گریڈ: High۔ Node 22.x, 24.x, 26.x کی متاثرہ عمارتوں کو پیچ سیکشن 2.1 انسٹال کرنے کی ضرورت ہے۔ Node اعلان میں عددی CVSS سکور درج نہیں ہے۔ S1

خراب شکل والے Brotli کمپریسڈ سٹریم کو ہینڈل کرتے وقت مقامی ضابطہ کشائی کرنے والی منطق میں مسئلہ پیدا ہوتا ہے، جس کی وجہ سے تحریریں حد سے باہر ہو سکتی ہیں۔ Vercel کی باضابطہ وضاحت اس بات کی تصدیق کرتی ہے کہ تحقیقی مظاہرے میں میموری کا اخراج اور کمانڈ پر عمل درآمد شامل ہے۔ آیا حملہ آور ڈیکوڈر تک پہنچ سکتا ہے اس کا انحصار اس بات پر ہے کہ آیا ایپلیکیشن یا انحصار دراصل اس ڈیٹا کو ڈی کوڈ کرتا ہے جسے وہ کنٹرول کرتا ہے۔ S3

دونوں سمتوں کو ایک ہی وقت میں چیک کرنے کی ضرورت ہے:

  • inbound: The فریم ورک یا مڈل ویئر صارف کی طرف سے جمع کرائی گئی Brotli درخواست کی باڈی کو خود بخود ڈیکمپریس کر دیتا ہے۔
  • **outbound:**HTTP کلائنٹس، امیج گرابرز، وغیرہ حملہ آور کے قابل کنٹرول ذرائع تک رسائی حاصل کرتے ہیں اور واپس کیے گئے مواد کو خود بخود ڈیکمپریس کرتے ہیں۔

براؤزرز کو بھیجے گئے جوابات کے Brotli کمپریشن کو غیر فعال کرنے سے ڈی کوڈنگ انٹری پوائنٹ نہیں ہٹتا ہے۔ ان باؤنڈ WAF تحفظ بیرونی ردعمل کی بازیافت اور ضابطہ کشائی کرنے والی ایپلیکیشنز کا احاطہ نہیں کرتا ہے۔ S3

**پیچ کی سمت:**Node Brotli اپ اسٹریم فکس کو مقامی انحصار میں منتقل کریں، اور غیر قانونی ضابطہ کشائی کی حیثیت کی جانچ اور خرابی کے پھیلاؤ کو پورا کریں۔ خود مرتب کردہ ورژن کو برقرار رکھتے وقت، آپ کو آفیشل سیکیورٹی ریلیز یا میچنگ برانچ کا مکمل پیچ استعمال کرنا چاہیے۔ آپ صرف JavaScript پیکیج کے ورژن اسٹیٹمنٹ کو تبدیل نہیں کرسکتے ہیں۔ S4

عبوری عمل درآمد کی تجاویز: غیر ضروری ناقابل اعتماد Brotli ڈی کوڈنگ کو روکیں۔ مڈل ویئر اور HTTP کلائنٹ کے خودکار ڈیکمپریشن رویے کو چیک کریں۔ اگر کاروبار کو اس فارمیٹ کو قبول کرنا ضروری ہے تو جلد از جلد پیچ ​​والے ماحول میں پروسیسنگ مکمل کریں۔ Accept-Encoding کو ایڈجسٹ کرنا محض گفت و شنید کا عمل ہے اور اس بات کے ثبوت کے طور پر اکیلے کھڑے نہیں ہونا چاہیے کہ بدنیتی پر مبنی ردعمل کو روک دیا گیا ہے۔

3.2 TLS / DNS تین High: تصدیقی اعتراض اصل ہدف سے مطابقت نہیں رکھتا

ان تینوں کا انکشاف 21 اکتوبر کو کیا گیا تھا، جس میں سیکشن 2.1. S1 میں سرکاری اپ گریڈ کی حد مقرر کی گئی تھی۔

شناخت کنندہمسئلے کی تصدیق ہو گئی۔متاثرہ شاخیں۔
CVE-2026-105482dns.resolve NUL پر مشتمل ناموں کی کٹوتی22.x / 24.x / 26.x
CVE-2026-105483IP مکمل چوڑائی عددی شکل میں سرٹیفکیٹ کے میزبان نام کی تصدیق کو نظرانداز کرنے کا سبب بنتا ہے24.x / 26.x
CVE-2026-106069میزبان نام جس کو IP کے طور پر سمجھا جا سکتا ہے اس کے نتیجے میں TLS تصدیق بائی پاس22.x / 24.x / 26.x

DNS مسئلہ کا خلاصہ یہ ہے کہ اوپری پرت کے ذریعے چیک کی گئی سٹرنگ اس نام سے مختلف ہے جسے اصل میں نچلی پرت کے ذریعے پارس کیا گیا ہے۔ آفیشل پیچ NUL کو پارسنگ انٹری پر مسترد کرتا ہے اور ریگریشن کوریج کو شامل کرتا ہے۔ S6

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

: کے لیے اصل ٹربل شوٹنگ کی تجاویز وصول کرنے والے صارف URL، ڈائنامک پراکسی ٹارگٹ یا Webhook ایڈریس کے کوڈ کو چیک کرنے کو ترجیح دیتی ہیں۔ متحد معیار سازی اور فہرست کے فیصلے کی اجازت دیتا ہے، NUL/کنٹرول حروف کو مسترد کرتا ہے، قانونی IPv4، IPv6 اور بین الاقوامی ڈومین ناموں کی تصدیق کرتا ہے جو اب بھی کام کرتا ہے۔ آیا SSRF کو مزید تشکیل دیا جا سکتا ہے اس کے لیے لنک ثبوت کی درخواست کی ضرورت ہے، جس کا براہ راست نام CVE سے اخذ نہیں کیا جا سکتا۔

پوسٹ اپ گریڈ چیکسم کی غلطیوں کو ختم کرنے کے لیے NODE_TLS_REJECT_UNAUTHORIZED=0 یا rejectUnauthorized: false استعمال نہ کریں۔ ایڈریس، سرٹیفکیٹ اور بزنس کنفیگریشن کو درست کیا جائے۔

3.3 جولائی HTTP/2 High- خطرہ اور اجازت ماڈل کے مسائل

جولائی میں انکشاف کردہ درج ذیل امور کو ابھی بھی تفتیش میں شامل کرنے کی ضرورت ہے۔ سیکشن 2.1 میں تعینات کرتے وقت اکتوبر کے سیکیورٹی ورژن کی بیس لائن کو براہ راست استعمال کرنے کی سفارش کی جاتی ہے۔ S7

CVEاسباب اور اثراتپہلا فکسڈ ورژن
CVE-2026-56846برقرار رکھا HTTP/2 header بلاک maxSessionMemory بجٹ میں مناسب طریقے سے شامل نہیں ہے اور میموری کو ختم کر سکتا ہے۔ اثر 22.x / 24.x22.23.2 / 24.18.1
CVE-2026-56848HTTP/2 پیکٹ جمع کرنے کے دوران بھیجنے کے راستے میں دوبارہ داخل ہوتا ہے، جس سے UAF کا ڈھیر ہوتا ہے۔ اثر 22.x / 24.x / 26.x22.23.2 / 24.18.1 / 26.5.1
CVE-2026-58043--permission راستے کا سابقہ باؤنڈری میچ بہت وسیع ہے، اور اجازت دی گئی فہرست سے باہر کی فائلوں تک رسائی حاصل کی جا سکتی ہے۔اوپر تین بحالی لائنوں کے طور پر ایک ہی

تینوں سرکاری طور پر High ہیں۔ پہلے دو آئٹمز یہ جانچنے کو ترجیح دیتے ہیں کہ آیا HTTP/2 خود Node کی طرف سے کارروائی کی جاتی ہے؛ اجازت کے ماڈل کا استعمال کرتے ہوئے اور اس حد پر انحصار کرتے وقت تیسری آئٹم کا صرف متعلقہ معنی ہوتا ہے۔ اجازت ماڈل کی تمام اشیاء کو نیٹ ورک RCE کے طور پر بیان نہیں کیا جا سکتا جس کے لیے تصدیق کی ضرورت نہیں ہے۔ S7

عارضی طور پر HTTP/2 کو علیحدہ، اپ ڈیٹ شدہ پراکسی پر ختم کرنا اور بیک اینڈ ذرائع کو محدود کرنا ایکسپوزر کو کم کرنے کے لیے تعیناتی کا اختیار ہے۔ وسائل کے کوٹے صرف وسائل کی تھکن کے نتائج کو کنٹرول کرسکتے ہیں اور UAF کو پیچ نہیں کرسکتے ہیں۔

3.4 اکتوبر React / Next.js: دو آئٹمز RCE اور ایک آئٹم DoS

A. RSC / میں RCE use cache فنکشنز ٹائپ شدہ صفوں کو لوٹ رہے ہیں

عوامی تاریخ: 2026-10-14; Critical, CVSS 4.0 9.5. آفیشل ایڈوائزری شناخت کنندگان:

  • React：GHSA-xqc2-xf4c-x3h3。
  • Next.js：GHSA-673q-mjm6-r5xr。S9S10

دی React upstream کے مسئلے میں حملہ آور کے قابل کنٹرول اقدار کے ساتھ مل کر متعدد ٹائپ شدہ صفیں شامل ہیں RSC جواب تینوں متاثر ہوئے۔ react-server-dom-* پیکیج ورژن ہیں 19.0.0 — 19.0.8 , 19.1.0 — 19.1.9 , 19.2.0 — 19.2.8 , 19.3.0 ; باب سیکشن دیکھیں 2.1. خالص براؤزر سائیڈ React ، یا ایسی ایپلی کیشنز جو سپورٹ کرنے والے فریم ورک/پلگ ان استعمال نہیں کرتی ہیں۔ RSC بالکل، اس شے کے دائرہ کار میں نہ آئیں۔ S10

Next.js ڈاؤن اسٹریم اعلان کی فہرستیں 16.0.0 — 16.4.0 میں نظر ثانی شدہ 16.4.1 ; منظر نامہ ہے App Router , Cache Components ، اور use cache فنکشنز جو متعدد ٹائپ شدہ صفوں کو واپس کرتے ہیں۔ کوئی سرکاری قابل اعتماد عمومی حل نہیں ہے، اور متاثرہ ورژن کے صارفین کو وقت پر اپ گریڈ کرنے کی ضرورت ہے۔ پروسیسنگ کو ختم کرنے کے لیے “یہ فنکشن موجود نہیں لگتا” کے لیے صرف دستی تلاشوں پر انحصار کرنا مناسب نہیں ہے۔ S9

حوالہ: B. SVG Image Optimization RCE

CVE-2026-96889/GHSA-2464-fhr4-w9xw, 2026-10-14, Critical, CVSS 4.0 9.5. The مسئلہ تصویر کی اصلاح کے لیے استعمال ہونے والی اپ اسٹریم مقامی لائبریری میں ہوتا ہے۔ حکام نے نشاندہی کی کہ RCE خطرہ glibc Linux منظر نامے میں موجود ہے۔ S11

سرکاری ورژن کے فیلڈز ہیں:

  • >=10.0.0 <=15.5.27；
  • >16.0.0 <=16.4.0。

اہلکار 16.x برانچ کے لیے >16.0.0 کی سخت نچلی حد استعمال کرتا ہے، لیکن یہ رینج اسٹیٹمنٹ یہ ثابت کرنے کے لیے کافی نہیں ہے کہ 16.0.0 محفوظ ہے۔ اصل اپ گریڈ کا ہدف یکساں طور پر 15.5.28 / 16.4.1 ہے۔ S11

سرکاری عارضی حل یہ یقینی بنانا ہے کہ Next اصل میں تیز ≥0.35.5 لوڈ کرتا ہے۔ لاک فائلز، نیسٹڈ انحصار، اور تعیناتی امیجز اب بھی پرانی مثالیں رکھ سکتے ہیں، اس لیے صرف اوپر کی سطح پر sharp انحصار کا نیا ورژن شامل کرنا کافی نہیں ہے، حتمی انحصاری درخت کو چیک کیا جانا چاہیے اور اسے دوبارہ بنایا جانا چاہیے۔ S11

C. Server Actions CPU ختم ہو گیا۔

**GHSA-p3m5-59mp-jv5r, 2026-10-14, High, CVSS 4.0 8.2.**Next متاثر کرتا ہے 13.0.0—15.5.27, 16.0.0—16.4.0، فکسز 15.5.28 /16.4.1۔ شرائط App Router اور کم از کم ایک Server Action ہیں۔ بدنیتی پر مبنی درخواستیں CPU کو لمبے عرصے تک اپنے قبضے میں رکھ سکتی ہیں، اسی عمل میں بعد کی درخواستوں کو بلاک کر سکتی ہیں۔ Pages Router کے ساتھ یا Server Actions کے بغیر درخواستیں اس سے متاثر نہیں ہوتی ہیں۔ S12

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

3.5 پہلے Next.js اسی ونڈو میں سنگین مسئلہ

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

تاریخشناخت کنندہ / منظر نامہسب سے پہلے درست کریں؛ موجودہ کارروائی
2026-08-25GHSA-2xp9-vwfh-vxw4: AVIF امیج آپٹیمائزیشن مقامی لائبریری RCE, Critical15.5.24 / 16.3.3; اب 15.5.28 / 16.4.1 S13
2026-08-25CVE-2026-75604: RCE, Critical جب Pages Router اور App Router کو Windows پر بیک وقت استعمال کیا جاتا ہے، اور Cache Components فعال نہیں ہوتا ہے۔ ورژن >=13.4.0 <15.5.24, >=16.0.0 <16.3.315.5.24 / 16.3.3; Linux/macOS اس مخصوص Windows مسئلے سے متاثر نہیں ہوتے ہیں S14
2026-09-22GHSA-vcvr-r3jv-pc5j: next/og میں Node تصویر بنانے کا راستہ ناقابل اعتماد SVG، Critical پر کارروائی کرتا ہے۔ 16.2.0—16.3.516.3.6; Edge کا نفاذ اس مسئلے کے دائرہ کار سے باہر ہے، اور 15.x اس RCE S15 کے لیے متاثرہ برانچ نہیں ہے۔

4. Java ماحولیاتی نظام: رن ٹائم ٹرسٹ، کنٹینرز اور فریم ورک کو الگ سے ہینڈل کیا جاتا ہے

4.1 JDK: باقاعدہ CPU اور CVE-2026-91403 دو درجے کی اپ ڈیٹس ہیں

دی Java SE کے لیے رسک میٹرکس Oracle CPU 20 اکتوبر کی فہرستوں پر 55 نئے سیکیورٹی پیچ، جن میں سے 49 بغیر تصدیق کے نیٹ ورک پر قابل استعمال کے طور پر نشان زد ہیں۔ . اس کا مطلب یہ نہیں کہ 55 ہیں۔ Critical ، اور نہ ہی اس کا مطلب یہ ہے کہ 49 براہ راست استحصال کے قابل ہیں۔ RCE ہر ایک کے لیے راستے Java ویب سروس؛ اسے اجزاء، APIs، صارف کے تعاملات اور میٹرکس میں تعیناتی کے حالات کے ساتھ مل کر سمجھنا چاہیے۔ S16

اگلے دن کا CVE-2026-91403 (CVSS 3.1 9.1) خطرے کی ایک اور قسم سے نمٹتا ہے: eMudhra ایونٹ سے متعلق انٹرمیڈیٹ CA کا ایک سیٹ جس پر اب بھروسہ نہیں ہے۔ یہ TLS ہم مرتبہ کی تصدیق اور مواصلات کی رازداری/ سالمیت کو متاثر کرتا ہے اور اسے JVM میموری بدعنوانی کے خطرے کے طور پر بیان نہیں کیا جا سکتا۔ S17

Oracle ایڈوائزری 20 اکتوبر کو جاری کردہ ورژن کو متاثر کے طور پر درج کرتی ہے، اس لیے 21 اکتوبر کو آؤٹ آف بینڈ اپ ڈیٹ کو بھی انسٹال کرنے کی ضرورت ہے۔ مخصوص ورژن کے لیے سیکشن 2.2 دیکھیں۔ GraalVM میں متعلقہ متاثرہ پروڈکٹس بھی ہیں، اور فکسڈ ورژن اس کے خصوصی سیکیورٹی بلیٹن کے تابع ہونا چاہیے۔ S17S18

عارضی سرکاری اقدامات: پہلے بیک اپ لیں، اور پھر اصل میں استعمال ہونے والے ہر ٹرسٹ اسٹور سے مخصوص روٹ سرٹیفکیٹ ہٹائیں:

  • emSign ECC Root CA - G3، Oracle عرف emsigneccrootcag3 [jdk]۔
  • AAA Certificate Services، Oracle عرف comodoaaaca [jdk]۔ S19

JDK 11 اور بعد میں، سرکاری مثال یہ ہے:

keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]"
keytool -delete -cacerts -alias "comodoaaaca [jdk]"

ان کمانڈز کے لیے ٹارگٹ JDKسےkeytool استعمال کریں اور تصدیق کریں کہ وہ ایپلیکیشن کے اصل ٹرسٹ اسٹور پر کام کر رہے ہیں۔ Java 8 jre/lib/security/cacerts کے مطابق راستہ استعمال کرتا ہے۔ ٹرسٹ اسٹور کی تخصیص کو الگ سے ہینڈل کیا جانا چاہیے، اور دوسرے ناشرین کے مختلف القابات ہو سکتے ہیں۔ روٹ سرٹیفکیٹ کو ہٹانے سے مسترد ہونے کا دائرہ وسیع ہو جائے گا، اور ریگریشن-ٹیسٹ جائز سروس سرٹیفکیٹ چینز۔ S19

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

4.2 Tomcat: توثیق بائی پاس اور کراس یوزر کی درخواست تنہائی

مندرجہ ذیل تین آئٹمز 2026-10-20 پر شائع کیے گئے تھے۔ مرمت شدہ ورژن کے اندراج کی تاریخ October 12 ہے۔ Apache کا آفیشل گریڈ Important ہے۔ S21S22S23

CVEتصدیق شدہ متاثرہ ورژنضروری منظرنامے/نتائج
CVE-2026-1012969.0.0.M1—9.0.122；10.1.0-M1—10.1.60；11.0.0-M1—11.0.26JNDIRealm غیر GSSAPI SASL تصدیقی طریقہ کار کو ترتیب دیتا ہے، اسناد کی توثیق غائب ہے، اور غلط پاس ورڈ بھی گزر سکتے ہیں
CVE-2026-1013569.0.118—9.0.122；10.1.55—10.1.60；11.0.22—11.0.26HTTP/2 کی غیر مطابقت پذیر سرولیٹ کی خرابی سے ہینڈلنگ غلط طریقے سے اشیاء کو ری سائیکل/دوبارہ استعمال کرتی ہے، جس کی وجہ سے صارفین کے درمیان درخواستیں یا جوابات مل جاتے ہیں۔
CVE-2026-103119صرف 11.0.0-M25—11.0.26 کی تصدیق کریںبڑی AJP غیر مسدود تحریریں بفر کو کم پڑھنے کا سبب بن سکتی ہیں، جو بعد کی درخواستوں میں سابقہ جوابی ڈیٹا کو بے نقاب کرتی ہیں۔

متعلقہ فکس ہے 9.0.123 / 10.1.61 / 11.0.27؛ اعلان کے مطابق AJP صرف Tomcat 11 کے طور پر درج ہے، اور اسی مسئلے کے ساتھ اسے تین برانچوں تک نہیں بڑھایا جا سکتا۔ S21S22S23

JNDIRealm پیچ اصل تصدیق کے عمل میں ایک توثیقی خلا کو ٹھیک کرتا ہے، جہاں “ایپلی کیشن لاگ ان انٹرفیس نارمل لگتا ہے” کو تصدیق کے بجائے استعمال نہیں کیا جا سکتا۔ Realm, SASL میکانزم کو سروس کی اصل ترتیب کے لیے چیک کیا جانا چاہیے، اور غلط پاس ورڈز کے لیے ٹیسٹ ناکام ہونا چاہیے۔ S24

Interim نفاذ کی تجاویز: متاثرہ تصدیقی راستے کو الگ کر دیں۔ کاروبار کی اجازت ملنے پر HTTP/2 Tomcat کی پروسیسنگ کو معطل کر دیں۔ بیکار AJP بند کریں۔ صرف AJP پورٹ تک براہ راست رسائی کو محدود کرنے سے یہ ثابت نہیں ہو سکتا کہ قانونی فرنٹ پراکسی کے ذریعے داخل ہونے والی ٹریفک متاثر نہیں ہوگی۔ باضابطہ اپ ڈیٹ کے بعد، دو آزاد صارفین کی طرف سے غیر مطابقت پذیر ہم آہنگی کی درخواستوں کی جانچ کی جانی چاہیے تاکہ اس بات کی تصدیق کی جا سکے کہ شناخت اور جوابات کے درمیان کوئی باہمی بات چیت نہیں ہے۔

حوالہ: 4.3 Spring for GraphQL：CVE-2026-59285

عوامی تاریخ: 20-08-2026; High. متاثرہ 2.0.0—2.0.4، مرمت شدہ 2.0.5 (OSS) یا 2.0.4.1 (تجارتی تعاون)۔ S25

یہ صفحہ بندی کے استفسارات میں غیر محفوظ ڈی سیریلائزیشن کا خطرہ ہے۔ سرکاری ضرورت یہ ہے کہ ایک ہی وقت میں درج ذیل شرائط کو پورا کرنا ضروری ہے:

  1. Spring for GraphQL استعمال کریں۔
  2. جیکسن 2.x کا استعمال کرتے ہوئے JSON کو ڈی سیریلائز کریں۔
  3. بیرونی دنیا کو کنکشن پیجنگ فیلڈ فراہم کریں۔
  4. کلاس پاتھ میں مخصوص کلاسز ہوتی ہیں جو انسٹی ٹیشن یا ڈی سیریلائزیشن کے دوران غیر متوقع منطق انجام دے سکتی ہیں۔

ایک بدنیتی پر مبنی GraphQL درخواست RCE کا سبب بن سکتی ہے جب شرائط پوری ہوجائیں۔ اسے “جیکسن کا استعمال کرتے ہوئے تمام Java پروگراموں کا استحصال کیا جا سکتا ہے” تک کم نہیں کیا جا سکتا۔ S25

2.0.4 ناکافی کیوں ہے: جون میں، CVE-2026-41699 نے 2.0.4 جیسی پیچ کی بنیادیں دی تھیں، اور اگست میں اعلان میں واضح طور پر 2.0.4 کے نئے اثر و رسوخ میں شامل کیا گیا تھا۔ اس لیے، مرمت کے ریکارڈ کو بعد کے اعلانات کے مطابق اپ ڈیٹ کیا جانا چاہیے، اور پرانے CVE کا کم از کم ورژن استعمال نہیں کیا جا سکتا۔ S26

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

4.4 Spring Security: CVE-2026-59270 اور متعلقہ تصدیق کے خطرات

CVE-2026-59270, 2026-08-20, Critical. ایمبیڈڈ UnboundIdContainer معروف ایڈمنسٹریٹر کی اسناد کو بطور ڈیفالٹ رجسٹر کرتا ہے اور تمام نیٹ ورک انٹرفاسس پر سنتا ہے۔ جب جزو فعال ہوتا ہے اور پورٹ قابل رسائی ہوتا ہے، حملہ آور ڈائریکٹری ڈیٹا کو پڑھ یا اس میں ترمیم کرسکتا ہے۔ وہ پروجیکٹ جو عام طور پر Spring Security متعارف کراتے ہیں خود بخود LDAP کو ظاہر نہیں کریں گے۔ S27

متاثرہ علاقہ:

شاخمتاثرپہلے فکس/ایکوزیشن چینل
7.17.1.07.1.1 OSS; تجارتی 7.1.0.1 بھی
7.07.0.0—7.0.67.0.7 OSS; تجارتی 7.0.6.1 بھی
6.5 / 6.46.5.0—6.5.11；6.4.0—6.4.186.5.12/6.4.19، تجارتی
5.8 / 5.75.8.0—5.8.27；5.7.0—5.7.255.8.28/5.7.26، تجارتی

ماخذ: S27. spring.ldap.embedded.* خودکار کنفیگریشن اور ڈائریکٹ انسٹیٹیشن کوڈ کا ازالہ کریں۔ جب پروڈکشن کے لیے اس کی ضرورت نہ ہو تو جزو کو بند کریں، اور سننے کا اصل پتہ چیک کریں۔ جب کاروبار کو واقعی اس کی ضرورت ہو، تو پہلے کال کرنے کے ذرائع کو محدود کریں اور پھر اجزاء کی اپ گریڈیشن کو مکمل کریں۔

متعلقہ توثیق کا مسئلہ: CVE-2026-47841 ( High ). WebAuthn صارف کی توثیق پر سیٹ ہے۔ REQUIRED ، اور اس کے بعد HTTP سیشن کو تقسیم شدہ اسٹوریج کے ذریعہ سیریلائز کیا جاتا ہے، آبجیکٹ کی شناخت کا غلط موازنہ توثیق کی ضرورت کو باطل کر سکتا ہے۔ حملے کے لیے یہ بھی ضروری ہوتا ہے کہ حملہ آور کے پاس صارف کی تصدیق کرنے والا آلہ ہو، نہ کہ کسی ڈیوائس کے بغیر من مانی ریموٹ لاگ ان۔ کے متعلقہ متاثرہ ورژن کے لیے 7.1 , 7.0 , 6.5 ، اور 6.4 , پیچ کی بنیاد مندرجہ بالا جدول میں ان شاخوں کے ساتھ مطابقت رکھتی ہے۔ تصدیق میں کراس نوڈ سیشن کا احاطہ کرنا چاہیے اور پھر بھی PIN/بائیو میٹرک تصدیق کی ضرورت ہے۔ S28

5. Python ماحولیاتی نظام: ترجمان، معیاری لائبریری، فریم ورک اور سرٹیفکیٹ

5.1 CVE-2026-19445: SNI کال بیک میں SSLContext UAF

اشاعت کی تاریخ: 2026-09-30; PSF سطح: Critical. Python سرور TLS میں، sni_callback کنکشن کو کسی دوسرے SSLContext سے سوئچ کرتا ہے، اور جب اصل سیاق و سباق کا کوئی حوالہ نہیں ہوتا ہے۔ غیر تصدیق شدہ TLS کلائنٹ سروس کو کریش کر سکتا ہے یا جاری کردہ آبجیکٹ میں پوائنٹر کو کال کر سکتا ہے۔ S29

بنیادی بات یہ ہے کہ Python آبجیکٹ بنیادی TLS کال بیک لائف سائیکل سے مطابقت نہیں رکھتا ہے۔ اصل سیاق و سباق جاری کر دیا گیا ہے، اور بنیادی پرت اب بھی کال بیک کے لیے درکار ریاست کو برقرار رکھ سکتی ہے۔ حوالہ زندگی کے چکر کو ٹھیک کرنے کے لیے مترجم مقامی پیچ کو استعمال کرنے کی ضرورت ہے۔ S47

Scope: Python کوڈ جو صرف TLS کلائنٹ کے طور پر کام کرتا ہے اس آئٹم سے متاثر نہیں ہوتا ہے۔ لمبے عرصے تک اصل سیاق و سباق کو تھامے ہوئے سننے والے ساکٹ کا عام موڈ اعلان میں بیان کردہ مخصوص ناکامی کے راستے میں نہیں آتا ہے۔ Nginx کے TLS کو ختم کرنے کے بعد، یہ صرف مقامی HTTP کو Python کے حوالے کرتا ہے، اور Python براہ راست خود سے SNI کو ہینڈل کرتا ہے، جو ایک مختلف حملے کی سطح ہے۔ S29

3.10—3.14 فکسڈ ورژن کے مطابق، سیکشن 2.3. دیکھیں 3.15 کے آفیشل ورژن کی مرمت کر دی گئی ہے، اور حقیقت میں 3.15.1 کو منتخب کیا جا سکتا ہے۔ صرف pip انحصار کو اپ ڈیٹ کرنے سے مترجم کے _ssl نفاذ کو تبدیل نہیں کیا جا سکتا۔ S33S35S47

آفیشل عارضی تخفیف: ان تمام SSLContext کے حوالے سے مضبوط حوالہ جات رکھتا ہے جنہوں نے سرور لائف سائیکل کے اختتام تک SNI کال بیک سیٹ کیا ہے۔ اس کو حقیقی متحرک تخلیق اور سوئچنگ کے راستوں کا احاطہ کرنے کی ضرورت ہے۔ اپنی مرضی کے مطابق OpenSSL 1.1.1 بلڈ کو سرکاری ایشو ریکارڈ کے ساتھ مل کر دوبارہ گفت و شنید کی شرائط کو بھی چیک کرنا چاہیے اور اپ ڈیٹس کو مکمل کرنے کو ترجیح دینی چاہیے۔ S29S47

5.2 CVE-2026-19553: میزبان نام کا جھنڈا آن ہے، لیکن کال کرتے وقت میزبان نام غائب ہے

عوامی تاریخ: 2026-09-30; High جبSSLContext.check_hostname=True، اگر wrap_bio() کو server_hostname میں پاس نہیں کیا گیا تو، اصل نفاذ خاموشی سے میزبان نام کی تصدیق کو چھوڑ سکتا ہے۔ کامیاب سرٹیفکیٹ چین کی توثیق کا مطلب یہ نہیں ہے کہ ٹارگٹ ڈومین کا نام بھی ملایا گیا ہے۔ S30

تدارک کے لیے دونوں مراحل کی ضرورت ہے:

  • سیکشن 2.3. میں درج انٹرپریٹر سیکیورٹی ریلیز انسٹال کریں۔
  • wrap_bio()، متعلقہ asyncio.create_connection() / loop.start_tls() راستوں کو چیک کریں، واضح طور پر متوقع اور غیر خالی میزبان نام میں پاس کریں، اور سرٹیفکیٹ کی تصدیق کو آن رکھیں۔ S30

**مطابقت کے فرق جنہیں نظر انداز نہیں کیا جا سکتا:**3.10, 3.11, 3.12 مطابقت کے لیے ہیں، صرف DeprecationWarning کچھ معاملات کے لیے جاری کیا جاتا ہے جہاں میزبان کا نام غائب ہے؛ 3.13 اور بعد میں ValueError بڑھائیں۔ 3.12 بیک پورٹ بھی واضح طور پر None کو خالی سٹرنگز سے ممتاز کرتا ہے: None کے لیے ایک نئی وارننگ شامل کی گئی ہے، اور خالی سٹرنگز کے لیے اب بھی ایک غلطی کی اطلاع ہے۔ لہذا، کم برانچ کے صارفین یہ فرض نہیں کر سکتے کہ اصل میں گمشدہ ڈومین نام کی توثیق صرف اپ گریڈ کر کے خود بخود بحال ہو گئی ہے۔ S31S33

ٹیسٹ کے ماحول میں، غیر مماثل میزبان نام کے ساتھ ایک قابل اعتماد چین سرٹیفکیٹ استعمال کریں اور تصدیق کریں کہ اصل ایپلیکیشن TLS کلائنٹ اسے مسترد کرتا ہے۔ صرف check_hostname بولین قدر کو پڑھنے سے مکمل قبولیت نہیں ہوتی۔

5.3 CVE-2026-82049: ٹارفائل فلٹر میں لنک کا امتزاج بائی پاس

عوامی تاریخ: 2026-09-14; High . میں CPython 3.13 اور اس سے پہلے کے متعلقہ نفاذات، ناقابل اعتماد ٹار میں ہارڈ لنکس اور علامتی لنکس کا امتزاج data / tar ایکسٹرکشن فلٹر، پیکنگ ٹری میں پیک کھولنے والی ڈائرکٹری کے باہر فائلوں کے مواد کو ظاہر کرنا، یا ان کی اجازتوں اور ترمیم کے اوقات میں ترمیم کرنا۔ S32

اس خطرے کے تصدیق شدہ اثرات میں فائل کے مواد کی نمائش اور میٹا ڈیٹا میں ترمیم شامل ہے۔ صرف یہ اثرات بیرونی فائل کے مواد کی صوابدیدی اوور رائٹنگ یا RCE کے غیر مشروط نفاذ کو ظاہر کرنے کے لیے کافی نہیں ہیں۔

کے متعلقہ پیچ بنیادی خطوط کے لیے 3.10 — 3.13 ، سیکشن دیکھیں 2.3. Python 3.14 کی وجہ سے اس مخصوص مسئلے سے مستثنیٰ ہے۔ os.link() کے بعد سے رویے میں تبدیلی 3.14.0b1 ، تو کے متاثرہ دائرہ کار 3.10 — 3.13 اوپر کی شاخ لاگو نہیں ہوتی۔ S33

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

filter="data" مکمل اعتماد کی حکمت عملی کے مقابلے عام ناقابل اعتماد آرکائیوز کے لیے زیادہ موزوں ہے، لیکن پرانے ورژن پر موجود فلٹر میں بھی یہ کمزوری ہے، اور صرف اس پیرامیٹر کو شامل کرنے سے اپ ڈیٹ کو تبدیل نہیں کیا جا سکتا۔ فلٹر ایک مکمل فائل سسٹم سینڈ باکس بھی نہیں ہے۔ S32S45

5.4 ضمنی خطرہ: CVE-2026-114583 (Medium) اور پیچ کی رہائی کی حیثیت

PSF نے 2026-10-22 میں انکشاف کیا کہ tarfile.tar_filter کی مخصوص لنک کے ناموں کی پروسیسنگ کو نظرانداز کیا جا سکتا ہے، جس سے بعد کے ممبران پیکنگ ڈائرکٹری کے باہر لکھ سکتے ہیں، Medium. اس دن سرکاری فکس PR کو ضم کر دیا گیا تھا۔ 23 اکتوبر 2026 تک، اس عہد پر مشتمل کسی بھی سرکاری دیکھ بھال کی ریلیز کی تصدیق نہیں کی گئی ہے۔ S40

لہذا:

  • یہ آئٹم الگ سے Medium کے طور پر درج ہے۔
  • 21 اکتوبر کو جاری ہونے والے مترجم ورژن میں یہ درستگی شامل نہیں سمجھا جا سکتا۔
  • وہ عمل جو اب بھی filter="tar" کو ناقابل اعتماد آرکائیوز کو ہینڈل کرنے کے لیے استعمال کرتا ہے اسے ریلیز بیک پورٹ کو ٹریک کرنا چاہیے۔ اس پروسیسنگ کے راستے کو مختصر مدت کے لیے الگ یا معطل کر دیں۔ data پر سوئچ کرتے وقت اور لنکس کو مسترد کرتے وقت، آپ کو اس بات کی بھی تصدیق کرنی چاہیے کہ یہ کاروباری تقاضوں کو پورا کرتا ہے، اور فلٹر کو تبدیل کرنے کو غیر مشروط سینڈ باکس کے طور پر بیان نہیں کیا جا سکتا۔

5.5 GeoDjango: CVE-2026-15307 اور اکتوبر میں اس کے بعد کی اصلاحات

2026-08-04, Django آفیشل High. مقامی استفسار واضح طور پر GDALRaster کو کچھ سٹرنگز/ڈکشنریز منتقل کرتا ہے، اور ڈرائیور نیٹ ورک میں فائلیں لکھ سکتا ہے۔ RCE اس وقت بن سکتا ہے جب مخصوص راستے اور بعد میں عمل درآمد کی شرائط ہوں۔ مقامی فیلڈ ماڈل دیکھنے کی اجازت کے ساتھ عملہ بھی ایڈمن چینج لسٹ کے ذریعے اس راستے تک رسائی حاصل کر سکتا ہے۔ S38

ابتدائی حل 5.2.17 / 6.0.8 ہے، جو مقامی تلاش کے ذریعہ قبول کردہ ان پٹ اقسام کو محدود کرتا ہے۔ یہ تبدیلی راسٹر کے اظہار کے لیے سٹرنگ/ڈکشنری کے استعمال کے اصل کاروبار کو متاثر کر سکتی ہے۔ صرف GDALRaster میں ناقابل اعتماد ان پٹ کو لپیٹنے کا مطلب اس کی تصدیق نہیں ہے۔ S38

6 اکتوبر کو CVE-2026-87890 (اعتدال پسند) مرمت کی گئی: بائٹس میں ظاہر کردہ VRT بیرونی وسائل کا حوالہ دے سکتا ہے اور پھر بھی نیٹ ورک کی درخواستوں کو متحرک کرتا ہے۔ اسی دن، نیسٹڈ جیومیٹری DoS کی حفاظت CVE-2026-15830 بھی مضبوط کیا گیا تھا. نئے ہائی رسک کو بیان کرنے کے لیے مؤخر الذکر دو کو اپ گریڈ نہیں کیا جا سکتا RCE ، لیکن اشارہ کریں کہ تعیناتی کی بنیادی لائن ہونی چاہئے۔ 5.2.18 / 6.0.9 / 6.1.2 . S39

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

5.6 certifi / pip: سرٹیفکیٹ ٹرسٹ ہر کاپی کا احاطہ کرتا ہے

GHSA-6q48-6c7w-9gw2 , 2026-10-20, Critical ، جانا جاتا ہے۔ CVE درج نہیں یہ سرٹیفکیٹ کی عدم اعتماد کی تازہ کاری ہے جس کی وجہ سے ہے۔ eMudhra انٹرمیڈیٹ CA واقعہ اس کا خلاصہ HTTPS کے کرپٹوگرافی میکانزم کے طور پر نہیں کیا جا سکتا یا یہ کہ تمام روٹ سرٹیفکیٹس کو کریک کر دیا گیا ہے۔ S36

certifi ایڈوائزری نے اصل میں 2026.10.18 کو ایک پیچ کے طور پر درج کیا ہے۔ PSF نے بعد میں واضح طور پر 2026.10.19 غیر متاثر شدہ روٹ سرٹیفکیٹس کے ساتھ مطابقت کو برقرار رکھنے کی سفارش کی۔ آپریٹنگ بیس لائن ہے .19۔ S36S37

تمیز کرنے کی ضرورت ہے:

مواد کی جگہ پر اعتماد کریں۔آپ کو الگ سے چیک کرنے کی ضرورت کیوں ہے۔
آپریٹنگ سسٹم CA پیکیجتصویر یا میزبان کے لیے سسٹم ٹرسٹ کا مواد
venv میں certifiCA bundle دراصل ایپلی کیشنز یا درخواستوں وغیرہ کے ذریعہ استعمال ہوتا ہے۔
pip بلٹ ان certifiبیرونی طور پر نصب certifi سے مختلف کاپی ہے۔
uv / دیگر پیکیجنگ ٹولزٹول کے اپنے اپ ڈیٹس اور قابل اعتماد ذرائع پر عمل کریں۔
اپنی مرضی کے مطابق CA فائلیں، پیکڈ سنیپ شاٹسسسٹم یا پیکجز کے لیے ڈیفالٹ بھروسہ مند ذرائع کو اوور رائیڈ کرنا جاری رکھ سکتا ہے۔

مندرجہ بالا مختلف پیکیجنگ مقامات پر مبنی ایک چیک لسٹ ہے۔ PSF کو متعلقہ ٹولز کو اپ ڈیٹ کرنے، موجودہ ورچوئل ماحول اور تصویر کو دوبارہ بنانے کی ضرورت ہے۔ صرف میزبان CA کو اپ ڈیٹ کرنے یا مترجم کو دوبارہ انسٹال کرنے سے یہ ثابت نہیں ہو سکتا کہ تمام کاپیاں تازہ کر دی گئی ہیں۔ S35S37

پرانے pip محفوظ بوٹسٹریپ سے اپ گریڈ کرتے وقت، PSF فکسڈ وہیل اور SHA-256 کے لیے کمانڈ فراہم کرتا ہے، ضمیمہ S37 دیکھیں۔ TLS تصدیق کو بند نہ کریں یا سرٹیفکیٹ کے مسائل کو نظرانداز کرنے کے لیے --trusted-host شامل نہ کریں۔

6. علاج کا باقاعدہ عمل

درج ذیل کمانڈز تصدیق شدہ قابل اعتماد ماحول کے لیے ہیں۔ عمل کرتے وقت، پراجیکٹ کے موجودہ پیکیج مینیجر، لاک فائل اور تعیناتی کے عمل کو یکجا کیا جانا چاہیے تاکہ متضاد لاک فائلوں کو بنانے کے لیے npm/pnpm/یارن یا pip/uv/Poetry کو ملانے سے گریز کیا جائے۔

پہلے ایک استثناء کو ہینڈل کریں: اگر آپ کو شبہ ہے کہ ماحول نے سیکشن 9 میں سمجھوتہ شدہ پیکج چلایا ہے، تو پہلے اسے الگ کریں اور صاف ماحول سے ڈسک، لاک فائل اور امیج ریکارڈ کو چیک کریں۔ پہلے درج ذیل Python/pip کمانڈ کو نہ چلائیں۔ S41

6.1 ایک لیجر قائم کریں جو حقیقی ٹریفک کے مطابق ہو

ہر سروس کم از کم ریکارڈ کرتی ہے:

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

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

6.2 Node.js: پہلے رن ٹائم کا تعین کریں، پھر درخواست کے انحصار کو اپ ڈیٹ کریں

اصل سروس ماحول میں چیک کریں:

node -p 'JSON.stringify({execPath:process.execPath,node:process.version,openssl:process.versions.openssl,brotli:process.versions.brotli},null,2)'
npm ls next react react-dom react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack sharp --all
npm audit --omit=dev

node -p کو سروس کے اصل ایگزیکیوٹیبل یا ایک حقیقی کنٹینر کے اندر استعمال کرتے ہوئے عمل میں لایا جانا چاہیے۔ یہ نئے شروع کیے گئے عمل کی جانچ پڑتال کرتا ہے اور خود یہ ثابت نہیں کرتا کہ پرانے کارکن کو تبدیل کر دیا گیا ہے۔ Node اصل لائبریری ورژن سٹرنگ کو برقرار رکھتے ہوئے بلٹ ان Brotli میں پیچ شامل کر سکتا ہے۔ لہذا، صرف process.versions.brotli پر انحصار نہ کریں تاکہ یہ معلوم کیا جا سکے کہ آیا اس کی مرمت ہو گئی ہے۔ آپ کو اسے Node سیکیورٹی ورژن یا وینڈر کے بیک پورٹ ثبوت کے ساتھ جوڑنا چاہیے۔ S2S4

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

Node 24کے ماحول کو منظم کرنے کے لیےmise کا استعمال کریں، جسے اس طرح اپ ڈیٹ کیا جا سکتا ہے:

mise use -g [email protected]
mise exec [email protected] -- node -p 'process.version + " " + process.execPath'

mise use -g عالمی ورژن کو ترتیب دیتا ہے۔ پروجیکٹ کی مقامی ترتیب کو اب بھی الگ سے چیک کرنے کی ضرورت ہے۔ اگر سروس نے پرانا مطلق راستہ، کنٹینر بیس امیج، یا کسی مختلف اکاؤنٹ کا ماحول ٹھیک کر دیا ہے، تو متعلقہ کنفیگریشن کو اپ ڈیٹ کرنا چاہیے اور سروس کو دوبارہ شروع کرنا چاہیے۔ کمانڈ خود پرانے چلنے والے عمل کو تبدیل نہیں کرتی ہے۔ S43

Next پروجیکٹ میں، منتخب برانچ کے مطابق متعلقہ کمانڈ پر عمل کریں۔ Next 15 کے لیے:

# Next 15 分支
npm install --save-exact [email protected]

Next 16 کے لیے:

# Next 16 分支
npm install --save-exact [email protected]

React/RSC مطابقت پذیر انحصار، لاک فائلز اور حتمی تیز مثال کو چیک کریں، اور پھر پروجیکٹ کے عمل کے مطابق تعمیر کریں۔ دوبارہ پیدا کرنے کے قابل انسٹالیشن کے لیے CI میں اپ ڈیٹ شدہ لاک فائل کا استعمال کریں، اور تعمیر کے بعد چلتی تصویر میں ورژن کو چیک کریں۔ اس ہنگامی صورت حال کے لیے پہلے سے طے شدہ حل کے طور پر بڑے ورژن میں بے قابو خودکار مرمت کا استعمال نہ کریں۔

6.3 Java: پبلشر، اصل JVM اور سرایت شدہ اجزاء کی تصدیق کریں

ابتدائی انوینٹری:

java -XshowSettings:properties -version

آؤٹ پٹ میں java.home, java.runtime.version اور پبلشر کو اصل میں سروس کے ذریعے استعمال کردہ JVM کے ساتھ منسلک ہونا چاہیے۔ اٹیچ کی اجازت کے ساتھ JVM کے لیے، JDK کا jcmd ہدف کے عمل کو چیک کرنے کے لیے استعمال کیا جا سکتا ہے، نہ صرف لاگ ان شیل۔

قابل اعتماد پروجیکٹس میں انحصار چیک کریں اور اصل تعمیراتی ٹولز کی بنیاد پر منتخب کریں:

./mvnw dependency:tree '-Dincludes=org.apache.tomcat.embed:*,org.springframework.security:*,org.springframework.graphql:*'

./gradlew dependencyInsight --dependency tomcat-embed-core --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-security-core --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-graphql --configuration runtimeClasspath

یہ بلڈ کمانڈز پلگ اِنز پر عمل درآمد کر سکتے ہیں اور آن لائن انحصار کو حل کر سکتے ہیں، اور صرف بھروسہ مند پروجیکٹس پر چل سکتے ہیں۔ تصویر میں حتمی JAR/WAR یا اصل JAR کو چیک کریں اور حتمی نمونے کے لیے فائل ڈیکلریشن کو تبدیل نہ کریں۔ Spring بوٹ ایمبیڈڈ Tomcat ایپلی کیشن کو دوبارہ بنانے کی ضرورت ہے۔ سسٹم میں علیحدہ Tomcat انسٹالیشن کو اپ ڈیٹ کرنے سے ایپلیکیشن پیکج میں موجود کاپی میں ترمیم نہیں ہوگی۔

رن ٹائم اپ ڈیٹ ہونے کے بعد، اپنی مرضی کے مطابق javax.net.ssl.trustStore، ایپلیکیشن سیلف لوڈڈ KeyStore، jlink رن ٹائم، GraalVM/نیٹیو امیج اور دیگر ڈیلیوری فارمز آئٹم کے حساب سے چیک کریں۔ وہ ایپلیکیشنز جن کے پاس پہلے سے ہی اپنی مرضی کے مطابق اعتماد کا مواد موجود ہے وہ صرف اس وجہ سے چیک کو ختم نہیں کر سکتیں کہ JDK ڈائرکٹری نئی ہو جاتی ہے۔

6.4 Python: ترجمان بہ ترجمان اور ورچوئل انوائرمنٹ پروسیسنگ

حقیقی venv/کنٹینر کے اندر بھروسہ ہونے کی تصدیق:

python - <<'PY'
import sys
import ssl
import importlib.metadata as metadata

print("executable:", sys.executable)
print("version:", sys.version)
print("openssl:", ssl.OPENSSL_VERSION)
print("verify_paths:", ssl.get_default_verify_paths())
for name in ("pip", "certifi", "Django", "urllib3", "Brotli", "litellm"):
    try:
        print(name + ":", metadata.version(name))
    except metadata.PackageNotFoundError:
        print(name + ": not installed")
PY

python -m pip --version
python -m pip check

یہ اسکرپٹ صرف معلومات جمع کرتا ہے اور ورژن کی اہلیت کا تعین نہیں کرتا ہے۔ ssl.get_default_verify_paths() پہلے سے طے شدہ راستے کی معلومات ہے اور یہ ثابت نہیں کر سکتی کہ تمام فریق ثالث کلائنٹ ایک ہی ٹرسٹ اسٹور استعمال کرتے ہیں۔ درخواست کی ترتیب کی بنیاد پر اس کی تصدیق ہونی چاہیے۔

ضمیمہ S37 کے قابل اعتماد pip بوٹ اپ گریڈ کو مکمل کرنے کے بعد، پروجیکٹ کی رکاوٹوں کے مطابق سرٹیفکیٹ انحصار کو اپ ڈیٹ کریں، مثال کے طور پر:

python -m pip install --upgrade 'certifi>=2026.10.19'

# 仅适用于当前就选择 Django 5.2 的项目
python -m pip install --upgrade 'Django>=5.2.18,<5.3'

python -m pip check

پروجیکٹ کی ضروریات/لاک فائل کو ایک ہی وقت میں اپ ڈیٹ کرنے کی ضرورت ہے، ورنہ اگلی تعیناتی پرانے ورژن میں واپس آسکتی ہے۔ uv، Poetry، یا انٹرپرائز پیکیج ریپوزٹری کا استعمال کرتے وقت، ان کے موجودہ لاکنگ اور اشاعت کے عمل کو استعمال کریں۔ صرف پروڈکشن کنٹینر کے اندر پیکجوں کو دستی طور پر تبدیل نہ کریں۔

پراجیکٹ کے موجودہ pip-audit ورک فلو کو قابل اعتماد ماحول میں معلوم انحصار کے خطرات کی جانچ کرنے کے لیے استعمال کیا جا سکتا ہے۔ یہ بدنیتی پر مبنی کوڈ اسکینر نہیں ہے اور اس میں مترجم، سسٹم لائبریری اور ٹرسٹ اسٹور کے تمام خطرات شامل نہیں ہیں۔ S44

نظام کو مجبور کرنے کی سفارش نہیں کی جاتی ہے۔ /usr/bin/python3 ایک نئے مرتب شدہ ورژن کی طرف اشارہ کرنے کے لیے۔ سسٹم پر انحصار کرنے والے مینجمنٹ ٹولز کو توڑنے سے بچنے کے لیے ریلیز سیکیورٹی اپ ڈیٹس یا پروجیکٹ آئسولیشن رن ٹائم استعمال کریں۔ Python . یہ عمل درآمد کا انتخاب ہے اور اس خطرے کے لیے اضافی درستگی کی ضرورت نہیں ہے۔

6.5 چل رہی مثال کو دوبارہ بنائیں اور تبدیل کریں۔

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

  1. اصل قابل اعتماد ذریعہ سے پیچ حاصل کریں اور ورژن/ہیش اور انحصار لاک کو محفوظ کریں۔
  2. قریبی پیداواری ماحول میں کلیدی فنکشنز واپس کریں اور تصدیق کریں کہ مقامی ایکسٹینشنز JVM/فریم ورک کے ساتھ مطابقت رکھتی ہیں۔
  3. رن ٹائم، ایپلیکیشن انحصار اور حقیقی ٹرسٹ اسٹور کو اپ ڈیٹ کریں؛ کنٹینر کے لیے بیس امیج اور سسٹم CA کو ریفریش کریں، صرف پرانی پرت کو دوبارہ استعمال نہ کریں۔
  4. ایپلیکیشنز اور امیجز کو دوبارہ بنائیں، اور سروس، ورکر، قطار میں صارفین، اور شیڈول ٹاسک انسٹینس کو رولنگ کی بنیاد پر تبدیل کریں۔
  5. نئی چل رہی مثال میں ورژن اور کنفیگریشن کو دوبارہ چیک کریں اور تصدیق کریں کہ تمام پرانی کاپیاں نکل چکی ہیں۔
  6. خرابی کی شرح، تاخیر، CPU/میموری، TLS ہینڈ شیک کی ناکامیوں، اور عمل کے کریشوں کا مشاہدہ کریں۔

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

7. عارضی تخفیف اور پیچ کا انتخاب

7.1 عارضی اقدامات کی کوریج کی حد

اعلان کردہ استعمال کی شرائط کی بنیاد پر عمل درآمد کی تجاویز درج ذیل ہیں۔ جب تک کہ آفیشل پلان نوٹ نہیں کیا جاتا، وینڈر اس بات کی ضمانت نہیں دیتا کہ تمام ویریئنٹس کو مکمل طور پر بلاک کیا جا سکتا ہے۔

خطرہعارضی اقدامات جو اٹھائے جاسکتے ہیں۔وہ حصہ جو اس کی بنیاد پر مکمل نہیں سمجھا جا سکتا
Brotli ضابطہ کشائیناقابل اعتماد ان پٹ ڈی کوڈنگ کو روکیں؛ ان باؤنڈ اور آؤٹ باؤنڈ خودکار ڈیکمپریشن چیک کریں۔ان باؤنڈ WAF یا جوابی کمپریشن کو بند کرنا تمام ضابطہ کشائی اندراجات کا احاطہ نہیں کرتا ہے S3
Next.js typed arrays RCEفوری طور پر اپ گریڈ کریں؛ اگر ضروری ہو تو متاثرہ خدمات کو عارضی طور پر الگ کر دیں۔S9 کا کوئی سرکاری قابل اعتماد عالمگیر حل نہیں ہے۔
Next.js SVG RCEسرکاری منصوبہ: یقینی بنائیں کہ اصل تیز ≥0.35.5؛ جب کاروبار کی اجازت ہو تو متعلقہ اصلاح کے انٹری پوائنٹس کو معطل کر دیں۔دیگر Next/RSC مسائل کا احاطہ نہیں کرتا ہے S11
Tomcat دائرہ / HTTP/2 / AJPمتعلقہ راستے کو الگ کریں اور غیر ضروری کنیکٹر بند کریں۔ابھی بھی متعلقہ برانچ کی مرمت کے پیکیج کی ضرورت ہے S21S22S23
GraphQL ڈی سیریلائزیشنمتاثرہ کنکشن فیلڈز کو معطل کریں؛ غیر بھروسہ مند کال کرنے والوں کو محدود کریں۔صرف درخواست کی لمبائی کی حد قسم/ڈی سیریلائزیشن کا مسئلہ S25 کو ٹھیک نہیں کر سکتی
Spring embedded LDAPجب ضرورت نہ ہو تو غیر فعال کریں؛ حقیقی سننے والے بندرگاہ کی پہنچ کو محدود کریں۔پہلے سے طے شدہ انتظامی شناخت اور ڈائریکٹری کی سالمیت کو ابھی بھی S27 چیک کرنے کی ضرورت ہے
CPython SNI UAFسرکاری منصوبہ: سروس کے اختتام تک متعلقہ SSLContext مضبوط حوالہ رکھیںتمام تخلیق/سوئچ راستوں کا احاطہ S29 ہونا چاہیے۔
Python میزبان نام چھوڑ دیں۔سرکاری حل: متوقع سرور_ہوسٹ نام کو درست طریقے سے پاس کریں۔صرف check_hostname پرچم کو چیک نہیں کر سکتے یا S30S31 وارننگ کو نظر انداز نہیں کر سکتے
ناقابل بھروسہ ٹارغیر ضروری/قرنطینہ نکالنے، غیر ضروری لنکس اور ڈیوائس اندراجات کو مسترد کریں۔نہ تو فلٹرز ہیں اور نہ ہی وسائل کا کوٹا یونیورسل سینڈ باکسز S32S40S45
سرٹیفکیٹ ٹرسٹ ایونٹصحیح CA مواد کو اپ ڈیٹ کریں؛ Java اعتماد کو سرکاری تخفیف کے مطابق محدود کیا جا سکتا ہے۔TLS تصدیق کو غیر فعال کرنے سے خطرہ S19S37 بڑھ جاتا ہے

7.2 ترسیل کے طریقہ کی بنیاد پر پیچ منتخب کریں۔

ترسیل کا طریقہمرمت کے طریقوں کو ترجیح دیں۔ثبوت جو برقرار رکھا جائے۔
تقسیم کے زیر انتظام رن ٹائممینوفیکچرر کی متعلقہ سیکیورٹی اپ ڈیٹسمکمل پیکیج ورژن، اعلان، ذخیرہ ماخذ
آفیشل بائنری/رن ٹائم مینیجراسی برانچ سے سرکاری سیکیورٹی ریلیزورژن، ماخذ اور ڈائجسٹ، عمل درآمد کا اصل راستہ
خود مرتب کردہ Node / CPythonمماثل برانچ کا آفیشل سورس ریلیز یا وینڈر کا مکمل پیچ سیٹکمٹ سیٹ، پیرامیٹرز کی تعمیر، منحصر لائبریریوں اور رجعت کے نتائج
Spring / Next / Djangoان برانچ اپ ڈیٹس، ریبلڈنگ انحصاری تالے اور حتمی ایپلیکیشنز کے ساتھ ہم آہنگحتمی انحصار کا درخت، JAR/پیکیج/تصویر میں اصل ورژن
کسٹم ٹرسٹ اسٹورانخلا کی تصدیق کرنے والا آفیشل انخلا کا منصوبہ یا وینڈر اپ ڈیٹاصل استعمال کا راستہ، مادی تبدیلی، TLS کامیابی اور مسترد ہونے کے ٹیسٹ
سمجھوتہ کرنے والا ماحولصاف اور قابل اعتماد مصنوعات سے دوبارہ تعمیر کریں اور الگ الگ واقعے کی تحقیقات کریں۔تاریخی پیکج/امیج ڈائجسٹ، انسٹالیشن ریکارڈ، کریڈینشل گردش ریکارڈ

7.3 کلیدی پیچ میکانزم اور جائزہ فوکس

  • Brotli: اس بات پر توجہ دیتا ہے کہ آیا تعمیر میں داخل ہونے سے پہلے باؤنڈری چیک اور مقامی ضابطہ کشائی کی حیثیت کی غلطی کی واپسی مکمل ہے۔ صرف JavaScript پیکیج کو تبدیل کرنے سے Node میں مستحکم طور پر مرتب کردہ کوڈ کو تبدیل نہیں کیا جا سکتا۔ S4
  • Node DNS / TLS : ان پٹ کو مسترد کرنے، ایڈریس نارملائزیشن، کے درمیان فرق پر توجہ مرکوز کرتا ہے۔ IP سان اور DNS شناخت، اور DNS کال بیک/ وعدہ پارسنگ پاتھ اور TLS میزبان نام میچ ٹیسٹ۔ S5 S6
  • Tomcat JNDIRealm: صرف ڈائرکٹری سیاق و سباق حاصل کرنے کے بجائے، تصدیق کا عمل درحقیقت اسناد کی تصدیق کرتا ہے یا نہیں۔ آفیشل ورژن کو ترجیح دینا اور کسی ایک سورس فائل کی تبدیلی کو مکمل بائنری پیچ کے طور پر نہ لینا۔ S24
  • CPython ssl: Python حوالہ ملکیت اور بنیادی SSLContext کے لائف سائیکل پر توجہ مرکوز کرتا ہے۔ wrap_bio() بیک پورٹ کرتا ہے جبکہ برانچ مطابقت میں فرق ہوتا ہے، اور آپ کو استعمال شدہ برانچ کے اصل نفاذ کو پڑھنا چاہیے۔ S31S47
  • Certificate distrust: اس طرح کی اپ ڈیٹس قابل اعتماد مواد کے طور پر ظاہر ہو سکتی ہیں یا واضح API تبدیلیوں کے بجائے فہرست کی تبدیلیوں سے انکار کر سکتی ہیں۔ Node کے اسی بیچ میں متاثرہ انٹرمیڈیٹ CA کا رد کرنے کا طریقہ کار بھی شامل ہے۔ Java اور Python کے متعلقہ اعتماد کے ذرائع کی اب بھی الگ سے تصدیق کرنے کی ضرورت ہے۔ S19S37S46

آزاد Brotli بائنڈنگ کو بھی چیک کیا جانا چاہئے۔ گوگل اپ اسٹریم جاری کیا گیا۔ 1.0.10 / 1.1.1 / 1.2.1 ٹھیک کرنے کے لئے اسی دن CVE-2026-111497 . Python مقامی ایکسٹینشنز یا JNI نمونے جو ایک ہی متاثرہ C کے نفاذ کو سرایت کرتے ہیں آزادانہ طور پر اپ ڈیٹ/ریبلٹ کرنے کی ضرورت ہے۔ اس کا اندازہ نہیں لگایا جا سکتا کہ تمام خالص Java ڈیکوڈرز متاثر ہوتے ہیں، اور نہ ہی یہ فرض کیا جا سکتا ہے کہ اپ گریڈنگ Node خود بخود دوسری زبانوں میں کاپیاں بدل دیتا ہے۔ S42

8. تصدیق اور فالو اپ چیکس

8.1 کم از کم تصدیقی چیک لسٹ

اشیاء کو چیک کریں۔ثبوت درکار ہے۔
رن ٹائممکمل ورژن یا وینڈر بیک پورٹ ثبوت حقیقی عمل/کنٹینر میں درست
درخواست پر انحصارNext/RSC/sharp، Tomcat/Spring، اور Django/certifi حتمی تعیناتی پروڈکٹس متعلقہ حد تک پہنچ چکے ہیں
تبدیلی کی حدتمام ورکر/JVM/کنٹینر کاپیاں اور بیک گراؤنڈ ٹاسکس کو نئے سے تبدیل کر دیا گیا ہے، اور پرانی مثالیں ختم ہو گئی ہیں۔
TLSدرست ڈومین سرٹیفکیٹ کامیاب؛ مماثل میزبان نام اور غلط زنجیریں پالیسی کے مطابق ناکام ہو جاتی ہیں۔ کسٹم ٹرسٹ اسٹورز شامل ہیں۔
eMudhra عدم اعتمادمتاثرہ انٹرمیڈیٹ CA کی طرف سے تیار کردہ سرٹیفکیٹ چین کو اصل رن ٹائم کے دوران مسترد کر دیا گیا تھا، یا اس بات کا ثبوت موجود ہے کہ مخصوص وینڈر کی سیکیورٹی کی تعمیر/مطابق مسترد فہرست کو تعینات کر دیا گیا ہے۔ کیس کو عام TLS ٹیسٹ یا Java 8 مختصر ورژن نمبر کی بنیاد پر بند نہیں کیا جا سکتا۔
Node ضابطہ کشائی اور تصاویرعام کمپریسڈ رسپانس، اپ لوڈ، امیج آپٹیمائزیشن اور RSC فنکشنز دستیاب ہیں۔ غیر بھروسہ مند ذریعہ کی پالیسی نافذ العمل ہے۔
Java توثیق اور تنہائیغلط پاس ورڈ مسترد کر دیا گیا؛ شناخت/ردعمل کے اختلاط کے بغیر آزاد صارف ہم وقتی غیر مطابقت پذیر درخواستیں؛ LDAP توقع کے مطابق سن رہا ہے۔
Python SNI / محفوظ شدہ دستاویزاتعام ملٹی ڈومین نام TLS کاروبار مستحکم ہے۔ آرکائیونگ پاتھ ٹراورسل اور نامنظور لنکس کو مسترد کرتا ہے، اور ڈائرکٹری سے باہر کی فائلوں میں ترمیم نہیں کی جاتی ہے
ڈیٹا اور فنکشنل رجعتصفحہ بندی، مقامی استفسار، اجازت کی جانچ اور پس منظر کے کاموں نے پروجیکٹ کے موجودہ امتحانات کو پاس کیا۔
وسائل اور مشاہداتCPU، میموری، غلطی کی شرح، لیٹنسی اور TLS کی غلطیوں میں کوئی غیر معمولی اضافہ نہیں ہے۔
ٹریس ایبلٹیاپ گریڈ کا وقت، پیکیج/امیج ڈائجسٹ، کنفیگریشن تبدیلیاں، تصدیقی نتائج اور حل نہ ہونے والے آئٹمز کی بچت کریں

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

8.2 پیچنگ اور مداخلت کی تفتیش مختلف کام ہیں۔

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

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

9. سپلائی چین سیکیورٹی کا واقعہ: LiteLLM 1.107.0 سمجھوتہ

**آفیشل تصدیق کی تاریخ: 21-10-2026.**LiteLLM نے اطلاع دی کہ اس کی ریلیز پائپ لائن سے سمجھوتہ کیا گیا تھا۔ PyPI کے litellm==1.107.0 اور اسی مدت کے کچھ Docker/GHCR پروڈکٹس میں خفیہ چوری اور ریموٹ کنٹرول نقصان دہ کوڈ تھا، اور متعلقہ مصنوعات کو واپس لے لیا گیا ہے۔ S41

اثر کا تعین کرنے کے لیے، آپ کو تاریخی تنصیب کے ریکارڈ اور تصویری ڈائجسٹ کو چیک کرنا چاہیے۔ latest، main-latest، اور main-stable جیسے لیبل اب صاف تصاویر کی طرف اشارہ کرتے ہیں، جو یہ ثابت نہیں کرتا کہ واقعے کے وقت کھینچی گئی مصنوعات صاف تھیں۔ اس وقت سرکاری سفارش یہ تھی کہ عارضی طور پر 1.106.2؛ یہ سفارش اس واقعے پر مبنی تھی، اور دیگر سیکیورٹی اعلانات کو ابھی بھی تعیناتی کے دوران چیک کرنے کی ضرورت ہے۔ S41

ان ماحول کے لیے جہاں متعلقہ مصنوعات انسٹال یا چلائی گئی ہیں:

  1. تنصیب کے ریکارڈز، تصاویر اور لاگ کو الگ تھلگ اور محفوظ کریں، اور صاف ماحول سے ان کا معائنہ کریں۔
  2. پہلے مشکوک ماحول میں Python/pip شروع نہ کریں۔ نقصان دہ .pth / sitecustomize.py کو دوبارہ شروع کرنے کے بعد پھانسی دی جا سکتی ہے۔
  3. قابل اعتماد ذرائع سے میزبانوں، venvs/کنٹینرز کو دوبارہ بنائیں؛ صرف پیکجوں کو ان انسٹال یا ڈاؤن گریڈ نہیں کر سکتا۔
  4. اصل رسائی کی بنیاد پر کلاؤڈ اسناد، LLM فراہم کنندہ کیز، LiteLLM کیز اور ڈیٹا بیس کی اسناد کو منسوخ/روٹیٹ کریں اور غیر معمولی استعمال کا جائزہ لیں۔ S41

یہ سپلائی چین کا ایک تصدیق شدہ واقعہ ہے اور اس سے نمٹنے کے دوران بدنیتی پر مبنی کوڈ پر عمل درآمد، اسناد کے رساو، اور مستقل خطرات پر غور کرنے کی ضرورت ہے۔ 23 اکتوبر 2026 تک، حکام اب بھی ابتدائی مداخلت کی تحقیقات کر رہے تھے۔

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

مندرجہ ذیل ماخذ کی توثیق کی تاریخ 2026-10-23 ہے، بشمول پروجیکٹ کا آفیشل سیکیورٹی اعلان، آفیشل کوڈ ریپوزٹری اور وینڈر کی ہدایات۔ مرکزی متن [Sx] اس ضمیمہ سے مطابقت رکھتا ہے۔ اپ ڈیٹ کرتے وقت، آپ کو یہ دیکھنا چاہیے کہ آیا فراہم کنندہ نے بعد میں ترمیم جاری کی ہے۔

S1 — Node.js: 2026-10-21 سیکیورٹی نوٹس

  • مقصد: چار رن ٹائمز High، برانچوں کو متاثر کرنے والے، اکتوبر سیکیورٹی ریلیز۔
  • حوالہ: Official Security Bulletin

S2 — Node.js: تین مینٹیننس لائنوں کے لیے باضابطہ ریلیز ہدایات

S3 — Vercel: Node.js Brotli RCE سیکیورٹی ایڈوائزری

S4 — Node.js: Brotli آفیشل پیچ جمع کروانا

  • مقصد: مقامی ضابطہ کشائی کی جانچ اور غلطی کے پھیلاؤ کے لیے نفاذ کی بنیاد۔
  • حوالہ: Brotli Patch commit 49dff6f57a

S5 — Node.js: TLS ایڈریس نارملائزیشن پیچ

S6 — Node.js: DNS NUL تصدیقی پیچ

S7 — Node.js: 2026-07-29 سیکیورٹی نوٹس

  • مقصد: HTTP/2 میموری کی تھکن، UAF اور اجازت ماڈل کی کمزوریاں۔
  • حوالہ: July 2026 Security Releases

S8 — Next.js: 2026-10-14 سیکیورٹی اپ ڈیٹ

حوالہ: S9 — Next.js：typed arrays / use cache RCE

  • مقصد: GHSA-673q-mjm6-r5xr؛ وقفہ، حالت، سکور اور کام کی کیفیت کو متاثر کرتا ہے۔
  • حوالہ: Next.js Official Security Bulletin

حوالہ: S10 — React：React Server Components RCE

حوالہ: S11 — Next.js：SVG Image Optimization RCE

حوالہ: S12 — Next.js：Server Actions DoS

S13 — Next.js: AVIF تصویر کی اصلاح RCE

حوالہ: S14 — Next.js：Windows RCE

حوالہ: S15 — Next.js：next/og ImageResponse RCE

حوالہ: S16 — Oracle: October 2026 CPU

S17 — Oracle: CVE-2026-91403 آؤٹ آف بینڈ الارم

  • مقصد: 2026-10-21، JSSE سرٹیفکیٹ ٹرسٹ رسک، متاثرہ مصنوعات اور CVSS 3.1 9.1۔
  • حوالہ: Oracle Security Alert

S18 — Oracle: JDK آفیشل ورژن اور ڈاؤن لوڈ کریں

  • مقصد: 20 اکتوبر کو CPU اور 21 اکتوبر کو آؤٹ آف بینڈ ورژن کے درمیان فرق کریں۔ Java 8 کے مختصر ورژن کی حدود میں فرق کریں۔
  • حوالہ: JDK release list
  • حوالہ: Oracle Java Download page

S19 — Oracle: eMudhra عارضی واپسی کا منصوبہ

S20 — Eclipse Adoptium: بلڈ ریکارڈ جاری کریں

  • مقصد: Temurin سرٹیفکیٹ کے واقعے کی وجہ سے دوبارہ پیک کیا گیا ہے۔ Oracle ورژن کا لاحقہ میکانکی طور پر لاگو نہیں کیا جا سکتا۔
  • حوالہ: Adoptium Release Scorecards

S21 — Apache Tomcat 9 سیکیورٹی نوٹس

  • مقصد: 9.0.123 فکس کے ساتھ 9 برانچ کا عین متاثرہ وقفہ۔
  • حوالہ: Tomcat 9 vulnerabilities

S22 — Apache Tomcat 10 سیکیورٹی نوٹس

S23 — Apache Tomcat 11 سیکیورٹی نوٹس

  • مقصد: تین آئٹمز Important, 11.0.27, AJP قابل اطلاق دائرہ کار اور انکشاف/ریلیز کی تاریخ۔
  • حوالہ: Tomcat 11 vulnerabilities

S24 — Apache Tomcat: JNDIRealm پیچ کمٹ

  • مقصد: سرٹیفیکیشن توثیقی خلا کی مرمت کے لیے رسمی بنیاد۔
  • حوالہ: JNDIRealm Patch commit

حوالہ: S25 — Spring：GraphQL CVE-2026-59285

حوالہ: S26 — Spring：GraphQL CVE-2026-41699

  • مقصد: پہلے سے طے شدہ حد، صرف یہ بتانے کے لیے کہ آپ پرانی بیس لائن پر کیوں نہیں رہ سکتے۔
  • حوالہ: 6 Month GraphQL Security Bulletin

حوالہ: S27 — Spring Security：CVE-2026-59270

  • مقصد: UnboundID LDAP، معروف انتظامی شناخت کو سرایت کریں اور OSS/تجارتی ورژن میں فرق کریں۔
  • حوالہ: Spring embedded LDAP Security Bulletin

حوالہ: S28 — Spring Security：CVE-2026-47841

  • مقصد: WebAuthn صارف کی تصدیق، سیشن سیریلائزیشن اور حملے کی بنیاد۔
  • حوالہ: WebAuthn Security Bulletin

S29 — PSF: CVE-2026-19445 آزاد سیکیورٹی ایڈوائزری

  • مقصد: 2026-09-30، Critical، SNI حالات اور عارضی اقدامات جن کا حوالہ SSLContext کے ذریعے دیا گیا ہے۔
  • حوالہ: SSLContext UAF Official announcement

S30 — PSF: CVE-2026-19553 آزاد سیکیورٹی ایڈوائزری

S31 — CPython: wrap_bio آفیشل پیچ اور 3.12 بیک پورٹ

S32 — PSF: CVE-2026-82049 آزاد سیکیورٹی ایڈوائزری

S33 — CPython: ستمبر کے آخر میں/اکتوبر کے شروع میں سرکاری سیکیورٹی ریلیز

S34 — CPython: 3.10 آخری محفوظ ریلیز

  • مقصد: 3.10.22 اور اپ اسٹریم لائف سائیکل کا اختتام۔
  • حوالہ: Python 3.10.22

S35 — CPython: 2026-10-21 ہنگامی دیکھ بھال کا ورژن

  • مقصد: 3.13.17 / 3.14.9 / 3.15.1، بلٹ ان pip اور certifi اپ ڈیٹس، موجودہ وینو کی ضروریات۔
  • حوالہ: Python 3.13.17
  • حوالہ: Python 3.14.9
  • حوالہ: Python 3.15.1

S36 — certifi: emSign سرٹیفکیٹ عدم اعتماد کا اعلان

S37 — PSF: Python صارفین پر eMudhra / emSign کا اثر

pip بوٹ اپ گریڈ کمانڈ S37 کی طرف سے بیان کردہ سرکاری ہدایات کے ذریعے فراہم کی گئی ہے۔ صرف Python ماحول میں استعمال کیا جائے جن کے قابل اعتماد ہونے کی تصدیق کی گئی ہو۔ اگر سیکشن 9 میں زہر دینے کا شبہ ہے تو پہلے الگ تھلگ کریں اور واقعہ کے عمل کے مطابق دوبارہ بنائیں۔ یہ وہیل مواد ہیش کو ٹھیک کرتا ہے اور اس کے بعد پروجیکٹ کے عمل کے مطابق دیگر انحصار کو اپ ڈیٹ کرتا ہے۔

python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"

S38 — Django: 2026-08-04 محفوظ رہائی

  • استعمال: CVE-2026-15307، GeoDjango استحصال کے حالات، ابتدائی اصلاحات اور مطابقت کی تبدیلیاں۔
  • حوالہ: Django 6.0.8 / 5.2.17

S39 — Django: 2026-10-06 محفوظ رہائی

  • مقصد: CVE-2026-87890، جیومیٹری DoS فی الحال منتخب کردہ بیس لائن کے ساتھ بعد میں کمک۔
  • حوالہ: Django 6.1.2 / 6.0.9 / 5.2.18

S40 — PSF / CPython: تازہ ترین tar_filter سائیڈ نوٹ

S41 — LiteLLM: آفیشل سپلائی چین واقعہ کی رپورٹ، 21 اکتوبر

  • مقصد: 1.107.0 آلودہ مصنوعات، تاریخی ڈائجسٹ، تنہائی کی تعمیر نو اور اسناد کو ضائع کرنا۔
  • حوالہ: Contained: LiteLLM v1.107.0 Compromised

S42 — Google Brotli: سرکاری محفوظ ورژن

  • مقصد: آزاد Brotli 1.0.10 / 1.1.1 / 1.2.1 اور کراس لینگویج ایمبیڈڈ کاپی کی تصدیق کی بنیاد۔
  • حوالہ: Brotli releases

S43 — غلط: کمانڈ آفیشل دستاویزات کا استعمال کریں۔

  • مقصد: عالمی ترتیب کے ٹول ورژن اور کمانڈ سیمنٹکس کی وضاحت کریں۔
  • حوالہ: mise use

S44 — PyPA: pip- آڈٹ آفیشل پروجیکٹ

  • مقصد: Python انحصار کمزوری آڈیٹنگ کا مقصد اور صلاحیت کی حدود۔
  • حوالہ: pip-audit

S45 — Python: ٹارفائل نکالنے والے فلٹر دستاویز

  • مقصد: ڈیٹا کی حکمت عملی، پہلے سے طے شدہ رویے میں تبدیلیاں، اور پابندیاں جو سینڈ باکس کی جگہ نہیں لے سکتی ہیں۔
  • حوالہ: tarfile extraction filters

S46 — Node.js: انٹرمیڈیٹ CA مسترد کرنے کا طریقہ کار

  • مقصد: یہ eMudhra متعلقہ ٹرسٹ چین پروسیسنگ تمام روٹ سرٹیفکیٹس کے کرپٹوگرافک باطل ہونے کے برابر نہیں ہے۔
  • حوالہ: Node.js PR #66871

S47 — CPython: SNI UAF تکنیکی نوٹس اور اصلاحات