--- title: "NGINX کمزوریاں: وجوہات، اصلاحات اور پیداوار کی تصدیق" description: "پانچ اکتوبر 2026 NGINX کمزوریوں، ان کی کنفیگریشن کی شرائط، برانچ کے لیے مخصوص اصلاحات، ڈسٹری بیوشن بیک پورٹ اور پروڈکشن کی تصدیق کا جائزہ لیں۔" language: "ur" url: "https://keendigit.com/ur/insights/nginx-remediation-guide" author: "KeenDigit" published: "2026-10-14" updated: "2026-10-27" --- # NGINX کمزوریاں: وجوہات، اصلاحات اور پیداوار کی تصدیق پانچ اکتوبر 2026 NGINX کمزوریوں، ان کی کنفیگریشن کی شرائط، برانچ کے لیے مخصوص اصلاحات، ڈسٹری بیوشن بیک پورٹ اور پروڈکشن کی تصدیق کا جائزہ لیں۔ تاریخی مضمون کی تاریخ: 2026-10-14 (انکشاف اور سیکیورٹی کی رہائی کی تاریخ)۔ 2026-10-27 کے ذریعے چیک کیے گئے ذرائع اور معلومات کی تکمیل۔ یہ مضمون واقعہ کی تاریخ کے لحاظ سے محفوظ کیا گیا ہے۔ 14 اکتوبر کے بعد جاری کردہ ورژن اور ریلیز اپ ڈیٹس ذیل میں شامل ہیں۔ سامعین: NGINX Open Source / NGINX Plus ویب سائٹ اور ریورس پراکسی آپریشن اور دیکھ بھال کرنے والے اہلکار، سیکیورٹی رسپانس اہلکار، ڈسٹری بیوشن مینٹینرز، نیز انجینئرز جو NGINX کو خود مرتب کرتے ہیں اور تیسرے فریق کے ماڈیولز کو برقرار رکھتے ہیں۔ یہ مضمون پانچ NGINX بنیادی کمزوریوں پر توجہ مرکوز کرتا ہے جنہیں 14 اکتوبر 2026 کو ظاہر کیا گیا تھا اور ان کو شدت سے طے کیا گیا تھا، اور مئی سے ستمبر 2026 تک نمائندہ میموری کی حفاظت اور سالمیت کے خطرات کی درخواست بھی کرتا ہے۔ اقدامات، باضابطہ پیچ کا نفاذ، پرانی شاخوں کو بیک پورٹ اور پیداوار کی تصدیق۔ حوالہ جات جیسے [S1](https://keendigit.com/ur/insights/nginx-remediation-guide#source-1) ماخذ ضمیمہ سے لنک کرتے ہیں۔ مثال کے کنفیگریشنز کا استعمال صرف تعیناتی اور آڈیٹنگ کے خیالات کو واضح کرنے کے لیے کیا جاتا ہے، اور عمل درآمد سے پہلے اصل ورژن، کنفیگریشن وراثت، انحصار، اور کاروباری صلاحیت کی بنیاد پر تصدیق کی جانی چاہیے۔ ## TL؛ DR: ترجیحی کارروائیاں 1. سیکیورٹی اپ گریڈ کو ترجیح دیں۔ کے لیے nginx.org اوپن سورس پیکجز، اپ ڈیٹ کریں۔ Stable 1.30 کم از کم شاخ 1.30.6 اور Mainline 1.31 کم از کم شاخ 1.31.7. تصدیق کی تاریخ پر، 1.31.8 تازہ ترین ہے Mainline رہائی یہ الگ الگ شاخ کی بنیادیں ہیں۔ شاخوں میں ان کی تعداد کا موازنہ نہ کریں۔ [S1](https://keendigit.com/ur/insights/nginx-remediation-guide#source-1) [S2](https://keendigit.com/ur/insights/nginx-remediation-guide#source-2) 2. مکمل پیکیج ورژن کے ذریعہ تقسیم کی تنصیبات کی تصدیق کریں۔ Ubuntu 22.04 / 24.04 / 26.04 / 26.10 کے پاس وینڈر بیک پورٹ ہیں۔ Debian 13 (trixie) کو کم از کم `1.26.3-3+deb13u10` کی ضرورت ہے۔ تصدیق کے وقت، Debian 12 (bookworm) پیکیج `1.22.1-9+deb12u10` ابھی بھی متاثرہ کے طور پر نشان زد ہے۔ ہر CVE کو چیک کریں؛ Debian 13 ایڈوائزری یہ ثابت نہیں کرتی ہے کہ Debian 12 فکس ہے۔ [S13](https://keendigit.com/ur/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/ur/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/ur/insights/nginx-remediation-guide#source-15) 3. پانچ ترتیب کے مجموعوں کا آڈٹ کریں: `alias + rewrite + $request_filename` , `map` + ریجیکس + متغیر تشخیص، `aio + ssi + include virtual` , HTTP/3 کے ساتھ `proxy_request_buffering on` ، اور `ssl_session_cache shared:...` خودکار کے ساتھ TLS سیشن ٹکٹ کی کلید گردش۔ صرف ایک ہدایت کی موجودگی استحصال کو قائم نہیں کرتی ہے۔ درخواست کے راستے اور ترتیب کے دائرہ کار کا اندازہ کریں۔ [S1](https://keendigit.com/ur/insights/nginx-remediation-guide#source-1) [S3](https://keendigit.com/ur/insights/nginx-remediation-guide#source-3) [S4](https://keendigit.com/ur/insights/nginx-remediation-guide#source-4) 4. تمام پرانے عمل اور کنٹینرز کو تبدیل کریں۔ `nginx -t` چلائیں، پھر سروس کو دوبارہ شروع کریں یا اعلی دستیابی والی رولنگ تعیناتی انجام دیں۔ تصدیق کریں کہ پرانے master/worker عمل ختم ہو چکے ہیں۔ `nginx -s reload` اکیلے یہ ثابت نہیں کرتا کہ چلنے والی بائنری بدل گئی ہے۔ 5. اصل اختتامی نکات کی تصدیق کریں: HTTP/1.1 , HTTP/2 , HTTP/3 اگر فعال ہو تو، پراکسی اپ لوڈز اور API اداروں کی درخواست کریں، mTLS سرٹیفکیٹ کی توثیق، SSI صفحات اور رسائی کے نوشتہ جات۔ ریکارڈ پیکج پرووننس، ورژن، امیج ڈائجسٹ، چل رہا عمل اور ہر ایک اینڈ پوائنٹ کے لیے نتائج۔ 6. اگر فوری اپ گریڈ کرنا ناممکن ہے تو، قابل اطلاق ٹرگر شرائط کو ہٹا دیں: غیر ضروری کو غیر فعال کریں SSI / AIO یا HTTP/3 ، کمزور کا جائزہ لیں `alias` / `rewrite` / `map` متغیر حوالہ جات، اور عارضی کا اندازہ کریں۔ `ssl_session_tickets off;` متاثرہ کے لئے mTLS خدمات WAF , ASLR ، شرح کی حد اور ترتیب میں تبدیلیاں صرف کچھ شرائط کا احاطہ کرتی ہیں اور سرکاری پیچ کو تبدیل نہیں کرسکتی ہیں۔ [S3](https://keendigit.com/ur/insights/nginx-remediation-guide#source-3) [S4](https://keendigit.com/ur/insights/nginx-remediation-guide#source-4) [S8](https://keendigit.com/ur/insights/nginx-remediation-guide#source-8) [S12](https://keendigit.com/ur/insights/nginx-remediation-guide#source-12) ## 1. کمزوری کا جائزہ اور خطرے کا فیصلہ NGINX نے 14 اکتوبر 2026 کو 1.30.6 (Stable) اور 1.31.7 (Mainline) کو جاری کیا، پانچ سیکیورٹی مسائل کو حل کیا۔ تین میں ہیپ اوور فلو یا استعمال کے بعد مفت شامل ہیں اور F5 CVSS v4.0 کے 9.2 اسکورز موصول ہوئے ہیں۔ دیگر دو HTTP/3 درخواست کی سالمیت اور TLS کلائنٹ سرٹیفکیٹ کی تصدیق کو متاثر کرتے ہیں۔ [S1](https://keendigit.com/ur/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/ur/insights/nginx-remediation-guide#source-2)[S3](https://keendigit.com/ur/insights/nginx-remediation-guide#source-3) درجہ بندی کے نظام میں فرق کریں: nginx.org پانچوں مسائل کو `medium` کے طور پر درج کرتا ہے، جبکہ F5 CVSS v4.0 اور کچھ قومی سلامتی ایجنسیاں میموری کے تین مسائل کو نازک کے طور پر درجہ بندی کرتی ہیں۔ اس کا مطلب یہ نہیں ہے کہ تمام پانچ غیر مشروط ریموٹ کوڈ پر عمل درآمد کی اجازت دیتے ہیں۔ کنفیگریشن، ٹریفک کی رسائی اور حملہ آور کے کنٹرول سے باہر کے حالات۔ میموری کی خرابی اور قابل اعتماد RCE ثبوت کی مختلف سطحیں ہیں۔ [S1](https://keendigit.com/ur/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/ur/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/ur/insights/nginx-remediation-guide#source-4) | سی وی ای | تکنیکی مسائل اور عام محرک حالات | بنیادی اثر | تشخیص اور ضائع کرنا | | -------------- | --------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | CVE-2026-15176 | `alias` پاتھ میپنگ + `rewrite` تبدیلی URI + تشخیص `$request_filename` | ہیپ بفر اوور فلو، Worker کریش؛ کچھ شرائط کے تحت ممکنہ RCE | F5 CVSS v4.0 9.2; خرابیوں کا سراغ لگانے کو ترجیح دیں۔ | | CVE-2026-93479 | HTTP/Stream اسکرپٹ کی تشخیص، خاص طور پر `map` regex کیپچر اور root ڈائریکٹری، لاگ متغیر کراس ریفرنس | محفوظ بفر کو اوور رائٹ کیا جاتا ہے اور ہیپ اوور فلو ہوتا ہے۔ کچھ شرائط کے تحت ممکنہ RCE | F5 CVSS v4.0 9.2; پچھلی مرمت کے بعد رجعت کا خطرہ ہے۔ | | CVE-2026-97205 | SSI ورچوئل شامل ہیں اور AIO/غیر مطابقت پذیر آپریشن؛ بقایا آپریشن شمار اوور فلو | مفت کے بعد استعمال کریں، Worker کریش، میموری کی خرابی؛ ممکنہ RCE | F5 CVSS v4.0 9.2; غیر طے شدہ ترتیب کی ضرورت ہے۔ | | CVE-2026-95101 | HTTP/3 نامعلوم فریم بفرز میں بکھرا ہوا ہے، پراکسی درخواست باڈی بفرنگ فعال ہے | اپ اسٹریم درخواست کے باڈی میں غیر DATA بائٹس کو غلط طریقے سے انجیکشن لگانا، ممکنہ طور پر درخواست کے باڈی سائز کی حد کو نظرانداز کرتے ہوئے | یہ کمزوری درخواست کی سالمیت کو متاثر کرتی ہے۔ یہ بذات خود ریموٹ کوڈ ایگزیکیوشن (RCE) فراہم نہیں کرتا ہے۔ | | CVE-2026-97629 | مشترکہ TLS سیشن کیش، خودکار کلید کی گردش اور Worker کلید کی عکس بندی | سیشن ٹکٹ کی جعلسازی؛ کلائنٹ سرٹیفکیٹ کی تصدیق کا بائی پاس متاثرہ mTLS سروس کے لیے ہو سکتا ہے۔ | سرٹیفکیٹ کی توثیق کی قسم API کے کاروباری اثرات پر خصوصی توجہ دینے کی ضرورت ہے | مندرجہ بالا CVSS سکور F5 نے v4.0 کا استعمال کرتے ہوئے دیا ہے۔ ایک ہی کمزوری CVSS 3.1، nginx.org کے اپنے درجات اور تقسیم کی شدت کی درجہ بندی میں مختلف شدت دکھا سکتی ہے۔ [S1](https://keendigit.com/ur/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/ur/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/ur/insights/nginx-remediation-guide#source-4) ### 1.1 صرف CVE سکور کے بجائے تعیناتی کی نمائش کو ترجیح دیں | تعیناتی فارم | اہم تفتیشی نکات | تصرف کی ترجیحی سفارشات | | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | -------------------------------------------------------- | | عوامی نیٹ ورک ریورس پراکسی، بشمول اپنی مرضی کے مطابق `rewrite`، `alias`، اور پیچیدہ `map` | CVE-2026-15176، CVE-2026-93479 اور مئی سے جولائی تک دوبارہ لکھنا/نقشہ کی کمزوریاں | P0: فوری طور پر آڈٹ اور اپ ڈیٹ کریں۔ | | API / مینجمنٹ ہوائی جہاز کلائنٹ سرٹیفکیٹ کا استعمال کرتے ہوئے واحد یا مرکزی داخلے کی تصدیق کے طور پر | CVE-2026-97629 کی سیشن ٹکٹ اور مشترکہ کیش کنفیگریشن | P0: تصدیق کی حد اور اپ ڈیٹ کی فوری تصدیق کریں۔ | | بیرونی HTTP/3 اپ لوڈ، اسٹیٹس چینج انٹرفیس، ٹرانزیکشن کلاس API فراہم کریں | CVE-2026-95101، خاص طور پر درخواست کا باڈی پسدید کے ساتھ منسلک ہے۔ | P0/P1: کاروباری اہمیت کے مطابق ترتیب دیں۔ | | SSI ڈائنامک صفحہ یا غیر مطابقت پذیر فائل I/O | CVE-2026-97205 | P1: مجموعہ حالات کی تصدیق کریں اور جلد از جلد مرمت کریں۔ | | صرف جامد صفحات + سادہ HTTP/1.1/2 ریورس پراکسی | کنفیگریشن اور ورژن کو ابھی بھی آڈٹ کرنے کی ضرورت ہے، لیکن کچھ CVE حالات غائب ہو سکتے ہیں۔ | P1: ایمرجنسی سیکیورٹی اپ گریڈ ونڈو میں شامل ہے۔ | | ریٹائرڈ Kubernetes کمیونٹی ingress-nginx استعمال کریں | پراجیکٹ سیکورٹی مینٹیننس کو روکتا ہے، اور خطرات ان پانچ CVEs تک محدود نہیں ہیں۔ | ایک انفرادی کنٹرولر منتقلی کا منصوبہ بنائیں | P0/P1 پبلک نیٹ ورک کی نمائش اور سرٹیفیکیشن کی حساسیت کے لیے اس مضمون میں دی گئی آپریشن اور دیکھ بھال کے ضائع کرنے کی تجاویز ہیں۔ یہ کوئی سرکاری CVSS درجہ بندی نہیں ہے، اور نہ ہی اسے انٹرپرائز کے اندرونی اثاثے کو تبدیل کرنا چاہیے اور خطرے کی تشخیص کو تبدیل کرنا چاہیے۔ ### 1.2 اثر کی حد اور حملے کی اجازتیں۔ اس بیچ میں بنیادی کمزوریاں بنیادی طور پر NGINX ڈیٹا پلین میں واقع ہیں: حملے کا انٹری پوائنٹ کلائنٹ کنکشن اور درخواست ہے، اور اصل اثر عام طور پر Worker عمل میں ہوتا ہے۔ اگر میموری کی بدعنوانی کے لیے قابل استعمال شرائط کو پورا کیا جاتا ہے تو، کوڈ پر عمل درآمد کی اجازت عام طور پر چلانے والے صارف، کنٹینر کی رکاوٹوں، لینکس کی صلاحیت، ماؤنٹنگ اور Worker کے نیٹ ورک کی اجازت کے ذریعے محدود ہوتی ہے۔ ممکنہ RCE خود بخود root مراعات یا میزبان سمجھوتہ کا مطلب نہیں ہے۔ [S4](https://keendigit.com/ur/insights/nginx-remediation-guide#source-4) لیکن یہاں تک کہ اگر یہ عمل غیر مراعات یافتہ ہے، تب بھی اسے پراکسی اسناد، سرٹیفکیٹ پرائیویٹ کیز پر مشتمل پڑھنے کے قابل فائلوں، اپ اسٹریم سروس ٹوکنز، عارضی فائلوں، اندرونی API، اور قابل رسائی نیٹ ورکس تک رسائی حاصل ہوسکتی ہے۔ mTLS کے لیے، توثیق بائی پاس خود ایک سنگین کاروباری نتیجہ ہو سکتا ہے، اور ضروری نہیں کہ اس کے ساتھ کوڈ کا نفاذ ہو۔ ## 2. وجہ کا تجزیہ ### 2.1 NGINX میں غلطی کے شکار تین حدود کو سمجھیں NGINX worker ایک طویل المدت، ایونٹ پر مبنی عمل ہے جو درخواست کی حیثیت، غیر مطابقت پذیر آپریشنز اور پروٹوکول پارسرز کو برقرار رکھتا ہے۔ یہ کمزوری انجینئرنگ کی تین سطحوں پر رکاوٹوں کی علامت ہے: 1. متغیر تشخیص اور میموری کا سائز مطابقت پذیر ہونا چاہیے: `rewrite` درخواست URI کو تبدیل کرنے کے بعد، راستے کی نقشہ سازی موجودہ موثر `location` کے مطابق ہونی چاہیے۔ جب اسکرپٹ مترجم متغیر کی لمبائی کا حساب لگاتا ہے، تو لکھنے کی جگہ کو اصل آؤٹ پٹ اور مخصوص علاقوں کا احاطہ کرنا چاہیے۔ 2. غیر مطابقت پذیر کارروائیوں کو درخواست کردہ میموری کے لائف سائیکل کو بڑھانا چاہیے: جب فائل پڑھنا اور لکھنا، کیش ویٹنگ یا تھریڈ کے کام نامکمل ہوتے ہیں، تو متعلقہ درخواست میموری پول کو پہلے سے جاری نہیں کیا جا سکتا۔ 3. پروٹوکول اسٹیٹس اور سیکیورٹی اسٹیٹس کو ملا یا چھوڑا نہیں جاسکتا: HTTP/3 نامعلوم فریم اسکیپنگ کی لمبائی کو DATA درخواست کے جسم کی لمبائی کے طور پر شمار نہیں کیا جاسکتا۔ TLS دستخطی تصدیق میں حصہ لینے والے تمام کلیدی سلاٹس کو سیشن ٹکٹ کی گردش کے دوران صحیح طریقے سے شروع اور مطابقت پذیر ہونا چاہیے۔ مندرجہ ذیل مواد NGINX اپ اسٹریم فکس کمٹ اور وینڈر کے اعلان پر مبنی ہے تاکہ اس ناکامی کے طریقہ کار کی وضاحت کی جا سکے جس کو متحرک کیا جا سکتا ہے۔ مثال کا ٹکڑا تجزیہ کے لیے ہے، یہ مکمل کوڈ نہیں ہے جسے براہ راست پیداواری ماحول کی مرمت کے لیے استعمال کیا جا سکے۔ [S5](https://keendigit.com/ur/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/ur/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/ur/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/ur/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/ur/insights/nginx-remediation-guide#source-9) ### 2.2 CVE-2026-15176: `alias` اور دوبارہ لکھے گئے URI کے درمیان راستے کی نقشہ سازی غلط ہے۔ NGINX میں، مماثل `location` اور اس کے `alias` فائل کے راستے کا تعین کرتے ہیں۔ `rewrite` موجودہ درخواست URI کو تبدیل کر سکتا ہے۔ دوبارہ لکھنے کے بعد، اصل `location` میپنگ کے ذریعے استعمال ہونے والے مفروضے مزید برقرار نہیں رہ سکتے ہیں۔ متاثرہ پروسیسنگ پاتھ نے مناسب طور پر چیک نہیں کیا کہ آیا `alias` اسٹیٹس `ngx_http_map_uri_to_path()` میں چیک کرتے وقت درخواست دوبارہ لکھی گئی تھی۔ جب کنفیگریشن دوبارہ لکھنے کے بعد `$request_filename` کا جائزہ لینا جاری رکھتی ہے، تو راستہ ان مفروضوں کے ساتھ بنایا جا سکتا ہے جو موجودہ URI حالت کے مطابق نہیں ہے، آخر کار ہیپ میموری پر حد سے باہر لکھنے کو متحرک کرتا ہے۔ [S5](https://keendigit.com/ur/insights/nginx-remediation-guide#source-5) عام مجموعہ (صرف کنفیگریشن آڈٹ کے لیے جوابی مثال کے طور پر استعمال کیا جاتا ہے، تعیناتی کی سفارش نہیں کی جاتی ہے): ```nginx # 仅用于识别风险模式：不是修复配置 location /foo/ { alias /srv/alias-root/; rewrite ^/foo/.*$ /new-path; return 200 $request_filename; } ``` خطرہ صرف `return` تک محدود نہیں ہے: `set`, `if`, `add_header`, `log_format`, وغیرہ کو بھی آڈٹ کرنے کی ضرورت ہے اگر `$request_filename` کی تشخیص اسی عمل میں شروع ہوتی ہے۔ مثال کے طور پر `return` صرف اس ریاستی راستے کو دیکھنے میں آسان بناتا ہے، اس کا استعمال یہ اندازہ لگانے کے لیے نہیں کیا جا سکتا کہ تمام پروڈکشن کنفیگریشنز اوور فلو پیدا کریں گی۔ [S5](https://keendigit.com/ur/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/ur/insights/nginx-remediation-guide#source-10) حملے کے نتائج: درخواست کی تعمیر Worker کو دوبارہ شروع کرنے یا سروس میں رکاوٹ کا سبب بن سکتی ہے۔ ASLR جیسے حالات میں بند ہونا یا اسے نظرانداز کیا جا سکتا ہے، ممکنہ RCE ہے۔ اپ اسٹریم پیچ کا بنیادی مقصد `alias` سیاق و سباق میں دوبارہ لکھی گئی URI پاتھ میپنگ کو مکمل کرنے سے انکار کرنا ہے جو کہ اب درست نہیں ہے، بجائے اس کے کہ کسی مخصوص بفر کو بڑھایا جائے۔ [S5](https://keendigit.com/ur/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/ur/insights/nginx-remediation-guide#source-10) ### 2.3 CVE-2026-93479: اسکرپٹ کی تشخیص میں "محفوظ جگہ" اور حقیقی متغیر لمبائی کے درمیان مماثلت نہیں NGINX کے HTTP اور Stream ماڈیولز میں اسکرپٹ ایویلیوٹرز ہوتے ہیں جو لغوی تاروں اور متغیر اقدار کو نتیجہ کے سٹرنگ میں جوڑتے ہیں۔ درخواست کی مثالوں میں HTTP دستاویز root راستے، لاگ پاتھ تک رسائی، اور Stream میں متغیر اظہار شامل ہیں۔ `map` + ریگولر ایکسپریشنز کی کچھ کنفیگریشنز `map` رزلٹ ویری ایبل کا جائزہ لینے سے پہلے کیپچر شدہ اقدار کو دوسرے ایکسپریشنز کے ذریعے پڑھنے کی اجازت دیتی ہیں۔ محفوظ طوالت کے ساتھ اسکرپٹ پر عمل درآمد کے طریقہ کار کے ساتھ مل کر، پرانا نفاذ `len` محفوظ جگہ کو پہلے سے تشخیص شدہ لمبائی جمع کرنے والے میں شمار کرے گا، تاکہ بعد میں لکھنے والے پوائنٹر کے حسابات بفر باؤنڈری کے ساتھ مطابقت نہ رکھیں۔ ایک مخصوص متغیر تشخیصی ترتیب میں، بعد میں آنے والی سٹرنگ رائٹز مخصوص جگہ کو اوور رائٹ کر سکتی ہیں، جس سے ہیپ اوور فلو ہوتا ہے۔ [S6](https://keendigit.com/ur/insights/nginx-remediation-guide#source-6) | شراکت دار عناصر | کیوں اس پر توجہ دینے کے قابل ہے۔ | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | regex `map` میں | کیپچر متغیر تشخیص میں آزاد لائف سائیکل اور کیشنگ رویہ ہو سکتا ہے۔ | | گمنام کیپچرز جیسے `$1`، `$2`، وغیرہ۔ | دوسرے ریگولر ایکسپریشنز یا ایکسپریشنز کے ذریعے آسانی سے اوور رائٹ ہو جاتے ہیں، جس سے ملکیت کو ٹریک کرنا مشکل ہو جاتا ہے۔ | | `root` میں متغیرات | اسکرپٹ پر عمل درآمد اور بفر ریزرویشن جب پاتھ بلڈنگ کو متحرک کرتے ہیں۔ | | `log_format`/متحرک لاگ پاتھ | اسی قسم کی تشخیص بعد میں درخواست میں شروع کی جا سکتی ہے۔ | | `stream` میں اسکرپٹ کے تاثرات | اپ اسٹریم فکس `ngx_stream_script_run()` میں بھی ترمیم کرتا ہے۔ آپ صرف HTTP ماڈیول کا جائزہ نہیں لے سکتے۔ | اہم رجعت کا تعلق: اس خطرے سے متعلق کوڈ کا تعلق سابقہ تبدیلیوں سے ہے جنہوں نے CVE-2026-42533 کو طے کیا تھا۔ Debian 13 کے لیے آفیشل DSA واضح طور پر کہتا ہے کہ متاثرہ کوڈ کو trixie پیکیج میں پہلے کے سیکیورٹی بیک پورٹ کے ذریعے متعارف کرایا گیا تھا۔ لہذا، "جولائی `map` خطرے کا پیچ انسٹال کر دیا گیا ہے" کا مطلب یہ نہیں ہے کہ اکتوبر کے CVE-2026-93479 کا احاطہ کیا گیا ہے۔ مکمل سیکورٹی فکس چین کو چیک کیا جانا چاہئے. [S6](https://keendigit.com/ur/insights/nginx-remediation-guide#source-6)[S14](https://keendigit.com/ur/insights/nginx-remediation-guide#source-14)[S17](https://keendigit.com/ur/insights/nginx-remediation-guide#source-17) یہاں ممکنہ RCE خطرہ میموری کے تحفظ کے ماحول سے متعلق ہے، اور یہ دعویٰ نہیں کیا جانا چاہیے کہ `map` regex ہی گمنام حملہ آوروں کے ذریعے فائدہ اٹھایا جا سکے گا۔ [S11](https://keendigit.com/ur/insights/nginx-remediation-guide#source-11) ### 2.4 CVE-2026-97205: AIO نامکمل آپریشن کاؤنٹ ریپراؤنڈ کا سبب بنتا ہے استعمال کے بعد مفت یہ خطرہ صرف "SSI آن کریں اور آپ کو UAF ملے گا" نہیں ہے۔ کلید مرکزی درخواست کے ذریعہ منعقد غیر مطابقت پذیر آپریشن حوالہ شمار میں ہے۔ NGINX غیر مطابقت پذیر پروسیسنگ کو ٹریک کرنے کے لیے `r->main->blocked` استعمال کریں جو ابھی تک مکمل نہیں ہوئی ہے، پرانے نفاذ میں یہ 8 بٹ کاؤنٹ تھا۔ کچھ راستوں نے گنتی میں اضافہ کرنے سے پہلے اوپری حد کی جانچ نہیں کی۔ جب ایک ہی اہم درخواست میں 256 بقایا کارروائیاں جمع ہوتی ہیں، تو گنتی 255 سے 0 تک سمیٹ سکتی ہے۔ بعد کے عمل غلطی سے یہ مان لیں گے کہ درخواست کو جاری ہونے سے روکنے والا کوئی غیر مطابقت پذیر آپریشن نہیں ہے، اس طرح درخواست کے میموری پول کو جاری کرے گا جس کا ابھی بھی ٹاسک کے ذریعہ حوالہ دیا گیا ہے۔ [S7](https://keendigit.com/ur/insights/nginx-remediation-guide#source-7) ناکامی کے عمل میں تقسیم کیا جا سکتا ہے: 1. متعلقہ غیر مطابقت پذیر I/O/تھریڈ پاتھ کو فعال کرنے کے ساتھ، SSI صفحہ `include virtual` کے ذریعے متعدد ذیلی درخواستیں یا پڑھنے کی کارروائیوں کو متعارف کراتا ہے۔ 2. ایک خاص اہم درخواست کی بقایا کارروائیاں شمار کے فیلڈ کے ذریعہ ظاہر کی گئی اوپری حد تک جمع ہوتی ہیں۔ 3. 8 بٹ کی گنتی چاروں طرف لپیٹ جاتی ہے، جس کا غلط اظہار "کوئی زیر التواء آپریشن نہیں" کے طور پر کیا جاتا ہے۔ 4. درخواست میموری پول جاری کیا جاتا ہے، جبکہ فائل پڑھتا ہے، کیش انتظار کرتا ہے، یا تھریڈ ٹاسک کے کال بیکس اب بھی اس کے حوالہ جات کو برقرار رکھتے ہیں۔ 5. بعد میں غیر مطابقت پذیر تکمیل کال بیکس جاری کردہ میموری تک رسائی حاصل کرتی ہیں، جس کے نتیجے میں UAF، Worker کریش ہو جاتے ہیں یا میموری کی ممکنہ خرابی ہوتی ہے۔ آفیشل فکس `NGX_HTTP_MAX_BLOCKED 250` کو درخواست ہیڈر فائل میں شامل کرتا ہے، اور آؤٹ پٹ فلٹر، کیش ریڈ، اور اپ اسٹریم تھریڈ پاتھ پر پابندیاں شامل کرتا ہے۔ جب حد تک پہنچ جاتی ہے، مطابقت پذیر راستوں کے ساتھ کام ہم آہنگی سے مکمل ہو جاتے ہیں، اور اگر ان پر محفوظ طریقے سے کارروائی نہیں کی جا سکتی ہے، تو زیر التواء کاموں میں مزید اضافہ کرنے سے انکار کر دیا جائے گا۔ [S7](https://keendigit.com/ur/insights/nginx-remediation-guide#source-7) قابل اطلاق فیصلہ: اس بات کا جائزہ لیا جانا چاہیے کہ آیا SSI، AIO، ورچوئل انکلوژن، ذیلی درخواستیں اور متعلقہ غیر مطابقت پذیر کارروائیاں ایک ہی درخواست کے سلسلے میں مل کر ہو سکتی ہیں۔ یہ عام طور پر پہلے سے طے شدہ سادہ جامد پراکسی کنفیگریشن نہیں ہوتے ہیں۔ `aio off;` یا `ssi off;` مخصوص محرک عناصر کو ہٹا سکتے ہیں، لیکن پہلے کاروباری فنکشن کے انحصار کی تصدیق ہونی چاہیے۔ [S4](https://keendigit.com/ur/insights/nginx-remediation-guide#source-4)[S7](https://keendigit.com/ur/insights/nginx-remediation-guide#source-7)[S25](https://keendigit.com/ur/insights/nginx-remediation-guide#source-25) ### 2.5 CVE-2026-95101: HTTP/3 نامعلوم فریم DATA درخواست کے باڈی کی حیثیت سے الجھا ہوا ہے HTTP/3 فریم پارسر کو `DATA` فریمز (جسے HTTP درخواست باڈی پروسیسنگ میں منتقل کرنے کی ضرورت ہے) اور نامعلوم فریموں کے درمیان فرق کرنا چاہیے جنہیں چھوڑ دیا جانا چاہیے۔ نیٹ ورک بفرز میں ٹکڑے ٹکڑے کرتے وقت نامعلوم فریموں کی لمبائی کو بھی درست طریقے سے محفوظ کیا جانا چاہیے۔ `ngx_http_v3_parse_data()` کے پرانے نفاذ نے `st->length` فیلڈ کا استعمال نامعلوم فریموں کو چھوڑتے وقت "چھوڑنے والے بائٹس کی بقیہ تعداد" کو بچانے کے لیے کیا، جب کہ درخواست کے باڈی فلٹر نے اسی فیلڈ کو "بقیہ DATA پے لوڈ کی لمبائی" سے تعبیر کیا۔ اگر نامعلوم فریم ایک سے زیادہ پارس کالوں پر محیط ہوتا ہے، تو پارس کرنے کے بعد بائٹس کے اگلے بیچ کو درخواست کے باڈی کے حصے کے طور پر غلطی سے سمجھا جا سکتا ہے۔ [S8](https://keendigit.com/ur/insights/nginx-remediation-guide#source-8) دو قسم کے خطرات پیدا ہوتے ہیں: - باڈی انجیکشن کی درخواست کریں: کلائنٹ کے ذریعہ جمع کردہ غیر DATA فریم پے لوڈ کو اپ اسٹریم ایپلی کیشن میں منتقل کیا جا سکتا ہے، اصل میں بیک اینڈ سے موصول ہونے والے ڈیٹا کو تبدیل کر کے۔ - سائز کی حد بائی پاسز: `client_max_body_size` اور دیگر پابندیاں۔ متوقع چیک DATA راستے پر مرکوز ہیں، اور غلط طریقے سے تبدیل شدہ مواد متعلقہ تصدیق کو نظرانداز کر سکتا ہے۔ اہلکار کے ذریعہ بیان کردہ عام محرک منظر نامہ وہ ہے جب `ngx_http_v3_module` HTTP/3 درخواست وصول کرتا ہے اور `proxy_request_buffering on` کو آگے بھیجتا ہے۔ پراکسی درخواست باڈی بفرنگ `ngx_http_proxy_module` میں ڈیفالٹ کے طور پر فعال ہے۔ لہذا، HTTP/3 کو آن کرنے والی ریورس پراکسی کو پہلے چیک کیا جانا چاہیے۔ یہ فرض کرنا مناسب نہیں ہے کہ کوئی محرک حالت نہیں ہے صرف اس وجہ سے کہ `proxy_request_buffering on;` واضح طور پر نہیں لکھا گیا ہے۔ [S8](https://keendigit.com/ur/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/ur/insights/nginx-remediation-guide#source-18) اس خطرے کا براہ راست نتیجہ پسدید کی درخواست کی سالمیت اور سیکیورٹی باؤنڈری کی تبدیلی سے تعلق رکھتا ہے، جو RCE کے براہ راست NGINX کور میں مکمل ہونے کے مساوی اظہار نہیں ہے۔ حتمی کاروباری اثر اس بات پر منحصر ہے کہ ان بائٹس کو کس طرح پارس کیا جاتا ہے اور اپ اسٹریم پر بھروسہ کیا جاتا ہے۔ [S24](https://keendigit.com/ur/insights/nginx-remediation-guide#source-24) ### 2.6 CVE-2026-97629: TLS ٹکٹ کی گردش تیسری کلیدی سلاٹ سے محروم ہے متاثرہ کنفیگریشنز میں، NGINX مشترکہ میموری کیش کے ذریعے TLS سیشن ٹکٹ کیز کو خود بخود بنا اور گھما سکتا ہے، جس سے متعدد Worker ٹکٹوں کے ایک ہی بیچ پر کارروائی کر سکتے ہیں۔ متعلقہ مطابقت پذیری منطق ہر Worker کے لیے 3 کلیدی سلاٹس مختص کرتی ہے، اور ڈکرپشن کال بیک ان سلاٹس کو بھی عبور کرے گا۔ لیکن پرانا نفاذ ہر بار مشترکہ میموری سے صرف 2 کلیدی سلاٹس کو کاپی کرتا ہے، جس کے نتیجے میں کلیدی نام، HMAC کلید اور تیسرے سلاٹ کا AES ہوتا ہے۔ کلید غیر شروع شدہ رہ سکتی ہے۔ اگر ٹکٹ کا کلیدی شناخت کنندہ اس حیثیت سے مماثل ہے تو، غیر شروع شدہ کلیدی مواد کو دستخط کی تصدیق اور ڈکرپشن کے لیے استعمال کیا جا سکتا ہے، اس طرح TLS سیشن کو جعلی بنانے کا راستہ بنتا ہے۔ [S9](https://keendigit.com/ur/insights/nginx-remediation-guide#source-9) اعلی خطرے کی تعیناتی کے مجموعے عام طور پر ہیں: ```nginx # 仅为排查触发条件所示：共享缓存本身不是恶意配置 ssl_session_cache shared:SSL:10m; # 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制 ``` اس خطرے کا سب سے سنگین کاروباری نتیجہ یہ ہے کہ ایسی سروسز پر جو `ssl_verify_client on;` اور دیگر طریقوں سے کلائنٹ سرٹیفکیٹ کی تصدیق (mTLS) استعمال کرتی ہیں، جعلی ریکوری سیشنز کلائنٹ سرٹیفکیٹ کی تصدیق کو نظرانداز کر سکتے ہیں۔ حملے کی کامیابی بھی بے قابو حالات سے مشروط ہے۔ ایک ایسی سائٹ جو صرف ایک عام سرور سائیڈ HTTPS سرٹیفکیٹ استعمال کرتی ہے اور کسی بھی کلائنٹ سرٹیفکیٹ کی توثیق کو غلط نہیں بنایا جانا چاہئے کیونکہ "حملہ آور پوری ویب سائٹ لاگ ان کو نظرانداز کر سکتا ہے۔" [S9](https://keendigit.com/ur/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/ur/insights/nginx-remediation-guide#source-12) یہ ایک TLS سیشن کی توثیق کی حیثیت کا مسئلہ ہے اور اس کا اس سے کوئی تعلق نہیں ہے کہ آیا سرور کی TLS نجی کلید کریک ہے یا عوامی CA root سرٹیفکیٹ متاثر ہے۔ [S24](https://keendigit.com/ur/insights/nginx-remediation-guide#source-24) ### 2.7 DoS، RCE، توثیق بائی پاس اور معروف کارناموں کو کیسے سمجھیں - DoS: میموری کی خرابی Worker کریش یا بڑے پیمانے پر دوبارہ شروع ہونے کا سبب بنتی ہے۔ چاہے یہ مجموعی طور پر عدم دستیابی کا سبب بنتا ہے ٹریفک کے دباؤ، عمل کو دوبارہ شروع کرنے کی صلاحیت، کنکشن کی بحالی کا وقت اور اعلی دستیابی کے فن تعمیر سے متعلق ہے۔ - ممکنہ RCE: کچھ اعلانات اس بات کی نشاندہی کرتے ہیں کہ ASLR کے بند یا نظرانداز ہونے پر کوڈ پر عمل درآمد کا امکان ہے۔ اس کا مطلب یہ نہیں ہے کہ ایک عوامی حملے کی زنجیر کا انکشاف کیا گیا ہے جو مستحکم اور عالمی طور پر کمانڈز کو انجام دے سکتا ہے۔ [S4](https://keendigit.com/ur/insights/nginx-remediation-guide#source-4) - انجیکشن/توثیق بائی پاس کی درخواست کریں: یہ براہ راست محفوظ کاروباری حیثیت کو تبدیل کر سکتا ہے یا مواد کی درخواست کر سکتا ہے، اور اسے صرف اس وجہ سے نظر انداز نہیں کیا جا سکتا کہ یہ براہ راست شیل حاصل نہیں کرتا ہے۔ - نے حملے کی کوششیں دریافت کی ہیں: مئی 2026 میں CVE-2026-42945 میں جنگلی استحصال کی سرگرمیوں کی رپورٹیں ہیں۔ اس تاریخی حقیقت کا براہ راست مطلب یہ نہیں نکالنا چاہیے کہ اکتوبر کے تمام پانچ CVE کا بڑے پیمانے پر کامیابی سے استحصال کیا گیا ہے۔ [S23](https://keendigit.com/ur/insights/nginx-remediation-guide#source-23) ## 3. ورژن اور پیچ کا انتخاب مرمت کریں۔ ### 3.1 NGINX Open Source آفیشل پیچ بیس لائن | اپ اسٹریم برانچ | اکتوبر میں پانچ کمزوریوں کا احاطہ کرنے والا پہلا سرکاری ورژن | 2026-10-27 کے مطابق سفارشات | | ------------------------------- | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | | Stable 1.30.x | 1.30.6（2026-10-14） | کم از کم 1.30.6 انسٹال کریں، اور بعد کے سیکیورٹی ورژنز کے ساتھ فالو اپ کریں۔ | | Mainline 1.31.x | 1.31.7（2026-10-14） | 1.31.8（2026-10-21） | | پہلے کی NGINX Open Source برانچ | اس کا فیصلہ صرف اس بنیاد پر نہیں کیا جا سکتا کہ "پرانے خطرے کے پیچ لاگو کیے گئے ہیں" | سب سے پہلے دیکھ بھال کی شاخ میں منتقل کریں؛ بصورت دیگر، وینڈر کو CVE-by-CVE کی بنیاد پر پشت پناہی کا باضابطہ ثبوت فراہم کرنے کی ضرورت ہے۔ | یہ nginx.org اپ اسٹریم سورس کوڈ/آفیشل برانچ کے ورژن کے نتائج ہیں، اور ڈسٹری بیوشن وینڈر کے ذریعے فراہم کردہ بیک پورٹڈ فکسس کے ساتھ سیکیورٹی پیکج کو براہ راست انکار کرنے کے لیے استعمال نہیں کیا جانا چاہیے۔ یہاں تک کہ اگر `1.31.6` کی قدر `1.30.6` سے زیادہ ہے، تب بھی یہ مین لائن برانچ کی پیچ بیس لائن سے کم ہے۔ [S1](https://keendigit.com/ur/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/ur/insights/nginx-remediation-guide#source-2) ### 3.2 پانچ CVEs کا اپ اسٹریم اثر کا دائرہ مندرجہ ذیل رینجز nginx.org سیکیورٹی بلیٹن کے اصل متن کے مطابق درج ہیں اور انہیں "موجودہ چلنے والی شاخ" اور "اصل کنفیگریشن پاتھ" کے ساتھ مل کر سمجھنے کی ضرورت ہے: | سی وی ای | اپ اسٹریم ٹیگز متاثرہ ورژن | باضابطہ طور پر مقررہ ورژن کا لیبل لگا ہوا ہے۔ | | -------------- | ------------------------------- | -------------------------------------------------- | | CVE-2026-15176 | `0.1.29–1.31.6` | `1.30.6+` یا `1.31.7+`، ان کی متعلقہ شاخوں کے اندر | | CVE-2026-93479 | `1.30.0–1.30.5`，`1.31.2–1.31.6` | اوپر کی طرح | | CVE-2026-97205 | `0.8.11–1.31.6` | اوپر کی طرح | | CVE-2026-95101 | `1.25.0–1.31.6` | اوپر کی طرح | | CVE-2026-97629 | `1.23.2–1.31.6` | اوپر کی طرح | CVE-2026-93479 کی تعارفی ورژن کی مخصوص حدود ہیں۔ ہر پرانا NGINX ورژن اس رجعت سے متاثر نہیں ہوتا ہے۔ ان حدود سے باہر کے پرانے ورژن اب بھی پہلے کے `map` ریجیکس کمزوری CVE-2026-42533 سے متاثر ہو سکتے ہیں۔ [S1](https://keendigit.com/ur/insights/nginx-remediation-guide#source-1) ### 3.3 Ubuntu: ڈسٹری بیوشن بیک پورٹ (USN-8955-1) کیننیکل USN-8955-1 26 اکتوبر 2026 کو چار Ubuntu کے لیے سیکیورٹی اپ ڈیٹ فراہم کرتا ہے: [S13](https://keendigit.com/ur/insights/nginx-remediation-guide#source-13) | Ubuntu ورژن | `nginx` اور ایک ہی سورس پیکیج فکسڈ ورژن | تفصیل | | ----------- | --------------------------------------- | ---------------------------------------------------------------------- | | 22.04 LTS | `1.18.0-6ubuntu14.22` | یہ ایک وینڈر بیک پورٹ ہے۔ اپ اسٹریم ورژن نمبر اب بھی 1.18.0 دکھاتا ہے۔ | | 24.04 LTS | `1.24.0-2ubuntu7.19` | اوپر کی طرح | | 26.04 LTS | `1.28.3-2ubuntu1.12` | اوپر کی طرح | | 26.10 | `1.30.4-7ubuntu1.1` | اوپر کی طرح | اعلان میں ہم جنس پیکجوں کے متعلقہ فکسڈ ورژن جیسے `nginx-core`، `nginx-extras`، `nginx-full`، اور `nginx-light` شامل ہیں۔ صرف `nginx -v` کی طرف سے دکھائے گئے upstream حصے سے اسے ٹھیک کرنا ہے یا نہیں اس بارے میں کوئی نتیجہ اخذ نہ کریں۔ جیسا کہ Ubuntu 24.04 اور `1.24.0-2ubuntu7.19` کو اس وینڈر نے پیچ کیا ہے، لیکن کسی بھی ذریعہ سے `1.24.0` فطری طور پر محفوظ نہیں ہے۔ Ubuntu سرکاری طور پر بھی واضح طور پر نشان لگا دیا گیا ہے کہ CVE-2026-95101 صرف اثر انداز ہوتا ہے Ubuntu 26.04 / 26.10 ، اور CVE-2026-97629 صرف اثر انداز ہوتا ہے Ubuntu 24.04 / 26.04 / 26.10. یہ ہے۔ Ubuntu کی اپنی پیکیجنگ اور فنکشنل اسکوپ، جسے براہ راست دوسری تقسیم میں فروغ نہیں دیا جا سکتا۔ [S13](https://keendigit.com/ur/insights/nginx-remediation-guide#source-13) ### 3.4 Debian: ورژن کے درمیان فرق کو الگ سے چیک کیا جانا چاہیے Debian ایڈوائزری DSA-6575-1 (2026-10-21) ان پانچ CVEs کا احاطہ کرتا ہے اور Debian 13 / trixie کے لیے طے شدہ `nginx` پیکیج کی شناخت کرتا ہے: ```text 1.26.3-3+deb13u10 ``` تاہم، اس رپورٹ کی تصدیق کے وقت تک، Debian 12 / bookworm کے لیے `1.22.1-9+deb12u10` کو ابھی بھی Debian سیکیورٹی ٹریکر نے خطرے سے دوچار کیا ہے۔ لہذا: - Debian 13 بس اپ ڈیٹ کریں اور DSA-6575-1 کے مطابق قبول کریں۔ - Debian 12 کو موجودہ سیکیورٹی ٹریکر یا ELTS وینڈر کے ذریعہ فراہم کردہ حفاظتی اصلاحات کو ایک ایک کرکے چیک کرنا چاہئے۔ اعلان میں درستگی کی تصدیق ہونے سے پہلے، یہ اعلان نہ کریں کہ تمام پانچوں آئٹمز کو `apt upgrade` کی کامیابی کی بنیاد پر طے کیا گیا ہے۔ - Debian سورس پیکیج nginx.org ورژن نمبر سے آزاد پیچ سیٹ لے سکتا ہے۔ اپنی مرضی کے مطابق تعمیرات کے لیے، آپ کو مکمل سورس کوڈ پیکج فکس سیٹ کو چیک کرنے کی ضرورت ہے، اور آپ صرف ایک اپ اسٹریم کمٹ کو کاپی نہیں کر سکتے اور اسے مکمل تصور کر سکتے ہیں۔ مندرجہ بالا امتیاز DSA اور CVE ٹریکنگ ریکارڈز پر مبنی ہے۔ [S14](https://keendigit.com/ur/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/ur/insights/nginx-remediation-guide#source-15)[S16](https://keendigit.com/ur/insights/nginx-remediation-guide#source-16) ### 3.5 NGINX Plus، njs اور انگریس کنٹرولر | مصنوعات/ اجزاء | حفاظتی انتخاب اور تصدیق کے کلیدی نکات | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | NGINX Plus (تجارتی ورژن) | براہ کرم F5 سے متعلق پلس برانچ کے اعلان اور اپ گریڈ ہدایات کا حوالہ دیں۔ تصدیق کے وقت تازہ ترین CR `PLS.37.2.0.1` ہے، اور LTS کی سیکیورٹی کی تعمیر `PLS.37.0.7.1` ہے؛ پلس ورژن اور شامل بیک پورٹ کو براہ راست اوپن سورس کی 1.30/1.31 حد سے تبدیل نہیں کیا جا سکتا۔ [S19](https://keendigit.com/ur/insights/nginx-remediation-guide#source-19) | | njs / ngx\_http\_js\_module | 2026-10-14 `njs 1.0.2` جاری کرتا ہے اور CVE-2026-101019 اور CVE-2026-101025 کو ٹھیک کرتا ہے۔ اگر آپ njs استعمال کر رہے ہیں، تو آپ کو NGINX کے ساتھ ماڈیول کی مطابقت کو بھی چیک کرنا چاہیے۔ [S20](https://keendigit.com/ur/insights/nginx-remediation-guide#source-20) | | F5 NGINX انگریس کنٹرولر / گیٹ وے فیبرک | NGINX کور ایک متعلقہ لیکن آزاد سافٹ ویئر ڈسٹری بیوشن چین ہے۔ متعلقہ کمزوریوں کو ان کے متعلقہ کنٹرولرز، امیجز اور ریلیز نوٹ سے ٹھیک کریں۔ آپ Pod میں صرف NGINX بائنری کو تبدیل نہیں کر سکتے۔ | | Kubernetes کمیونٹی `kubernetes/ingress-nginx` | اس منصوبے کو مارچ 2026 میں ختم کر دیا گیا ہے اور اس کے بعد سیکیورٹی کی نئی دیکھ بھال فراہم نہیں کی جائے گی۔ آپ کو F5 NGINX انگریس کنٹرولر کے لیے اس کے ریلیز نمبر کو غلط سمجھنے کے بجائے برقرار رکھے ہوئے کنٹرولر یا Gateway API پر منتقل کرنے کا منصوبہ بنانا چاہیے۔ [S21](https://keendigit.com/ur/insights/nginx-remediation-guide#source-21) | ### 3.6 آپ کو اصل میں کون سا پیچ منتخب کرنا چاہئے؟ | تعیناتی فارم | تجویز کردہ طرز عمل | مرمت کا ثبوت | | ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | nginx.org آفیشل DEB/RPM پیکیج | اپ اسٹریم برانچ کے فکسڈ ورژن میں اپ گریڈ کریں۔ | `nginx -v/-V`، پیکیج کا ذریعہ، سرکاری سیکورٹی اعلان | | Ubuntu/Debian آفیشل ریپوزٹری | وینڈر سیکیورٹی پیکجز انسٹال کریں۔ | مکمل پیکیج ورژن + وینڈر USN/DSA + CVE اسٹیٹس | | RHEL/Alma/Rocky/SUSE/دیگر تقسیم | مخصوص ڈسٹری بیوشن سیکیورٹی بلیٹنز اور پیکیج ورژن کے مطابق اپ گریڈ کریں۔ | متعلقہ وینڈر CSAF/اعلان، Ubuntu/Debian ورژن لاگو نہیں کیا جا سکتا | | سرکاری یا حسب ضرورت کنٹینر کی تصاویر | تصدیق شدہ مرمت کی تصویر کو دوبارہ بنائیں یا کھینچیں اور اسے رولنگ کی بنیاد پر تبدیل کریں۔ | امیج ڈائجسٹ، ایس بی او ایم بنائیں، پوڈ/کنٹینر امیج آئی ڈی چلائیں۔ | | خود مرتب کردہ NGINX, OpenResty, Tengine یا تیسرے فریق کے ماڈیولز کے ساتھ پیچ شدہ ورژن | دیکھ بھال کرنے والے کے مکمل حفاظتی ورژن کے استعمال کو ترجیح دیں۔ ٹارگٹ سورس ٹری کے لیے جب ضروری ہو تو جائزہ شدہ پیچ بیک پورٹ انجام دیں۔ | پانچ خطرے سے متعلق اصلاحات، ABI/ماڈیول مطابقت، یونٹ اور کاروباری رجعت | OpenResty اور Tengine مختلف ریلیز سسٹم ہیں۔ یہ جدول صرف تصدیق کا طریقہ بیان کرتا ہے۔ اس کا مطلب یہ نہیں ہے کہ اس کے تمام ورژن معیاری NGINX کی طرح ایک ہی وقت میں متاثر ہوتے ہیں، اور نہ ہی اپ اسٹریم کوڈ پیچ کو غیر مشروط طور پر لاگو کیا جا سکتا ہے۔ ## 4. باقاعدہ مرمت کا عمل ### 4.1 بیرونی ٹریفک موصول ہونے کی اصل مثالوں کی انوینٹری کم از کم ہر اندراج کے لیے کولیٹ کریں: - ڈومین کا نام، لوڈ بیلنسنگ/CDN/Edge پراکسی لنک، اصل سائٹ کی نمائش کا طریقہ اور نیٹ ورک پروٹوکول استعمال کیا گیا۔ - NGINX مصنوعات (اوپن سورس، پلس، انگریس، وغیرہ)، مکمل ورژن، پیکیج ریپوزٹری سورس، امیج ڈائجسٹ۔ - `nginx -V` عمارت کے ماڈیولز اور تالیف کے پیرامیٹرز دکھاتا ہے۔ چاہے وہاں njs، Lua، OpenResty، اور تھرڈ پارٹی ڈائنامک ماڈیولز ہوں۔ - اصلی چل رہا ہے master/worker PID، سروس یونٹ/کنٹینر/Pod، Replica اور Worker نوڈ۔ - اصل مؤثر `http`/`stream`، `server`، `location`، `include` کنفیگریشنز۔ - آیا HTTP/3، mTLS، SSI/AIO، ڈائنامک لاگ پاتھ، پیچیدہ `map` اور regex کیپچر کو فعال کرنا ہے۔ صرف ڈیفالٹ `/etc/nginx/nginx.conf` کو چیک نہ کریں۔ پیداواری ماحول اکثر `include` کے ذریعے متعدد سائٹس، TLS اور ماڈیول کنفیگریشنز کو لوڈ کرتا ہے۔ ایک سے زیادہ NGINX تنصیب کے راستے یا متعدد پراکسی پرتیں بھی ہو سکتی ہیں۔ ### 4.2 ورژن اور تالیف کی معلومات چیک کریں۔ ```bash # NGINX 版本及构建选项 nginx -v nginx -V 2>&1 # Linux：查看实际运行的 NGINX 进程 ps -eo pid,ppid,user,comm,args | grep '[n]ginx' # Debian / Ubuntu：查看完整已安装包版本、来源 apt-cache policy nginx # 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包 dpkg-query -W 'nginx*' 2>/dev/null # RPM 系：以实际安装包及仓库公告为准 rpm -qa | grep '^nginx' ``` `nginx -V` کمانڈ لائن پاتھ پر پائے جانے والے بائنری کی تعمیر کی اطلاع دیتا ہے۔ اس سے یہ ثابت نہیں ہوتا ہے کہ چلانے والے worker نے اسے لوڈ کیا ہے۔ `nginx -v` ڈسٹری بیوشن کے مکمل پیکیج کے لاحقے کو چھوڑ سکتا ہے، اس لیے پیکیج مینیجر یا سپلائی چین کے ریکارڈ کو بھی چیک کریں۔ ### 4.3 موثر ترتیب کو برآمد کریں اور جامد اسکریننگ کا پہلا دور انجام دیں۔ `nginx -T` کنفیگریشن کی جانچ کرے گا اور ضم شدہ کنفیگریشن کو پھینک دے گا۔ آؤٹ پٹ میں حساس معلومات ہو سکتی ہیں جیسے کہ تصدیقی اسناد، کلیدی راستے، داخلی میزبان کے نام وغیرہ۔ یہ تجویز کیا جاتا ہے کہ کنٹرول شدہ ٹرمینل کو root اجازتوں اور نجی فائل کی اجازتوں کے ساتھ محفوظ کریں، اور اصل فائلوں کو عوامی کام کے احکامات پر پوسٹ نہ کریں: ```bash sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log' sudo grep -nE \ 'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \ /root/nginx-effective.conf ``` یہ صرف امیدوار پاتھ لوکیٹر ہے، ایک قابل اعتماد CVE خودکار تعین کرنے والا ٹول نہیں: 1. `grep` اس بات کا تعین نہیں کر سکتا کہ آیا متغیرات ایک ہی `location` میں واقع ہیں یا ایک ہی درخواست کی تشخیص کے سلسلے میں، اور نہ ہی یہ کنفیگریشن وراثت کے تعلق کو اخذ کر سکتا ہے۔ 2. `proxy_request_buffering on`، کچھ کیشے اور ٹکٹ کنفیگریشنز کی ڈیفالٹ ویلیوز ہوتی ہیں، اور متعلقہ ہدایات نہ لکھنے کا مطلب یہ نہیں کہ خطرہ ختم ہو جاتا ہے۔ 3. ریورس پراکسیز، CDN، کنٹینر سائڈ کارز، یا کنٹرولرز کے ذریعے تیار کردہ کنفیگریشنز دستی طور پر معائنہ شدہ فائلوں سے مختلف ہو سکتی ہیں۔ 4. `NGINX Plus` اور متحرک ماڈیولز کی خصوصیات کو ان کے متعلقہ آفیشل مینجمنٹ ٹولز کا استعمال کرتے ہوئے تصدیق کرنے کی ضرورت ہو سکتی ہے۔ ### 4.4 بھروسہ مند چینلز کے ذریعے فکس تعینات کریں۔ Debian/Ubuntu (سرکاری تقسیم کا ذخیرہ): ```bash sudo apt-get update apt-cache policy nginx # 升级发行版仓库中已经安装的 NGINX 及相关包； # 先确认 Candidate 属于修复版本，再执行升级。 sudo apt-get install --only-upgrade nginx # 对实际安装的 nginx-core / nginx-full / nginx-extras 等包 # 确认它们的版本和依赖一同达到厂商修复要求。 dpkg-query -W 'nginx*' 2>/dev/null ``` کمانڈز کا یہ سیٹ پتلی ہوا سے حفاظتی اصلاحات نہیں بنا سکتا جو ابھی دستیاب نہیں ہیں۔ خاص طور پر Debian 12 کے لیے، اگر اپ گریڈ شدہ پیکیج کو سیکیورٹی ٹریکنگ سسٹم کے ذریعے اب بھی کمزور سمجھا جاتا ہے، اضافی وینڈر کی مرمت، تنہائی یا نقل مکانی کے اقدامات کی ضرورت ہے۔ [S13](https://keendigit.com/ur/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/ur/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/ur/insights/nginx-remediation-guide#source-15) nginx.org آفیشل پیکیج: ```bash # 先确认仓库来自 nginx.org、目标分支和候选版本 apt-cache policy nginx # 经变更审批后再执行对应仓库的升级命令 sudo apt-get install --only-upgrade nginx ``` اگر خود مرتب کردہ، OpenResty، Tengine یا NGINX Plus استعمال کر رہے ہیں، تو متعلقہ مینٹینر کے ذریعے تعاون یافتہ فکس ورژن استعمال کریں اور nginx.org، تقسیم اور تیسرے فریق کے ریپوزٹری پیکجز کو نہ ملا دیں۔ اصل بائنریز/تصاویر، کنفیگریشن، دستخط، اور رول بیک تعیناتی مینی فیسٹس کو محفوظ کیا جانا چاہیے۔ کنٹینرز/Kubernetes: ناقابل تغیر تصویر کو اپ ڈیٹ کریں، اس کا ڈائجسٹ ریکارڈ کریں اور تمام پرانی نقلوں کو مرحلہ وار رول آؤٹ سے تبدیل کریں۔ `kubectl rollout status` صرف اس بات کی تصدیق کرتا ہے کہ تعیناتی کنٹرولر ختم ہو گیا ہے۔ امیج ڈائجسٹ، انگریس روٹنگ اور غیر صحت بخش نقلوں کی بھی تصدیق کریں۔ ### 4.5 کنفیگریشن کی تصدیق کریں اور پرانے Worker کو تبدیل کریں ```bash sudo nginx -t # 按服务实际名称、主机高可用和变更窗口执行重启 sudo systemctl restart nginx sudo systemctl status nginx --no-pager # 核查真正存在的 master / worker ps -eo pid,ppid,user,comm,args | grep '[n]ginx' ``` `nginx -s reload` کو اس بات کا ثبوت نہ سمجھیں کہ ایک نئی بائنری چل رہی ہے: عام کنفیگریشن دوبارہ لوڈز پرانے master کو اس کے قابل عمل کو تبدیل کیے بغیر نئے کارکنوں کو شروع کرنے دیتی ہے۔ NGINX ایک وقف شدہ آن لائن بائنری اپ گریڈ طریقہ کار کی حمایت کرتا ہے، لیکن اس کے لیے اضافی اقدامات اور تصدیق کی ضرورت ہے۔ بغیر کسی طے شدہ طریقہ کار کے، ایک اعلیٰ دستیاب ٹریفک سوئچ کا استعمال کریں جس کے بعد سروس دوبارہ شروع ہو، یا متبادل کنٹینرز کو رول آؤٹ کریں۔ [S22](https://keendigit.com/ur/insights/nginx-remediation-guide#source-22) اگر آپ NGINX کا نظم `systemd` ساکٹ، کنٹینر انٹری اسکرپٹ، یا ایک سے زیادہ تنصیبات کے ذریعے کرتے ہیں، تو آپ کو براہ راست یہ ماننے کے بجائے کہ `systemctl restart nginx` تمام مثالوں کا احاطہ کرتا ہے اصل لانچ ہدف اور عمل کا راستہ چیک کرنا چاہیے۔ ### 4.6 حقیقی بیرونی داخلی دروازے سے کاروباری رجعت کو قبول کریں اور کریں۔ کم از کم انجام دینے کی سفارش کی جاتی ہے: - کیا عام HTTPS، دوبارہ لکھے گئے راستے، جامد وسائل، اور `alias` نقشہ سازی کے صفحات درست ہیں؟ - کیا ریگولر `map` ڈسٹری بیوشن، متغیر root پاتھ، رسائی لاگ پاتھ، SNI/سرٹیفکیٹ روٹنگ، اور Stream پراکسی درست ہیں۔ - کیا نارمل اپ لوڈز، chunked اپ لوڈز، API درخواستیں اور HTTP/3 (جب فعال ہو) کے لیے اپ اسٹریم والیوم کی حدیں اب بھی توقع کے مطابق ہیں۔ - mTLS: سرٹیفکیٹ کی جائز درخواستیں کامیاب ہونی چاہئیں۔ گمشدہ، میعاد ختم، یا غیر مجاز سرٹیفکیٹس کو اب بھی مسترد کر دیا جانا چاہیے، اور TLS دوبارہ شروع/دوبارہ کنکشن کو غلطی سے اجازتوں کو تبدیل نہیں کرنا چاہیے۔ - آیا SSI صفحہ اور غیر مطابقت پذیر فائل تک رسائی عام ہے؛ ایرر لاگ میموری حوالہ جات یا بار بار Worker کریش کے لیے کوئی غیر معمولی درخواست نہیں دکھاتا ہے۔ - ٹریفک سوئچ کے بعد، پرانے ورژن کا عمل اور پرانی تصویری نقل سے باہر نکل جانا چاہیے تھا۔ جانچ خود یا مجاز ماحول میں کی جانی چاہیے۔ عام درخواست دھواں ٹیسٹ اکیلے یہ ثابت نہیں کر سکتا کہ میموری کی کمزوری کو ٹھیک کر دیا گیا ہے۔ بالآخر، سپلائر کا مقررہ ورژن، سورس کوڈ پیچ اور رن ٹائم ٹیسٹ کو قبولیت کے لیے مشترکہ طور پر قبول کیا جانا چاہیے۔ ## 5. تخفیف کے اقدامات جب فوری اپ گریڈ ممکن نہ ہو۔ یہ سیکشن خطرے میں کمی کا اختیار ہے، پیچ کی تبدیلی نہیں۔ تمام عارضی کنفیگریشن تبدیلیوں کا بیک اپ لیا جانا چاہیے، `nginx -t` کو عمل میں لایا جانا چاہیے، بیچوں میں جاری کیا جانا چاہیے، اور اگر ضروری ہو تو فوری طور پر واپس کر دیا جائے۔ [S3](https://keendigit.com/ur/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/ur/insights/nginx-remediation-guide#source-4) ### 5.1 بیرونی نمائش کی بنیاد پر ٹریفک کی ترجیح کو کنٹرول کریں۔ خدمات کے حملے کی سطح کو کم کرنے کو ترجیح دیں جن کو وقت پر اپ گریڈ نہیں کیا جا سکتا: انتظامی سطح اور اندرونی API پر بھروسہ مند سورس ایکسیس کنٹرول، اپ اسٹریم نیٹ ورک آئسولیشن یا مختصر مدت کے آف لائن شامل کریں۔ کنکشن شامل کریں، باڈی کی درخواست کریں اور زیادہ خطرہ والے داخلی راستوں پر شرح کی حد؛ اس بات کو یقینی بنائیں کہ درخواست کی پروسیسنگ چین سے پہلے داخلے سے متعلق NGINX پر ذریعہ کی تصدیق ہوتی ہے۔ واضح رہے کہ زیادہ تر خطرات بذات خود NGINX ڈیٹا جہاز کے اندر موجود ہیں، روایتی WAF قواعد حسب ضرورت کنفیگریشن ٹرگر حالات کا درست تعین نہیں کر سکتے ہیں۔ ### 5.2 `alias` / `rewrite`: دوبارہ لکھنے کے بعد `$request_filename` کا جائزہ لینے سے گریز کریں یہ چیک کرنے اور ایڈجسٹ کرنے کی سفارش کی جاتی ہے: - `rewrite` انجام دینے کی کوشش نہ کریں جو URI کو `alias` استعمال کرتے ہوئے `location` کے ساتھ ہی تبدیل کردے گا۔ - `$request_filename` استعمال کرنے سے گریز کریں جب URI دوبارہ لکھا گیا ہو لیکن صحیح پوزیشن میچ ابھی مکمل نہیں ہوا ہے۔ - `return`, `set`, `if`, `add_header` میں بالواسطہ متغیر حوالہ جات کی جانچ کریں، لاگ فارمیٹ تک رسائی حاصل کریں اور فائلیں شامل کریں۔ - کاروبار کی اجازت دیتے وقت واضح `root`/`try_files`/آزاد `location` استعمال کریں، لیکن صرف `alias` کو `root` میں تبدیل کریں۔ یہ فائل پاتھ سیمنٹکس کو بھی تبدیل کر سکتا ہے، جس کی ایک ایک کرکے تصدیق ہونی چاہیے۔ موجودہ کنفیگریشن کو اوور رائٹ کرنے کے لیے انٹرنیٹ پر عام "سیف ری رائٹ ٹیمپلیٹ" کو براہ راست کاپی نہ کریں۔ مختلف `location` سابقے اور دوبارہ لکھنے والے اہداف کا نتیجہ بالکل مختلف معنی کے ساتھ راستے کو الگ کرنے کا نتیجہ ہے۔ [S5](https://keendigit.com/ur/insights/nginx-remediation-guide#source-5) ### 5.3 `map`/Regex: کیپچر متغیر حالت مکسنگ کو کم کریں نامزد کیپچرز کو ترجیح دینے اور ان کے پھیلاؤ کے دائرہ کار کو محدود کرنے کی سفارش کی جاتی ہے، بجائے اس کے کہ `$1` جیسے گمنام کیپچرز کو وقت کے ساتھ ساتھ مختلف ریجیکس تشخیصی راستوں پر دوبارہ استعمال کیا جائے۔ مثال کے طور پر: ```nginx # 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整 map $host $tenant_root { default /srv/www/default; ~^(?[a-z0-9-]+)\.example\.net$ /srv/www/$tenant; } ``` یہ ٹکڑا صرف متغیر ملکیت کے آڈٹ سے آسان ڈھانچے کو ظاہر کرتا ہے۔ اس کا مطلب یہ نہیں ہے کہ یہ آزادانہ طور پر تمام CVE-2026-93479 ٹرگر پاتھ کو ختم کرنے کے لیے ثابت ہوا ہے۔ خاص طور پر، اس بات کا جائزہ لیں کہ آیا دیگر `root` یا `log_format` کے ذریعے کیپچر متغیرات کا حوالہ وقت سے پہلے دیا جاتا ہے، اور آیا `volatile`، متحرک راستے، اور ایک دوسرے پر منحصر تشخیصی سلسلہ موجود ہیں۔ F5/CERT تجویز کرتا ہے کہ نام کیپچر استعمال کریں اور استعمال کے دائرہ کار کو متعلقہ ریگولر میچنگ کنفیگریشن تک محدود رکھیں بطور قلیل مدتی ریلیف۔ [S3](https://keendigit.com/ur/insights/nginx-remediation-guide#source-3)[S6](https://keendigit.com/ur/insights/nginx-remediation-guide#source-6) ### 5.4 AIO + SSI: غیر ضروری فنکشن کے امتزاج کو بند کریں ایسے سرورز/راستوں کے لیے جنہیں SSI یا غیر مطابقت پذیر فائل I/O کی ضرورت نہیں ہے، استعمال کریں: ```nginx # 在适当的 http/server/location 上下文中配置 ssi off; aio off; ``` خطرے کو متحرک کرنے والے حالات کے نقطہ نظر سے، دونوں میں سے ایک کو بند کرنا عام طور پر بیان کردہ مخصوص سلسلہ کو ہٹانے کے لیے کافی ہوتا ہے۔ ایک ہی وقت میں بند ہونا صرف ان منظرناموں پر لاگو ہوتا ہے جہاں کاروبار اس قابلیت پر انحصار نہیں کرتا ہے۔ `include virtual`، ذیلی درخواستیں، کیشے، اور تھریڈ پول کے رویے کو چیک کریں۔ جب ریورس پراکسی لوڈ زیادہ ہوتا ہے، AIO کو بند کرنے سے تاخیر اور I/O کارکردگی تبدیل ہو سکتی ہے۔ [S7](https://keendigit.com/ur/insights/nginx-remediation-guide#source-7) ### 5.5 HTTP/3 باڈی انجیکشن کی درخواست کریں: اگر ضروری ہو تو عارضی طور پر داخلہ بند کریں کو غیر فعال کریں۔ `quic` سننے والا شامل ہے HTTP/3 ، منسوخ کریں۔ `Alt-Svc` جوابی ہیڈر جو اعلان کرتا ہے۔ HTTP/3 ، اور چیک کریں کہ آیا کنارے کی پرت/لوڈ بیلنسر اب بھی بھیجتا ہے۔ QUIC براہ راست غیر مرمت شدہ سے درخواست کرتا ہے۔ NGINX : ```nginx # 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen server { listen 443 ssl; # 保留 HTTPS/TCP 入口 # 对支持新版语法的构建，可在此使用 http2 on; # 删除原有的 listen 443 quic reuseport; # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项） # 其余证书、server_name、location 等配置保持不变 } ``` مندرجہ بالا صرف تبدیلی کے فرق کی وضاحت ہے، ایک مکمل سرور کنفیگریشن نہیں جسے انفرادی طور پر فعال کیا جا سکتا ہے۔ HTTP/2 کی ترتیب کا نحو NGINX ورژن سے متعلق ہے۔ اگر آپ کو HTTP/2 کو برقرار رکھنے کی ضرورت ہے، تو آپ کو متعلقہ ورژن کے مطابق `http2 on;` یا موجودہ درست نحو استعمال کرنا چاہیے، اور `nginx -t` کے ساتھ چیک کریں۔ پورے سیکشن کو اس سیکشن کے ساتھ تبدیل کرنے کے بجائے، تعیناتی سے پہلے موجودہ سرور کنفیگریشن کے ساتھ مل جانا چاہیے۔ UDP 443 فائر وال، HTTP/3 ٹرمینیشن لوکیشن اور CDN/ فرنٹ پراکسی کے کلائنٹ فال بیک پاتھ کو بھی چیک کرتا ہے۔ قلیل مدتی تخفیف کی ایک اور قسم متاثرہ پراکسی پاتھ پر `proxy_request_buffering off;` کا استعمال کرنا ہے، لیکن اس سے اپ اسٹریم درخواست باڈی اسٹریمنگ، ناکامی کی دوبارہ کوششوں، اور کچھ اپ لوڈ ورک فلوز کے رویے میں تبدیلی آئے گی۔ صرف کافی جانچ اور تصدیق کے بعد استعمال کیا جائے گا کہ ہدایت متاثرہ HTTP/3 پراکسی پاتھ کو متاثر کرتی ہے۔ [S8](https://keendigit.com/ur/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/ur/insights/nginx-remediation-guide#source-18) ### 5.6 TLS سیشن ٹکٹ: ترجیحی تحفظ mTLS توثیق کی حد اگر اپ گریڈ کرنا ممکن نہیں ہے اور مثال مشترکہ سیشن کیشے + خودکار ٹکٹ کلید کی گردش پر انحصار کرتی ہے تو اندازہ کریں: ```nginx # 在 nginx http/server 适当作用域进行配置 ssl_session_tickets off; ``` یہ TLS سیشن ٹکٹ کے طریقہ کار کو بند کر سکتا ہے، اس طرح اس خطرے میں بیان کردہ ٹکٹ کی جعلسازی کے راستے کو ہٹا سکتا ہے۔ تاہم، یہ سیشن کی بحالی کی کارکردگی کو متاثر کر سکتا ہے۔ آپ صرف mTLS کلائنٹ سرٹیفکیٹ کی توثیق کو "خطرے سے بچنے" کے لیے بند نہیں کر سکتے، کیونکہ اس سے تصدیق کی اصل حد براہ راست حذف ہو جائے گی۔ [S9](https://keendigit.com/ur/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/ur/insights/nginx-remediation-guide#source-12) واضح `ssl_session_ticket_key` فائلوں اور محفوظ گردش کو پیشہ ورانہ TLS انتظامی عمل کے ذریعے خود کار طریقے سے پیدا ہونے والے حالات کو روکنے کے لیے بھی استعمال کیا جا سکتا ہے، لیکن کلیدی تحویل، مکمل نوڈ کی تقسیم، گردش، اور پرانے ٹکٹ لائف سائیکل سبھی کو احتیاط سے آڈٹ کرنے کی ضرورت ہے۔ عام ویب کنفیگریشن یا عارضی ہنگامی حالات کے لیے اسکرپٹس میں طویل مدتی دوبارہ قابل استعمال کلید کو ہارڈ کوڈ کرنے کی سفارش نہیں کی جاتی ہے۔ mTLS استعمال کرنے والی اہم خدمات کو TLS سیشن کی بحالی کے رویے اور درست کلائنٹ سرٹیفکیٹ کے بغیر درخواستوں کو مسترد کرنے کے لیے بھی نگرانی کی جانی چاہیے۔ [S12](https://keendigit.com/ur/insights/nginx-remediation-guide#source-12) ### 5.7 آپریٹنگ سسٹم اور سرحدی تحفظ کا کردار ```bash # Linux：常见值 2 表示进程地址空间随机化处于完整启用状态 sysctl kernel.randomize_va_space ``` ASLR، غیر root ورکرز، صرف پڑھنے کے لیے کنٹینر فائل سسٹم، فائل کی کم سے کم اجازتیں اور نیٹ ورک آئسولیشن ممکنہ RCE کے اثرات کو کم کر سکتا ہے۔ ASLR ہیپ اوور فلو یا UAF کو ٹھیک نہیں کرتا اور اس بات کی گارنٹی نہیں دے سکتا کہ کارکن کریش نہیں ہوں گے۔ WAF، شرح کی حد اور درخواست کے باڈی سائز کی حدیں TLS ٹکٹ کلید کی مطابقت پذیری کو ٹھیک نہیں کرتی ہیں۔ [S4](https://keendigit.com/ur/insights/nginx-remediation-guide#source-4) ### 5.8 عام غلط فہمی: یہ آپریشن مرمت مکمل کرنے کے لیے کافی نہیں ہیں | عام آپریشنز | یہ ناکافی کیوں ہے؟ | | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | "nginx -v نسبتا نیا لگتا ہے" | اس کا تعلق جس برانچ سے ہے، ریلیز ورژن کا مکمل بیک پورٹ شدہ پیکیج ورژن اور آن لائن عمل کو چیک نہیں کیا گیا ہے۔ | | "انٹرانیٹ میں سے صرف ایک کو اپ گریڈ کیا گیا تھا" | پرانا Worker/پرانا کنٹینر/پرانا CDN اصل مثال اب بھی درخواستیں وصول کرتا ہے | | "سائٹ پی ایچ پی/متحرک ٹیگز استعمال نہیں کرتی" | یہ خرابی NGINX کور پاتھ یا پروٹوکول پارسنگ میں ہوتی ہے اور پی ایچ پی کے عمل پر انحصار نہیں کرتی ہے۔ | | "WAF/Cloudflare کھولنا کافی ہے" | WAF تمام NGINX کنفیگریشن پر منحصر میموری خامیوں یا TLS دوبارہ شروع کرنے کی خامیوں کو روکنے کے لیے ثابت نہیں ہو سکتا | | "پہلے سے ہی ASLR کھول دیا گیا ہے" | صرف مشکل میں کمی کا فائدہ اٹھانا؛ درخواست انجیکشن کے ساتھ DoS اب بھی ممکن ہے۔ | | "HTTP/3 عوامی نیٹ ورک کے سامنے نہیں ہے، لہذا اپ گریڈ کرنے کی بالکل ضرورت نہیں ہے" | دیگر چار CVEs کو اب بھی آزادانہ تشخیص کی ضرورت ہے۔ اور پوشیدہ ماخذ سے براہ راست تعلق ہو سکتا ہے۔ | | "جولائی کی `map` خطرے کو طے کر دیا گیا ہے" | اکتوبر CVE-2026-93479 میں اسکرپٹ کی تشخیص کے بعد کے مسائل شامل ہیں | | "کیچنگ کو غیر فعال کرنے سے تمام مسائل حل ہو جاتے ہیں" | صرف کچھ TLS کیشے یا AIO منظرناموں کو متاثر کرتا ہے، اور عرف، اسکرپٹ، HTTP/3 کا احاطہ نہیں کرتا ہے۔ | ## 6. سرکاری پیچ کے نفاذ کے خیالات اور جائزہ کے نکات یہ سیکشن اکتوبر 2026 کے upstream NGINX اصلاحات کی پیروی کرتا ہے۔ ٹکڑوں میں پیچ کا جائزہ لینے کے لیے نمائندہ تبدیلیوں کی وضاحت ہوتی ہے۔ وہ مکمل نہیں ہیں، آزادانہ طور پر مرتب کی جانے والی اصلاحات۔ اپنی مرضی کے مطابق تعمیرات کے لیے، مکمل کمٹ، ارد گرد کے کوڈ اور ٹیسٹس کا جائزہ لیں، اور مکمل تعاون یافتہ ریلیز کو ترجیح دیں۔ [S5](https://keendigit.com/ur/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/ur/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/ur/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/ur/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/ur/insights/nginx-remediation-guide#source-9) ### 6.1 CVE-2026-15176: URI کو `alias` پاتھ میپنگ کو مسترد کرنے کی شرائط کو شامل کرنے کے لیے دوبارہ لکھا گیا ہے۔ `src/http/ngx_http_core_module.c` میں اپ اسٹریم کمٹ میں ترمیم شدہ `ngx_http_map_uri_to_path()`: ```diff - if (alias && !r->valid_location) { + if (alias && (!r->valid_location || r->uri_changed)) { ``` جائزہ فوکس: URI تبدیل ہونے پر فائل سسٹم کے راستے کا حساب لگانا جاری نہیں رکھا جا سکتا لیکن `alias` کے متعلقہ مقام کے الفاظ اب قابل بھروسہ نہیں ہیں۔ یہ ریاست سے پہلے کی رکاوٹ میں اضافہ ہے۔ یہ کوئی آسان جانچ نہیں ہے کہ آیا درخواست URI غیر قانونی حروف پر مشتمل ہے۔ [S5](https://keendigit.com/ur/insights/nginx-remediation-guide#source-5) ### 6.2 CVE-2026-93479: آؤٹ پٹ ڈیٹا کی لمبائی اور محفوظ لمبائی کے درمیان درست طریقے سے فرق کریں اپ اسٹریم کمٹ `src/http/ngx_http_script.c` اور `src/stream/ngx_stream_script.c` کو ایک ہی وقت میں اپ ڈیٹ کرتا ہے۔ بنیادی نیت کا خلاصہ یوں کیا جا سکتا ہے: ```diff - n = len; + n = 0; /* ...计算实际脚本输出长度... */ - value->len = n; - value->data = ngx_pnalloc(pool, n); + value->len = n + len; + value->data = ngx_pnalloc(pool, n + len); ``` یہاں، `pool` ایک مثالی پیرامیٹر کا نام ہے: اصل HTTP اور Stream مختص کے تاثرات مختلف ہیں۔ تبدیلی پہلے اسکرپٹ آؤٹ پٹ کی لمبائی کا حساب لگاتی ہے، پھر حتمی مختص میں مخصوص لمبائی کا اضافہ کرتی ہے تاکہ آؤٹ پٹ محفوظ جگہ کو اوور رائٹ نہ کرے۔ [S6](https://keendigit.com/ur/insights/nginx-remediation-guide#source-6) آڈیٹنگ اور بیک پورٹ کرتے وقت، HTTP/Stream کے متعلقہ ایویلیویٹر کا بھی احاطہ کیا جانا چاہیے۔ صرف `map` کی کنفیگریشن نحوی فائل کو چیک کرنے سے یہ ثابت نہیں ہو سکتا کہ خرابی ٹھیک ہو گئی ہے۔ ### 6.3 CVE-2026-97205: 8 بٹ غیر مطابقت پذیر آپریشن کی گنتی کے لیے حفاظتی حد مقرر کریں `src/http/ngx_http_request.h` پر Upstream شامل کیا گیا: ```c #define NGX_HTTP_MAX_BLOCKED 250 ``` اور اسی طرح کے اندراجات کو غیر مطابقت پذیر فائل ریڈنگ، کیشے ویٹنگ، آؤٹ پٹ فلٹرنگ اور تھریڈ آپریشن میں شامل کریں: ```c if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) { /* 使用同步路径，或者拒绝新的异步操作 */ } ``` فوکس کا جائزہ لیں: تمام اصل کوڈ پاتھز جو `r->main->blocked` کو شامل کریں گے کا احاطہ کیا جانا چاہیے۔ آپ صرف ہیڈر فائل میں تھریشولڈ مستقل نہیں لکھ سکتے ہیں۔ بیک پورٹ کو سنکرونس فال بیک، غیر مطابقت پذیر کال بیک اور ایرر ریٹرن کے مکمل کوآرڈینیشن کو بھی چیک کرنے کی ضرورت ہے تاکہ یہ یقینی بنایا جا سکے کہ کاموں کے براہ راست مسترد ہونے سے تعطل یا ریفرنس کا رساو نہیں ہوگا۔ [S7](https://keendigit.com/ur/insights/nginx-remediation-guide#source-7) ### 6.4 CVE-2026-95101: نامعلوم فریموں کے لیے الگ سے `skip` کی حیثیت برقرار رکھیں اپ اسٹریم HTTP/3 پارسر اسٹیٹس اسٹرکچر میں `skip` فیلڈ کو شامل کرتا ہے اور اسٹیٹس سیپریشن انجام دیتا ہے: ```c if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) { st->skip = st->length; st->length = 0; st->state = sw_skip; } /* ... */ rc = ngx_http_v3_parse_skip(b, &st->skip); ``` کلید "نامعلوم HTTP/3 فریموں کو غیر فعال کرنا" نہیں ہے، بلکہ اس بات کو یقینی بنانا ہے کہ متعدد ریڈز میں، چھوڑے گئے بائٹ کاؤنٹ اور DATA پے لوڈ کی لمبائی ہمیشہ آزاد ریاستوں کے زیر انتظام ہے۔ جائزوں کو نامعلوم فریم کراس بفر شارڈنگ، اور `client_max_body_size` کی حتمی مستقل مزاجی پر توجہ مرکوز کرنی چاہیے۔ [S8](https://keendigit.com/ur/insights/nginx-remediation-guide#source-8) ### 6.5 CVE-2026-97629: مکمل TLS کلیدی سلاٹ سرنی کو ہم آہنگ کریں اپ اسٹریم تبدیلیاں `src/event/ngx_event_openssl.c` پر واقع ہیں: ```diff ngx_memcpy(keys->elts, cache->ticket_keys, - 2 * sizeof(ngx_ssl_ticket_key_t)); + keys->nelts * sizeof(ngx_ssl_ticket_key_t)); ``` اصل تصویر میں تین کلیدی سلاٹس تھے، لیکن صرف پہلے دو کو کاپی کیا گیا تھا۔ اس کے بجائے، اس بات کو یقینی بنانے کے لیے کہ Worker کا ووٹنگ کلید سیٹ مشترکہ میموری کے مطابق ہے۔ جائزہ لیتے وقت، اس بات کی بھی تصدیق کریں کہ صرف ایک بار `memcpy` کی لمبائی کی ترمیم کو چیک کرنے کے بجائے، سرنی کی تخصیص، ابتدا، مشترکہ تالا اور گردش کی منطق مطابقت رکھتی ہے۔ [S9](https://keendigit.com/ur/insights/nginx-remediation-guide#source-9) ### 6.6 صرف بکھرے ہوئے پیچ کے ٹکڑے لگانے کی سفارش کیوں نہیں کی جاتی ہے؟ یہ پانچ ترمیمات بالترتیب `src/http`، `src/stream`، `src/http/v3`، اور `src/event` پر محیط ہیں، اور پرانے ورژن میں سیکیورٹی بیک پورٹ اور غیر سرکاری توسیعات ہو سکتی ہیں۔ بیک پورٹنگ کو درج ذیل چیک میٹرکس بنانا چاہیے: | آبجیکٹ چیک کریں۔ | جس کی تصدیق ہونی چاہیے۔ | | ----------------- | ---------------------------------------------------------------------------------- | | پیچ کا ذریعہ | باضابطہ جمع کرانا، مماثل ہدف ورژن، مکمل پیچ اور دستخط کی تصدیق | | اصل پیچ سیٹ | تاریخی ترمیمات جیسے CVE-2026-42533، ڈسٹری بیوشن بیک پورٹ وغیرہ سے متصادم نہیں ہے۔ | | کوڈ کا راستہ | HTTP + Stream اسکرپٹ، AIO/thread، HTTP/3، OpenSSL ٹکٹ سبھی شامل ہیں | | مرتب کردہ ہم آہنگ | OpenSSL، PCRE، ماڈیول ABI، ڈائنامک ماڈیول اور لنک پر انحصار مطابقت رکھتا ہے | | فنکشنل رجعت | `alias` دوبارہ لکھنا، متحرک لاگ، SSI/AIO، HTTP/3 اپ لوڈ، mTLS سیشن کا دوبارہ آغاز | | رن ٹائم | تمام Worker/Pods نئی تصدیق شدہ تعمیرات چلاتے ہیں، کوئی میراثی تصویر باقی نہیں رہتی | ان ٹیموں کے لیے جو اپنی ریلیز کو برقرار رکھتی ہیں، یہ سفارش کی جاتی ہے کہ وہ ہر ایک CVE کے لیے قابل آڈیٹ پیچ IDs، پیکیج ورژن، لاگ لاگز، اور ریگریشن رپورٹس رکھیں۔ عام آپریشن اور دیکھ بھال کے لیے، سب سے محفوظ حل یہ ہے کہ وینڈر کی مکمل سیکیورٹی اپ ڈیٹس کو انسٹال کیا جائے۔ ## 7. تاریخی کمزوری پیچھے ہٹنا، پرانی شاخیں اور دیگر مصنوعات ### 7.1 NGINX بنیادی کمزوری مئی سے ستمبر 2026 تک بیک وقت تصدیق کے قابل ہے بہت سے NGINX مثالیں جو طویل عرصے سے اپ ڈیٹ نہیں ہوئی ہیں نہ صرف اکتوبر کے نئے شمارے سے متاثر ہوئی ہیں۔ مستقبل قریب میں نمائندہ مرمت نوڈس درج ذیل ہیں: [S1](https://keendigit.com/ur/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/ur/insights/nginx-remediation-guide#source-2) | سی وی ای | پہلے فکس ریلیز | اہم خطرات اور شرائط جن کے لیے آڈٹ کی ضرورت ہوتی ہے۔ | | -------------- | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | | CVE-2026-42945 | Stable 1.30.1 / Mainline 1.31.0، 13 مئی | `rewrite` گمنام ریجیکس کیپچر اور متبادل منطق ہیپ اوور فلو کو متحرک کرتی ہے، ممکنہ RCE؛ جنگلی حملوں کی کوششوں کی عوامی اطلاعات ہیں۔ | | CVE-2026-9256 | Stable 1.30.2 / Mainline 1.31.1، 22 مئی | `rewrite` میں اوور لیپنگ ریجیکس کیپچر اور لمبائی کا تخمینہ اوور فلو کا باعث بنتا ہے | | CVE-2026-42055 | Stable 1.30.3 / Mainline 1.31.2، 17 جون | HTTP/2 اپ اسٹریم یا جی آر پی سی کے لیے مخصوص کنفیگریشن، بڑی درخواست ہیڈر کی حالت بفر اوور فلو کو متحرک کرتی ہے | | CVE-2026-42530 | Mainline 1.31.2، 17 جون | HTTP/3 استعمال کے بعد مفت؛ آفیشل مارک متاثرہ رینج `1.31.0–1.31.1` | | CVE-2026-42533 | Stable 1.30.4 / Mainline 1.31.3، 15 جولائی | `map` + regex کیپچر متغیر تشخیص ہیپ اوور فلو کا سبب بنتا ہے، اور اس کے بعد کے پیچ اکتوبر میں CVE-2026-93479 کے ساتھ ریگریشن ارتباط رکھتے ہیں۔ | | CVE-2026-60005 | Stable 1.30.4 / Mainline 1.31.3، 15 جولائی | `ngx_http_slice_module` میموری کا مواد مخصوص متغیر اور کیش اپ ڈیٹ کی شرائط کے تحت لیک ہوا | | CVE-2026-56434 | Stable 1.30.4 / Mainline 1.31.3، 15 جولائی | SSI کا تعلق UAF سے ہے۔ اکتوبر کے AIO کی گنتی کے خطرے کی وجہ سے وہی root نہیں ہے | | CVE-2026-90439 | Stable 1.30.5 / Mainline 1.31.6، 15 ستمبر | HTTP/3 + مخصوص OpenSSL ورژن مجموعہ کا محدود ہیپ اوور فلو، بنیادی طور پر کریش/محدود میموری کرپٹ کے طور پر ظاہر ہوتا ہے۔ | دیگر خطرات جیسے NGINX Core، HTTP/2، چارسیٹ، اور SMTP کا اعلان 2026 میں کیا گیا تھا ان کی بھی سرکاری سیکیورٹی بلیٹنز کے مطابق تفتیش کی جانی چاہیے۔ یہ جدول جان بوجھ کر عام واقعات پر توجہ مرکوز کرتا ہے جو موجودہ NGINX عوام کا سامنا کرنے والی ریورس پراکسی تعیناتیوں سے زیادہ متعلقہ ہیں اور میموری کی حفاظت یا سالمیت کے مضمرات کی درخواست کرتے ہیں۔ 2026 میں تمام CVE نہیں ہیں۔ فہرست۔ [S1](https://keendigit.com/ur/insights/nginx-remediation-guide#source-1) #### CVE-2026-42945 پر کیوں خصوصی توجہ دیں۔ سرکاری ایجنسیوں کی طرف سے حفاظتی بلیٹن ہیں جو مئی میں اس `rewrite` خطرے کے لیے جنگلی استحصال کی سرگرمیوں اور عوامی استحصال کوڈ کی معلومات کو ریکارڈ کرتے ہیں۔ اس لیے، ایسی مثالوں کے لیے جن میں مئی سے لے کر اب تک طویل عرصے سے پیچ نہیں کیا گیا ہے اور پبلک نیٹ ورک پر پیچیدہ ریگولر ایکسپریشن ری رائٹ کھلے ہوئے ہیں، مرمت مکمل کرنے کے علاوہ، غیر معمولی Worker کریش، ایکسیس لاگز اور اس وقت مشکوک تبدیلیوں کا بھی جائزہ لیا جانا چاہیے۔ [S23](https://keendigit.com/ur/insights/nginx-remediation-guide#source-23) "حملے کی کوشش ہوئی" خود بخود یہ ثابت نہیں کرتا کہ حملہ آور نے قابل اعتماد طریقے سے ہر ہدف پر کمانڈز پر عمل کیا ہے۔ جب واقعہ کا ردعمل شامل ہوتا ہے، تو سمجھوتہ کے اشارے اور عمل کے کریشوں کو استحقاق میں اضافے یا استقامت کے حقیقی ثبوت سے الگ الگ تفتیش کرنا چاہیے۔ ### 7.2 پرانے ورژنز اور ڈسٹری بیوشن بیک پورٹ کے لیے علاج NGINX مختلف شاخوں کے اپنے اپنے سپورٹ سائیکل اور مختلف خطرات کے تعارف کے اوقات ہوتے ہیں۔ پانچ نئے پیچ بغیر جائزہ کے تمام ابتدائی ماخذ درختوں پر نہیں لگائے جا سکتے۔ | منظر | تجویز کردہ حکمت عملی | | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ریلیز ورژن نے مکمل حفاظتی پیچ کا اعلان کیا ہے۔ | وینڈر پیکجز کا استعمال کریں اور مکمل پیکیج ورژن کو دستاویز کریں؛ غیر مطابقت پذیر upstream bare binaries کے ساتھ تبدیل کرنے سے گریز کریں۔ | | Debian 12 اور دیگر متاثرہ ریلیز جو ابھی تک اس بیچ کے تمام CVEs میں شامل نہیں ہیں | رسک ورک آرڈرز جمع کروائیں، بیرونی نمائش کو محدود کریں، اور سپلائر/ELTS کی حیثیت چیک کریں۔ ہجرت کریں یا جب ضروری ہو تو قابل تصدیق مینٹیننس ریلیز چین استعمال کریں۔ | | تاریخی شاخیں جو اپ اسٹریم سپورٹ کو ختم کر چکی ہیں۔ | تعاون یافتہ ورژن میں منتقلی کو ترجیح دیں؛ اگر قلیل مدتی بیک پورٹنگ ضروری ہو تو دیکھ بھال کرنے والے انحصار اور پیچ کی مطابقت کا جائزہ لیں گے، اور مکمل ٹیسٹ لکھیں گے۔ | | NGINX کانٹے کے ساتھ آتا ہے (OpenResty، Tengine، حسب ضرورت گیٹ وے) | پہلے اس بات کا تعین کریں کہ آیا متعلقہ کوڈ کا راستہ شامل ہے، اور پھر فورک مینٹینر کا سیکیورٹی اسٹیٹمنٹ استعمال کریں۔ یہ براہ راست اپ اسٹریم ورژن کے برابر نہیں ہو سکتا۔ | | سیکیورٹی پیچ کاروباری فعالیت میں تبدیلیوں کا باعث بنتے ہیں۔ | مرحلہ وار رول آؤٹ، ورژن کے درمیان ٹریفک سوئچنگ، اور کنفیگریشن موافقت کو اپنائیں؛ عوامی نیٹ ورک کے غیر فکسڈ ورژن کو تنہائی کے بغیر بحال کرنا مناسب نہیں ہے۔ | ### 7.3 njs، Ingress اور NGINX کور کے لیے علیحدہ علاج - njs: NGINX مین پروگرام کے علاوہ، آپ کو خود NGINX JavaScript ماڈیول کا ورژن بھی چیک کرنا ہوگا۔ `njs 1.0.2` اکتوبر 2026 کے XML کو پارس کرنے والے میموری کی تھکن اور XML کی توثیق کے عدم مطابقت کے مسئلے کو ہستی کے حوالہ کی خصوصیات کے ساتھ حل کرتا ہے۔ `nginx-saml` کا استعمال کرتے ہوئے XML دستخطی تصدیق کے ساتھ منسلک تعیناتیوں کے لیے، آپ کو پلگ ان منظرناموں کے لیے سرکاری njs ہدایات کو مزید پڑھنا چاہیے۔ [S20](https://keendigit.com/ur/insights/nginx-remediation-guide#source-20) - F5 NGINX Plus / NGINX انگریس کنٹرولر: پلس، کنٹرولر اور گیٹ وے فیبرک میں ہر ایک میں اضافی سیکیورٹی بلیٹنز، مختلف پیکیجنگ ورژن اور منفرد پالیسی کے خطرات ہوسکتے ہیں۔ ایک پرت کو اپ گریڈ کرنے کا مطلب خود بخود دوسری پرت کو اپ ڈیٹ کرنا نہیں ہے۔ [S19](https://keendigit.com/ur/insights/nginx-remediation-guide#source-19) - Kubernetes کمیونٹی ingress-nginx: Kubernetes حکام پہلے ہی اعلان کر چکے ہیں کہ کنٹرولر نے مارچ 2026 میں دیکھ بھال بند کر دی ہے، اور اس کے گودام کو F5 کنٹرولر کے ساتھ الجھایا نہیں جا سکتا۔ متاثرہ کاروباروں کو نئے سیکیورٹی ورژن کا انتظار کرنے کی بجائے ہموار منتقلی کی منصوبہ بندی کرنی چاہیے اور Ingress تشریحات اور Gateway API سیمنٹک اختلافات کی تصدیق کرنی چاہیے۔ [S21](https://keendigit.com/ur/insights/nginx-remediation-guide#source-21) ## 8. قبولیت کے معیار اور فالو اپ معائنہ یہ سفارش کی جاتی ہے کہ درج ذیل فہرست کو کام کے احکامات کی تبدیلی کے لیے قبولیت کی شرائط کے طور پر استعمال کیا جائے۔ | پروجیکٹ | اہلیت کے معیارات | ثبوت جو برقرار رکھا جا سکتا ہے۔ | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | اثاثہ اور پورٹل کوریج | تمام بیرونی اور براہ راست منسلک مثالیں جو CDN کو نظرانداز کر سکتی ہیں ان کی فہرست بنائی گئی ہے۔ | ڈومین کا نام، ایل بی، آئی پی، پوڈ/کنٹینر کی فہرست | | پیکیج کا ذریعہ اور مرمت کا دائرہ | تمام قابل اطلاق CVEs کا احاطہ کرنے کے لیے تصدیق شدہ ورژن استعمال کریں۔ | اپ اسٹریم سیکیورٹی ایڈوائزری، USN/DSA، پیکیج ورژن، امیج ڈائجسٹ | | پرانا عمل ختم ہو جاتا ہے۔ | تمام پرانے master/worker/کنٹینرز کو تبدیل کر دیا گیا ہے | پی آئی ڈی/اسٹارٹ ٹائم، رولنگ ڈیپلائمنٹ سٹیٹس، چل رہی امیج | | کنفیگریشن آڈٹ | اعلی خطرے کے امتزاج کو ختم کر دیا گیا ہے یا پیچ کے ذریعے احاطہ کیا گیا ہے، اور وراثت کے تعلقات کی تصدیق کی گئی ہے | ترمیم شدہ خلاصہ اور `nginx -T` کا آڈٹ ریکارڈ | | TLS/mTLS | قابل اعتماد سرٹیفکیٹ پاس؛ غلط یا گمشدہ سرٹیفکیٹس کو مسترد کر دیا جاتا ہے؛ سیشن دوبارہ شروع کرنا تصدیق کو نظرانداز نہیں کرتا ہے۔ | منفی/مثبت اجازت ٹیسٹ، کنٹرول شدہ TLS ٹیسٹ کے نتائج | | HTTP/3 درخواست کا باڈی | طے شدہ راستے کو فعال کریں؛ upstream درخواست باڈی اور تھروٹلنگ صحیح طریقے سے برتاؤ کرتے ہیں۔ | HTTP/3، پراکسی اپ لوڈ، حجم کی حد ریگریشن ٹیسٹ | | SSI/AIO | فنکشن ضروریات کو پورا کرتا ہے، Worker میں کوئی غیر معمولی اسقاط نہیں ہے | کاروباری رجعت، حادثے اور غلطی کی شرح کی نگرانی | | آپریشن اور بحالی کی نگرانی | کوئی واضح رعایت نہیں 5xx، SIGSEGV، عمل بار بار خارج ہوتا ہے | تبدیلیوں سے پہلے اور بعد میں سروس کے اشارے اور لاگ | | رول بیک حکمت عملی | اگر رول بیک ضروری ہو تو پہلے نمائش کو محدود کریں اور حفاظتی حدود کو محفوظ رکھیں | آرڈرز، ایمرجنسی فلو، اور قرنطینہ پلانز کو تبدیل کریں۔ | | بعد کی زندگی سائیکل | سیکیورٹی بلیٹن سبسکرپشنز، کنٹینر اپ ڈیٹ فریکوئنسی، اور برانچ مائیگریشن پلانز کا تعین کریں۔ | لیجر، ذمہ دار شخص اور اگلی آڈٹ کی تاریخ کو اپ گریڈ کریں۔ | ### 8.1 آپ کو لاگ اور چلنے کی حالت میں کس چیز پر توجہ دینی چاہیے؟ طویل عرصے سے سامنے آنے والے سرورز پر اسامانیتاوں کا ازالہ کریں۔ `worker process exited on signal` 、 `SIGSEGV` , ناکامی کے اضافے کی درخواست کریں، غیر معمولی ذریعہ تک رسائی کی جمع، غیر متوقع TLS سیشن دوبارہ شروع کرنا/توثیق کی کامیابی اور غیر معمولی پسدید کی درخواست جسمانی رویے. یہ اشارے صرف تفتیشی سراغ کے طور پر استعمال کیے جا سکتے ہیں اور یہ براہ راست ثابت کرنے کے لیے کافی ثبوت نہیں ہیں کہ کسی مخصوص CVE کا استحصال کیا گیا ہے۔ متعلقہ نوشتہ جات کی کمی یہ ثابت نہیں کرتی ہے کہ حملہ نہیں ہوا ہے۔ ### 8.2 تجویز کردہ حتمی خطرے کے اختتامی الفاظ پیداواری ماحول کے لیے قبولیت کی رپورٹ کو درج ذیل قطعی اظہار کا استعمال کرنا چاہیے: > NGINX بیرونی سروس کے داخلے اور سافٹ ویئر پیکج کے ذریعہ کی نشاندہی کی گئی ہے۔ تمام قابل اطلاق واقعات کو اپ سٹریم آفیشل سیکورٹی ورژن میں اپ گریڈ کر دیا گیا ہے، یا ریلیز وینڈر کے ذریعے تصدیق شدہ بیک پورٹ مکمل ہو گیا ہے۔ پرانے Worker اور پرانے کنٹینرز کو تبدیل کر دیا گیا ہے۔ عرف/دوبارہ لکھنا/نقشہ، AIO/SSI، HTTP/3 درخواست کا باڈی اور TLS سیشن ٹکٹ/mTLS سے متعلقہ کنفیگریشنز کا آڈٹ کر لیا گیا ہے اور ان کا دوبارہ جائزہ لیا گیا ہے اور دوبارہ درخواست کی جانچ میں فنکشنل اور پاس کر لیا گیا ہے۔ ان مثالوں کے لیے جنہوں نے ابھی تک اپ گریڈ مکمل نہیں کیا ہے، اضافی طور پر نمائش کے علاقوں، معاوضے کے اقدامات، ذمہ دار افراد، اور تکمیل کی آخری تاریخوں کا اندراج کریں۔ اگر Debian 12 یا دیگر ریلیز کے لیے پیچ اب بھی نامکمل ہے، تو یہ مناسب نہیں ہے کہ قبولیت کے پورے فارم کو "مکمل" قرار دیا جائے۔ غیر حل شدہ CVE، چاہے کوئی متعلقہ ٹرگر کنفیگریشن ہو، الگ تھلگ کی حیثیت اور حتمی اپ گریڈ روٹ کو واضح طور پر ریکارڈ کیا جائے۔ *** ## ضمیمہ: حوالہ کردہ ذرائع اور لنکس تفصیل: متن میں `[Sx]` نمبر یکساں طور پر اس حصے سے مطابقت رکھتے ہیں۔ مندرجہ ذیل پراجیکٹ کے تحفظ کے اعلانات، کوڈ کمٹ، سپلائر کی رہائی کے اعلانات اور قومی سلامتی ایجنسی کی معلومات کو ترجیح دیتا ہے۔ بیان کردہ کمزوریوں کی شدت کو ہر جاری کرنے والے ادارے کی درجہ بندی کے معیار کے مطابق بیان کیا جاتا ہے۔ ڈیٹا کی تصدیق کی تاریخ 27 اکتوبر 2026 ہے۔ ### S1 — NGINX Open Source آفیشل سیکیورٹی بلیٹن - اپ اسٹریم سے متاثرہ ورژنز، فکس برانچز، اور پانچ اکتوبر CVEs کے آفیشل سیوریٹی لیول پر مشتمل ہے، اور 2026 تک تاریخی کمزوریوں کا بھی احاطہ کرتا ہے۔ ### S2 — NGINX آفیشل ورژن ریلیز ریکارڈ - - تصدیق کریں۔ 1.30.6 / 1.31.7 کی 2026-10-14 , 1.31.8 کی 2026-10-21 ، اور مئی سے ستمبر تک اہم سیکیورٹی ریلیز سنگ میل۔ ### S3 - سنگاپور کی سائبر سیکیورٹی ایجنسی: F5 NGINX تین اہم خطرات - CVSS v4.0 9.2 اسکورز، ترتیب کی مطلوبہ شرائط، اور CVE-2026-15176، CVE-2026-93479، اور CVE-2026-97205 کے لیے عبوری تخفیف کی سفارشات کی تفصیل۔ ### S4 - NHS انگلینڈ: F5 NGINX ہائی رسک ایڈوائزری - میموری کی حفاظت کے مسائل کے DoS / ممکنہ RCE اثرات، اور ASLR کو بند یا نظرانداز کرنے جیسی رکاوٹوں کی وضاحت کرتا ہے۔ ### S5 - سرکاری ذریعہ کمٹ: CVE-2026-15176 - `ngx_http_map_uri_to_path()` میں `alias` اور `r->uri_changed` کے اسٹیٹس چیک سے مماثل ہے۔ ### S6 — سرکاری ذریعہ کمٹ: CVE-2026-93479 - HTTP/Stream اسکرپٹ کی لمبائی اور محفوظ بفر مختص منطق کے مطابق۔ ### S7 - سرکاری ذریعہ کمٹ: CVE-2026-97205 - `r->main->blocked` کاؤنٹ تھریشولڈ `NGX_HTTP_MAX_BLOCKED 250` اور غیر مطابقت پذیر پاتھ فال بیک سے مماثل ہے۔ ### S8 - سرکاری ذریعہ کمٹ: CVE-2026-95101 - حیثیت کی علیحدگی HTTP/3 نامعلوم فریم کی باقی لمبائی اور DATA درخواست کے جسم کی لمبائی کے مطابق ہے۔ ### S9 — سرکاری ذریعہ کمٹ: CVE-2026-97629 - سنکرونائزیشن TLS سیشن ٹکٹ کی گردش کے دوران تمام کلیدی سلاٹس سے مماثل ہے۔ ### S10 — F5: CVE-2026-15176 وینڈر کا اعلان - محرک عوامل کی فہرست بنائیں جیسے `alias`, `rewrite`, `$request_filename` اور رسائی کے نوشتہ جات۔ ### S11 — F5: CVE-2026-93479 وینڈر کا اعلان - نقشہ ریجیکس کیپچر، root پاتھ، اور لاگ متغیر تشخیصی حالات کی فہرست بنائیں۔ ### S12 — NGINX آفیشل TLS/SSL ماڈیول دستاویزات - تفصیل `ssl_session_cache`, `ssl_session_tickets`, `ssl_session_ticket_key` اور کلائنٹ سرٹیفکیٹ کی توثیق اور دیگر ہدایات۔ ### S13 — سیکیورٹی ایڈوائزری: Ubuntu USN-8955-1 (2026-10-26) - Ubuntu 22.04 / 24.04 / 26.04 / 26.10. کا مکمل سافٹ ویئر پیکیج فکسڈ ورژن اور تقسیم کا دائرہ فراہم کریں۔ ### S14 — سیکیورٹی ایڈوائزری: Debian DSA-6575-1 (2026-10-21) - Debian 13 / trixie کے لیے سیکیورٹی فکس پیکیج `1.26.3-3+deb13u10` کی تصدیق کریں، اور CVE-2026-93479 کے لیے بیک پورٹ ایسوسی ایشن کو ریکارڈ کریں۔ ### S15 — خطرے سے باخبر رہنا: Debian Security Tracker: CVE-2026-15176 - Debian 12 / bookworm اور Debian 13 / trixie کی ڈسٹری بیوشن فکس اسٹیٹس کی تصدیق کے لیے استعمال کیا جاتا ہے۔ یہ حیثیت مستقبل کے سیکیورٹی اپ ڈیٹس کے ساتھ بدل سکتی ہے۔ ### S16 — خطرے سے باخبر رہنا: Debian Security Tracker: CVE-2026-95101 - مختلف Debian برانچوں پر HTTP/3 خطرے کی سیکیورٹی کی حیثیت کی اضافی تصدیق۔ ### S17 — سیکیورٹی ایڈوائزری: Red Hat: CVE-2026-93479 - اکتوبر کے رجعت کے خطرے اور جولائی CVE-2026-42533 کے لیے طے شدہ باہمی تعلق کی ضمنی تفہیم۔ ### S18 — NGINX آفیشل ریورس پراکسی ماڈیول دستاویز - - کنفیگریشنز کی سیمنٹکس اور ڈیفالٹ ویلیوز جیسے `proxy_request_buffering`، `client_max_body_size`، `alias`، `aio`، وغیرہ سے استفسار کریں۔ ### S19 — NGINX Plus آفیشل ریلیز نوٹس - پلس CR/LTS برانچز، ورژن، پیچ اور اپ گریڈ مطابقت کی یاد دہانیوں کی فہرست بنائیں۔ ### S20 — NGINX JavaScript / njs آفیشل سیکیورٹی بلیٹن - - اکتوبر 2026 njs 1.0.2 اور متعلقہ XML کی توثیق، میموری کی تھکن کے مسائل پر مشتمل ہے۔ ### S21 — Kubernetes: کمیونٹی ingress-nginx سرکاری ریٹائرمنٹ ہدایات - - نوٹ کریں کہ پروجیکٹ نے مارچ 2026 میں نئی ریلیزز اور سیکیورٹی فکسز کو روک دیا تھا، اور یہ تجویز کیا جاتا ہے کہ برقرار رکھے ہوئے کنٹرولر یا Gateway API کو منتقل کیا جائے۔ ### S22 — NGINX آفیشل سروس کنٹرول اور آن لائن بائنری اپ گریڈ ہدایات - پراسیس سوئچنگ قبولیت کے لیے کنفیگریشن ری لوڈ، ری اسٹارٹ اور آن لائن قابل عمل فائل اپ گریڈ کے طریقوں میں فرق کریں۔ ### S23 - حکومتی سیکورٹی نوٹس: مئی 2026 NGINX دوبارہ لکھنے کا خطرہ - - CVE-2026-42945 کے لیے تاریخی خطرے کا پس منظر اور سیکیورٹی اپ ڈیٹ کی تجاویز فراہم کریں۔ جنگل میں ہونے والے استحصال سے متعلق فیصلے اس وقت ایجنسی کے اعلان اور واقعے کے مزید شواہد پر مبنی ہونے چاہئیں۔ ### S24 — F5: CVE-2026-95101 اور CVE-2026-97629 وینڈر کے اعلانات - - بالترتیب HTTP/3 درخواست باڈی انجیکشن اور خودکار TLS ٹکٹ کلید گردش کے خطرات کا احاطہ کرتا ہے۔ ### S25 — F5: CVE-2026-97205 وینڈر کا اعلان - تفصیل SSI/AIO محرک حالات اور ممکنہ میموری کی خرابی کے خطرات۔ [NGINX سیکیورٹی اپ ڈیٹ: کنفیگریشن چیک، اپ گریڈ اور تصدیق](https://keendigit.com/ur/news/nginx-security-update) ## سیکیورٹی کی بحالی سے متعلق مشاورت یقین نہیں ہے کہ سرٹیفکیٹ ٹرسٹ کی تبدیلیاں آپ کے سسٹمز کو کیسے متاثر کرتی ہیں؟ ہم متاثرہ کلائنٹس کا اندازہ لگانے اور سیکیورٹی اپ ڈیٹس کی منصوبہ بندی کرنے میں مدد کر سکتے ہیں۔ [سیکیورٹی اپ ڈیٹس پر تبادلہ خیال کریں۔]() [اصل صفحہ]() · [مواد کا اشاریہ]() KeenDigit LLC · وومنگ فائلنگ آئی ڈی: 2026-002106155 [وائیومنگ سیکرٹری آف سٹیٹ سے تصدیق کریں۔]() © 2026 KeenDigit LLC · Sheridan, Wyoming, USA · جملہ حقوق محفوظ ہیں۔