NGINX کمزوریاں: وجوہات، اصلاحات اور پیداوار کی تصدیق

تاریخی مضمون کی تاریخ: 2026-10-14 (انکشاف اور سیکیورٹی کی رہائی کی تاریخ)۔ 2026-10-27 کے ذریعے چیک کیے گئے ذرائع اور معلومات کی تکمیل۔

یہ مضمون واقعہ کی تاریخ کے لحاظ سے محفوظ کیا گیا ہے۔ 14 اکتوبر کے بعد جاری کردہ ورژن اور ریلیز اپ ڈیٹس ذیل میں شامل ہیں۔ سامعین: NGINX Open Source / NGINX Plus ویب سائٹ اور ریورس پراکسی آپریشن اور دیکھ بھال کرنے والے اہلکار، سیکیورٹی رسپانس اہلکار، ڈسٹری بیوشن مینٹینرز، نیز انجینئرز جو NGINX کو خود مرتب کرتے ہیں اور تیسرے فریق کے ماڈیولز کو برقرار رکھتے ہیں۔

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

TL؛ DR: ترجیحی کارروائیاں

1. سیکیورٹی اپ گریڈ کو ترجیح دیں۔ کے لیے nginx.org اوپن سورس پیکجز، اپ ڈیٹ کریں۔ Stable 1.30 کم از کم شاخ 1.30.6 اور Mainline 1.31 کم از کم شاخ 1.31.7. تصدیق کی تاریخ پر، 1.31.8 تازہ ترین ہے Mainline رہائی یہ الگ الگ شاخ کی بنیادیں ہیں۔ شاخوں میں ان کی تعداد کا موازنہ نہ کریں۔ S1 S2
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 فکس ہے۔ S13S14S15
3. پانچ ترتیب کے مجموعوں کا آڈٹ کریں: alias + rewrite + $request_filename , map + ریجیکس + متغیر تشخیص، aio + ssi + include virtual , HTTP/3 کے ساتھ proxy_request_buffering on ، اور ssl_session_cache shared:... خودکار کے ساتھ TLS سیشن ٹکٹ کی کلید گردش۔ صرف ایک ہدایت کی موجودگی استحصال کو قائم نہیں کرتی ہے۔ درخواست کے راستے اور ترتیب کے دائرہ کار کا اندازہ کریں۔ S1 S3 S4
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 S4 S8 S12

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

NGINX نے 14 اکتوبر 2026 کو 1.30.6 (Stable) اور 1.31.7 (Mainline) کو جاری کیا، پانچ سیکیورٹی مسائل کو حل کیا۔ تین میں ہیپ اوور فلو یا استعمال کے بعد مفت شامل ہیں اور F5 CVSS v4.0 کے 9.2 اسکورز موصول ہوئے ہیں۔ دیگر دو HTTP/3 درخواست کی سالمیت اور TLS کلائنٹ سرٹیفکیٹ کی تصدیق کو متاثر کرتے ہیں۔ S1S2S3

درجہ بندی کے نظام میں فرق کریں: nginx.org پانچوں مسائل کو medium کے طور پر درج کرتا ہے، جبکہ F5 CVSS v4.0 اور کچھ قومی سلامتی ایجنسیاں میموری کے تین مسائل کو نازک کے طور پر درجہ بندی کرتی ہیں۔ اس کا مطلب یہ نہیں ہے کہ تمام پانچ غیر مشروط ریموٹ کوڈ پر عمل درآمد کی اجازت دیتے ہیں۔ کنفیگریشن، ٹریفک کی رسائی اور حملہ آور کے کنٹرول سے باہر کے حالات۔ میموری کی خرابی اور قابل اعتماد RCE ثبوت کی مختلف سطحیں ہیں۔ S1S3S4

سی وی ای	تکنیکی مسائل اور عام محرک حالات	بنیادی اثر	تشخیص اور ضائع کرنا
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 کے اپنے درجات اور تقسیم کی شدت کی درجہ بندی میں مختلف شدت دکھا سکتی ہے۔ S1S3S4

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

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

2. وجہ کا تجزیہ

2.1 NGINX میں غلطی کے شکار تین حدود کو سمجھیں

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

1. متغیر تشخیص اور میموری کا سائز مطابقت پذیر ہونا چاہیے: rewrite درخواست URI کو تبدیل کرنے کے بعد، راستے کی نقشہ سازی موجودہ موثر location کے مطابق ہونی چاہیے۔ جب اسکرپٹ مترجم متغیر کی لمبائی کا حساب لگاتا ہے، تو لکھنے کی جگہ کو اصل آؤٹ پٹ اور مخصوص علاقوں کا احاطہ کرنا چاہیے۔
2. غیر مطابقت پذیر کارروائیوں کو درخواست کردہ میموری کے لائف سائیکل کو بڑھانا چاہیے: جب فائل پڑھنا اور لکھنا، کیش ویٹنگ یا تھریڈ کے کام نامکمل ہوتے ہیں، تو متعلقہ درخواست میموری پول کو پہلے سے جاری نہیں کیا جا سکتا۔
3. پروٹوکول اسٹیٹس اور سیکیورٹی اسٹیٹس کو ملا یا چھوڑا نہیں جاسکتا: HTTP/3 نامعلوم فریم اسکیپنگ کی لمبائی کو DATA درخواست کے جسم کی لمبائی کے طور پر شمار نہیں کیا جاسکتا۔ TLS دستخطی تصدیق میں حصہ لینے والے تمام کلیدی سلاٹس کو سیشن ٹکٹ کی گردش کے دوران صحیح طریقے سے شروع اور مطابقت پذیر ہونا چاہیے۔

مندرجہ ذیل مواد NGINX اپ اسٹریم فکس کمٹ اور وینڈر کے اعلان پر مبنی ہے تاکہ اس ناکامی کے طریقہ کار کی وضاحت کی جا سکے جس کو متحرک کیا جا سکتا ہے۔ مثال کا ٹکڑا تجزیہ کے لیے ہے، یہ مکمل کوڈ نہیں ہے جسے براہ راست پیداواری ماحول کی مرمت کے لیے استعمال کیا جا سکے۔ S5S6S7S8S9

2.2 CVE-2026-15176: alias اور دوبارہ لکھے گئے URI کے درمیان راستے کی نقشہ سازی غلط ہے۔

NGINX میں، مماثل location اور اس کے alias فائل کے راستے کا تعین کرتے ہیں۔ rewrite موجودہ درخواست URI کو تبدیل کر سکتا ہے۔ دوبارہ لکھنے کے بعد، اصل location میپنگ کے ذریعے استعمال ہونے والے مفروضے مزید برقرار نہیں رہ سکتے ہیں۔

متاثرہ پروسیسنگ پاتھ نے مناسب طور پر چیک نہیں کیا کہ آیا alias اسٹیٹس ngx_http_map_uri_to_path() میں چیک کرتے وقت درخواست دوبارہ لکھی گئی تھی۔ جب کنفیگریشن دوبارہ لکھنے کے بعد $request_filename کا جائزہ لینا جاری رکھتی ہے، تو راستہ ان مفروضوں کے ساتھ بنایا جا سکتا ہے جو موجودہ URI حالت کے مطابق نہیں ہے، آخر کار ہیپ میموری پر حد سے باہر لکھنے کو متحرک کرتا ہے۔ S5

عام مجموعہ (صرف کنفیگریشن آڈٹ کے لیے جوابی مثال کے طور پر استعمال کیا جاتا ہے، تعیناتی کی سفارش نہیں کی جاتی ہے):

# 仅用于识别风险模式：不是修复配置
location /foo/ {
    alias /srv/alias-root/;
    rewrite ^/foo/.*$ /new-path;
    return 200 $request_filename;
}

خطرہ صرف return تک محدود نہیں ہے: set, if, add_header, log_format, وغیرہ کو بھی آڈٹ کرنے کی ضرورت ہے اگر $request_filename کی تشخیص اسی عمل میں شروع ہوتی ہے۔ مثال کے طور پر return صرف اس ریاستی راستے کو دیکھنے میں آسان بناتا ہے، اس کا استعمال یہ اندازہ لگانے کے لیے نہیں کیا جا سکتا کہ تمام پروڈکشن کنفیگریشنز اوور فلو پیدا کریں گی۔ S5S10

حملے کے نتائج: درخواست کی تعمیر Worker کو دوبارہ شروع کرنے یا سروس میں رکاوٹ کا سبب بن سکتی ہے۔ ASLR جیسے حالات میں بند ہونا یا اسے نظرانداز کیا جا سکتا ہے، ممکنہ RCE ہے۔ اپ اسٹریم پیچ کا بنیادی مقصد alias سیاق و سباق میں دوبارہ لکھی گئی URI پاتھ میپنگ کو مکمل کرنے سے انکار کرنا ہے جو کہ اب درست نہیں ہے، بجائے اس کے کہ کسی مخصوص بفر کو بڑھایا جائے۔ S5S10

2.3 CVE-2026-93479: اسکرپٹ کی تشخیص میں “محفوظ جگہ” اور حقیقی متغیر لمبائی کے درمیان مماثلت نہیں

NGINX کے HTTP اور Stream ماڈیولز میں اسکرپٹ ایویلیوٹرز ہوتے ہیں جو لغوی تاروں اور متغیر اقدار کو نتیجہ کے سٹرنگ میں جوڑتے ہیں۔ درخواست کی مثالوں میں HTTP دستاویز root راستے، لاگ پاتھ تک رسائی، اور Stream میں متغیر اظہار شامل ہیں۔

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

شراکت دار عناصر	کیوں اس پر توجہ دینے کے قابل ہے۔
regex map میں	کیپچر متغیر تشخیص میں آزاد لائف سائیکل اور کیشنگ رویہ ہو سکتا ہے۔
گمنام کیپچرز جیسے $1، $2، وغیرہ۔	دوسرے ریگولر ایکسپریشنز یا ایکسپریشنز کے ذریعے آسانی سے اوور رائٹ ہو جاتے ہیں، جس سے ملکیت کو ٹریک کرنا مشکل ہو جاتا ہے۔
root میں متغیرات	اسکرپٹ پر عمل درآمد اور بفر ریزرویشن جب پاتھ بلڈنگ کو متحرک کرتے ہیں۔
log_format/متحرک لاگ پاتھ	اسی قسم کی تشخیص بعد میں درخواست میں شروع کی جا سکتی ہے۔
stream میں اسکرپٹ کے تاثرات	اپ اسٹریم فکس ngx_stream_script_run() میں بھی ترمیم کرتا ہے۔ آپ صرف HTTP ماڈیول کا جائزہ نہیں لے سکتے۔

اہم رجعت کا تعلق: اس خطرے سے متعلق کوڈ کا تعلق سابقہ تبدیلیوں سے ہے جنہوں نے CVE-2026-42533 کو طے کیا تھا۔ Debian 13 کے لیے آفیشل DSA واضح طور پر کہتا ہے کہ متاثرہ کوڈ کو trixie پیکیج میں پہلے کے سیکیورٹی بیک پورٹ کے ذریعے متعارف کرایا گیا تھا۔ لہذا، “جولائی map خطرے کا پیچ انسٹال کر دیا گیا ہے” کا مطلب یہ نہیں ہے کہ اکتوبر کے CVE-2026-93479 کا احاطہ کیا گیا ہے۔ مکمل سیکورٹی فکس چین کو چیک کیا جانا چاہئے. S6S14S17

یہاں ممکنہ RCE خطرہ میموری کے تحفظ کے ماحول سے متعلق ہے، اور یہ دعویٰ نہیں کیا جانا چاہیے کہ map regex ہی گمنام حملہ آوروں کے ذریعے فائدہ اٹھایا جا سکے گا۔ S11

2.4 CVE-2026-97205: AIO نامکمل آپریشن کاؤنٹ ریپراؤنڈ کا سبب بنتا ہے استعمال کے بعد مفت

یہ خطرہ صرف “SSI آن کریں اور آپ کو UAF ملے گا” نہیں ہے۔ کلید مرکزی درخواست کے ذریعہ منعقد غیر مطابقت پذیر آپریشن حوالہ شمار میں ہے۔

NGINX غیر مطابقت پذیر پروسیسنگ کو ٹریک کرنے کے لیے r->main->blocked استعمال کریں جو ابھی تک مکمل نہیں ہوئی ہے، پرانے نفاذ میں یہ 8 بٹ کاؤنٹ تھا۔ کچھ راستوں نے گنتی میں اضافہ کرنے سے پہلے اوپری حد کی جانچ نہیں کی۔ جب ایک ہی اہم درخواست میں 256 بقایا کارروائیاں جمع ہوتی ہیں، تو گنتی 255 سے 0 تک سمیٹ سکتی ہے۔ بعد کے عمل غلطی سے یہ مان لیں گے کہ درخواست کو جاری ہونے سے روکنے والا کوئی غیر مطابقت پذیر آپریشن نہیں ہے، اس طرح درخواست کے میموری پول کو جاری کرے گا جس کا ابھی بھی ٹاسک کے ذریعہ حوالہ دیا گیا ہے۔ S7

ناکامی کے عمل میں تقسیم کیا جا سکتا ہے:

1. متعلقہ غیر مطابقت پذیر I/O/تھریڈ پاتھ کو فعال کرنے کے ساتھ، SSI صفحہ include virtual کے ذریعے متعدد ذیلی درخواستیں یا پڑھنے کی کارروائیوں کو متعارف کراتا ہے۔
2. ایک خاص اہم درخواست کی بقایا کارروائیاں شمار کے فیلڈ کے ذریعہ ظاہر کی گئی اوپری حد تک جمع ہوتی ہیں۔
3. 8 بٹ کی گنتی چاروں طرف لپیٹ جاتی ہے، جس کا غلط اظہار “کوئی زیر التواء آپریشن نہیں” کے طور پر کیا جاتا ہے۔
4. درخواست میموری پول جاری کیا جاتا ہے، جبکہ فائل پڑھتا ہے، کیش انتظار کرتا ہے، یا تھریڈ ٹاسک کے کال بیکس اب بھی اس کے حوالہ جات کو برقرار رکھتے ہیں۔
5. بعد میں غیر مطابقت پذیر تکمیل کال بیکس جاری کردہ میموری تک رسائی حاصل کرتی ہیں، جس کے نتیجے میں UAF، Worker کریش ہو جاتے ہیں یا میموری کی ممکنہ خرابی ہوتی ہے۔

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

قابل اطلاق فیصلہ: اس بات کا جائزہ لیا جانا چاہیے کہ آیا SSI، AIO، ورچوئل انکلوژن، ذیلی درخواستیں اور متعلقہ غیر مطابقت پذیر کارروائیاں ایک ہی درخواست کے سلسلے میں مل کر ہو سکتی ہیں۔ یہ عام طور پر پہلے سے طے شدہ سادہ جامد پراکسی کنفیگریشن نہیں ہوتے ہیں۔ aio off; یا ssi off; مخصوص محرک عناصر کو ہٹا سکتے ہیں، لیکن پہلے کاروباری فنکشن کے انحصار کی تصدیق ہونی چاہیے۔ S4S7S25

2.5 CVE-2026-95101: HTTP/3 نامعلوم فریم DATA درخواست کے باڈی کی حیثیت سے الجھا ہوا ہے

HTTP/3 فریم پارسر کو DATA فریمز (جسے HTTP درخواست باڈی پروسیسنگ میں منتقل کرنے کی ضرورت ہے) اور نامعلوم فریموں کے درمیان فرق کرنا چاہیے جنہیں چھوڑ دیا جانا چاہیے۔ نیٹ ورک بفرز میں ٹکڑے ٹکڑے کرتے وقت نامعلوم فریموں کی لمبائی کو بھی درست طریقے سے محفوظ کیا جانا چاہیے۔

ngx_http_v3_parse_data() کے پرانے نفاذ نے st->length فیلڈ کا استعمال نامعلوم فریموں کو چھوڑتے وقت “چھوڑنے والے بائٹس کی بقیہ تعداد” کو بچانے کے لیے کیا، جب کہ درخواست کے باڈی فلٹر نے اسی فیلڈ کو “بقیہ DATA پے لوڈ کی لمبائی” سے تعبیر کیا۔ اگر نامعلوم فریم ایک سے زیادہ پارس کالوں پر محیط ہوتا ہے، تو پارس کرنے کے بعد بائٹس کے اگلے بیچ کو درخواست کے باڈی کے حصے کے طور پر غلطی سے سمجھا جا سکتا ہے۔ S8

دو قسم کے خطرات پیدا ہوتے ہیں:

• باڈی انجیکشن کی درخواست کریں: کلائنٹ کے ذریعہ جمع کردہ غیر 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; واضح طور پر نہیں لکھا گیا ہے۔ S8S18

اس خطرے کا براہ راست نتیجہ پسدید کی درخواست کی سالمیت اور سیکیورٹی باؤنڈری کی تبدیلی سے تعلق رکھتا ہے، جو RCE کے براہ راست NGINX کور میں مکمل ہونے کے مساوی اظہار نہیں ہے۔ حتمی کاروباری اثر اس بات پر منحصر ہے کہ ان بائٹس کو کس طرح پارس کیا جاتا ہے اور اپ اسٹریم پر بھروسہ کیا جاتا ہے۔ S24

2.6 CVE-2026-97629: TLS ٹکٹ کی گردش تیسری کلیدی سلاٹ سے محروم ہے

متاثرہ کنفیگریشنز میں، NGINX مشترکہ میموری کیش کے ذریعے TLS سیشن ٹکٹ کیز کو خود بخود بنا اور گھما سکتا ہے، جس سے متعدد Worker ٹکٹوں کے ایک ہی بیچ پر کارروائی کر سکتے ہیں۔

متعلقہ مطابقت پذیری منطق ہر Worker کے لیے 3 کلیدی سلاٹس مختص کرتی ہے، اور ڈکرپشن کال بیک ان سلاٹس کو بھی عبور کرے گا۔ لیکن پرانا نفاذ ہر بار مشترکہ میموری سے صرف 2 کلیدی سلاٹس کو کاپی کرتا ہے، جس کے نتیجے میں کلیدی نام، HMAC کلید اور تیسرے سلاٹ کا AES ہوتا ہے۔ کلید غیر شروع شدہ رہ سکتی ہے۔ اگر ٹکٹ کا کلیدی شناخت کنندہ اس حیثیت سے مماثل ہے تو، غیر شروع شدہ کلیدی مواد کو دستخط کی تصدیق اور ڈکرپشن کے لیے استعمال کیا جا سکتا ہے، اس طرح TLS سیشن کو جعلی بنانے کا راستہ بنتا ہے۔ S9

اعلی خطرے کی تعیناتی کے مجموعے عام طور پر ہیں:

# 仅为排查触发条件所示：共享缓存本身不是恶意配置
ssl_session_cache shared:SSL:10m;
# 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制

اس خطرے کا سب سے سنگین کاروباری نتیجہ یہ ہے کہ ایسی سروسز پر جو ssl_verify_client on; اور دیگر طریقوں سے کلائنٹ سرٹیفکیٹ کی تصدیق (mTLS) استعمال کرتی ہیں، جعلی ریکوری سیشنز کلائنٹ سرٹیفکیٹ کی تصدیق کو نظرانداز کر سکتے ہیں۔ حملے کی کامیابی بھی بے قابو حالات سے مشروط ہے۔ ایک ایسی سائٹ جو صرف ایک عام سرور سائیڈ HTTPS سرٹیفکیٹ استعمال کرتی ہے اور کسی بھی کلائنٹ سرٹیفکیٹ کی توثیق کو غلط نہیں بنایا جانا چاہئے کیونکہ “حملہ آور پوری ویب سائٹ لاگ ان کو نظرانداز کر سکتا ہے۔” S9S12

یہ ایک TLS سیشن کی توثیق کی حیثیت کا مسئلہ ہے اور اس کا اس سے کوئی تعلق نہیں ہے کہ آیا سرور کی TLS نجی کلید کریک ہے یا عوامی CA root سرٹیفکیٹ متاثر ہے۔ S24

2.7 DoS، RCE، توثیق بائی پاس اور معروف کارناموں کو کیسے سمجھیں

• DoS: میموری کی خرابی Worker کریش یا بڑے پیمانے پر دوبارہ شروع ہونے کا سبب بنتی ہے۔ چاہے یہ مجموعی طور پر عدم دستیابی کا سبب بنتا ہے ٹریفک کے دباؤ، عمل کو دوبارہ شروع کرنے کی صلاحیت، کنکشن کی بحالی کا وقت اور اعلی دستیابی کے فن تعمیر سے متعلق ہے۔
• ممکنہ RCE: کچھ اعلانات اس بات کی نشاندہی کرتے ہیں کہ ASLR کے بند یا نظرانداز ہونے پر کوڈ پر عمل درآمد کا امکان ہے۔ اس کا مطلب یہ نہیں ہے کہ ایک عوامی حملے کی زنجیر کا انکشاف کیا گیا ہے جو مستحکم اور عالمی طور پر کمانڈز کو انجام دے سکتا ہے۔ S4
• انجیکشن/توثیق بائی پاس کی درخواست کریں: یہ براہ راست محفوظ کاروباری حیثیت کو تبدیل کر سکتا ہے یا مواد کی درخواست کر سکتا ہے، اور اسے صرف اس وجہ سے نظر انداز نہیں کیا جا سکتا کہ یہ براہ راست شیل حاصل نہیں کرتا ہے۔
• نے حملے کی کوششیں دریافت کی ہیں: مئی 2026 میں CVE-2026-42945 میں جنگلی استحصال کی سرگرمیوں کی رپورٹیں ہیں۔ اس تاریخی حقیقت کا براہ راست مطلب یہ نہیں نکالنا چاہیے کہ اکتوبر کے تمام پانچ CVE کا بڑے پیمانے پر کامیابی سے استحصال کیا گیا ہے۔ S23

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 سے زیادہ ہے، تب بھی یہ مین لائن برانچ کی پیچ بیس لائن سے کم ہے۔ S1S2

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

3.3 Ubuntu: ڈسٹری بیوشن بیک پورٹ (USN-8955-1)

کیننیکل USN-8955-1 26 اکتوبر 2026 کو چار Ubuntu کے لیے سیکیورٹی اپ ڈیٹ فراہم کرتا ہے: S13

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

3.4 Debian: ورژن کے درمیان فرق کو الگ سے چیک کیا جانا چاہیے

Debian ایڈوائزری DSA-6575-1 (2026-10-21) ان پانچ CVEs کا احاطہ کرتا ہے اور Debian 13 / trixie کے لیے طے شدہ nginx پیکیج کی شناخت کرتا ہے:

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 ٹریکنگ ریکارڈز پر مبنی ہے۔ S14S15S16

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
njs / ngx_http_js_module	2026-10-14 njs 1.0.2 جاری کرتا ہے اور CVE-2026-101019 اور CVE-2026-101025 کو ٹھیک کرتا ہے۔ اگر آپ njs استعمال کر رہے ہیں، تو آپ کو NGINX کے ساتھ ماڈیول کی مطابقت کو بھی چیک کرنا چاہیے۔ S20
F5 NGINX انگریس کنٹرولر / گیٹ وے فیبرک	NGINX کور ایک متعلقہ لیکن آزاد سافٹ ویئر ڈسٹری بیوشن چین ہے۔ متعلقہ کمزوریوں کو ان کے متعلقہ کنٹرولرز، امیجز اور ریلیز نوٹ سے ٹھیک کریں۔ آپ Pod میں صرف NGINX بائنری کو تبدیل نہیں کر سکتے۔
Kubernetes کمیونٹی kubernetes/ingress-nginx	اس منصوبے کو مارچ 2026 میں ختم کر دیا گیا ہے اور اس کے بعد سیکیورٹی کی نئی دیکھ بھال فراہم نہیں کی جائے گی۔ آپ کو F5 NGINX انگریس کنٹرولر کے لیے اس کے ریلیز نمبر کو غلط سمجھنے کے بجائے برقرار رکھے ہوئے کنٹرولر یا Gateway API پر منتقل کرنے کا منصوبہ بنانا چاہیے۔ S21

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 ورژن اور تالیف کی معلومات چیک کریں۔

# 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 اجازتوں اور نجی فائل کی اجازتوں کے ساتھ محفوظ کریں، اور اصل فائلوں کو عوامی کام کے احکامات پر پوسٹ نہ کریں:

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 (سرکاری تقسیم کا ذخیرہ):

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 کے لیے، اگر اپ گریڈ شدہ پیکیج کو سیکیورٹی ٹریکنگ سسٹم کے ذریعے اب بھی کمزور سمجھا جاتا ہے، اضافی وینڈر کی مرمت، تنہائی یا نقل مکانی کے اقدامات کی ضرورت ہے۔ S13S14S15

nginx.org آفیشل پیکیج:

# 先确认仓库来自 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 کو تبدیل کریں

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

اگر آپ NGINX کا نظم systemd ساکٹ، کنٹینر انٹری اسکرپٹ، یا ایک سے زیادہ تنصیبات کے ذریعے کرتے ہیں، تو آپ کو براہ راست یہ ماننے کے بجائے کہ systemctl restart nginx تمام مثالوں کا احاطہ کرتا ہے اصل لانچ ہدف اور عمل کا راستہ چیک کرنا چاہیے۔

4.6 حقیقی بیرونی داخلی دروازے سے کاروباری رجعت کو قبول کریں اور کریں۔

کم از کم انجام دینے کی سفارش کی جاتی ہے:

• کیا عام HTTPS، دوبارہ لکھے گئے راستے، جامد وسائل، اور alias نقشہ سازی کے صفحات درست ہیں؟
• کیا ریگولر map ڈسٹری بیوشن، متغیر root پاتھ، رسائی لاگ پاتھ، SNI/سرٹیفکیٹ روٹنگ، اور Stream پراکسی درست ہیں۔
• کیا نارمل اپ لوڈز، chunked اپ لوڈز، API درخواستیں اور HTTP/3 (جب فعال ہو) کے لیے اپ اسٹریم والیوم کی حدیں اب بھی توقع کے مطابق ہیں۔
• mTLS: سرٹیفکیٹ کی جائز درخواستیں کامیاب ہونی چاہئیں۔ گمشدہ، میعاد ختم، یا غیر مجاز سرٹیفکیٹس کو اب بھی مسترد کر دیا جانا چاہیے، اور TLS دوبارہ شروع/دوبارہ کنکشن کو غلطی سے اجازتوں کو تبدیل نہیں کرنا چاہیے۔
• آیا SSI صفحہ اور غیر مطابقت پذیر فائل تک رسائی عام ہے؛ ایرر لاگ میموری حوالہ جات یا بار بار Worker کریش کے لیے کوئی غیر معمولی درخواست نہیں دکھاتا ہے۔
• ٹریفک سوئچ کے بعد، پرانے ورژن کا عمل اور پرانی تصویری نقل سے باہر نکل جانا چاہیے تھا۔

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

5. تخفیف کے اقدامات جب فوری اپ گریڈ ممکن نہ ہو۔

یہ سیکشن خطرے میں کمی کا اختیار ہے، پیچ کی تبدیلی نہیں۔ تمام عارضی کنفیگریشن تبدیلیوں کا بیک اپ لیا جانا چاہیے، nginx -t کو عمل میں لایا جانا چاہیے، بیچوں میں جاری کیا جانا چاہیے، اور اگر ضروری ہو تو فوری طور پر واپس کر دیا جائے۔ S3S4

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

5.3 map/Regex: کیپچر متغیر حالت مکسنگ کو کم کریں

نامزد کیپچرز کو ترجیح دینے اور ان کے پھیلاؤ کے دائرہ کار کو محدود کرنے کی سفارش کی جاتی ہے، بجائے اس کے کہ $1 جیسے گمنام کیپچرز کو وقت کے ساتھ ساتھ مختلف ریجیکس تشخیصی راستوں پر دوبارہ استعمال کیا جائے۔ مثال کے طور پر:

# 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
    default /srv/www/default;
    ~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}

یہ ٹکڑا صرف متغیر ملکیت کے آڈٹ سے آسان ڈھانچے کو ظاہر کرتا ہے۔ اس کا مطلب یہ نہیں ہے کہ یہ آزادانہ طور پر تمام CVE-2026-93479 ٹرگر پاتھ کو ختم کرنے کے لیے ثابت ہوا ہے۔ خاص طور پر، اس بات کا جائزہ لیں کہ آیا دیگر root یا log_format کے ذریعے کیپچر متغیرات کا حوالہ وقت سے پہلے دیا جاتا ہے، اور آیا volatile، متحرک راستے، اور ایک دوسرے پر منحصر تشخیصی سلسلہ موجود ہیں۔ F5/CERT تجویز کرتا ہے کہ نام کیپچر استعمال کریں اور استعمال کے دائرہ کار کو متعلقہ ریگولر میچنگ کنفیگریشن تک محدود رکھیں بطور قلیل مدتی ریلیف۔ S3S6

5.4 AIO + SSI: غیر ضروری فنکشن کے امتزاج کو بند کریں

ایسے سرورز/راستوں کے لیے جنہیں SSI یا غیر مطابقت پذیر فائل I/O کی ضرورت نہیں ہے، استعمال کریں:

# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;

خطرے کو متحرک کرنے والے حالات کے نقطہ نظر سے، دونوں میں سے ایک کو بند کرنا عام طور پر بیان کردہ مخصوص سلسلہ کو ہٹانے کے لیے کافی ہوتا ہے۔ ایک ہی وقت میں بند ہونا صرف ان منظرناموں پر لاگو ہوتا ہے جہاں کاروبار اس قابلیت پر انحصار نہیں کرتا ہے۔ include virtual، ذیلی درخواستیں، کیشے، اور تھریڈ پول کے رویے کو چیک کریں۔ جب ریورس پراکسی لوڈ زیادہ ہوتا ہے، AIO کو بند کرنے سے تاخیر اور I/O کارکردگی تبدیل ہو سکتی ہے۔ S7

5.5 HTTP/3 باڈی انجیکشن کی درخواست کریں: اگر ضروری ہو تو عارضی طور پر داخلہ بند کریں

کو غیر فعال کریں۔ quic سننے والا شامل ہے HTTP/3 ، منسوخ کریں۔ Alt-Svc جوابی ہیڈر جو اعلان کرتا ہے۔ HTTP/3 ، اور چیک کریں کہ آیا کنارے کی پرت/لوڈ بیلنسر اب بھی بھیجتا ہے۔ QUIC براہ راست غیر مرمت شدہ سے درخواست کرتا ہے۔ 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 پراکسی پاتھ کو متاثر کرتی ہے۔ S8S18

5.6 TLS سیشن ٹکٹ: ترجیحی تحفظ mTLS توثیق کی حد

اگر اپ گریڈ کرنا ممکن نہیں ہے اور مثال مشترکہ سیشن کیشے + خودکار ٹکٹ کلید کی گردش پر انحصار کرتی ہے تو اندازہ کریں:

# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;

یہ TLS سیشن ٹکٹ کے طریقہ کار کو بند کر سکتا ہے، اس طرح اس خطرے میں بیان کردہ ٹکٹ کی جعلسازی کے راستے کو ہٹا سکتا ہے۔ تاہم، یہ سیشن کی بحالی کی کارکردگی کو متاثر کر سکتا ہے۔ آپ صرف mTLS کلائنٹ سرٹیفکیٹ کی توثیق کو “خطرے سے بچنے” کے لیے بند نہیں کر سکتے، کیونکہ اس سے تصدیق کی اصل حد براہ راست حذف ہو جائے گی۔ S9S12

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

5.7 آپریٹنگ سسٹم اور سرحدی تحفظ کا کردار

# Linux：常见值 2 表示进程地址空间随机化处于完整启用状态
sysctl kernel.randomize_va_space

ASLR، غیر root ورکرز، صرف پڑھنے کے لیے کنٹینر فائل سسٹم، فائل کی کم سے کم اجازتیں اور نیٹ ورک آئسولیشن ممکنہ RCE کے اثرات کو کم کر سکتا ہے۔ ASLR ہیپ اوور فلو یا UAF کو ٹھیک نہیں کرتا اور اس بات کی گارنٹی نہیں دے سکتا کہ کارکن کریش نہیں ہوں گے۔ WAF، شرح کی حد اور درخواست کے باڈی سائز کی حدیں TLS ٹکٹ کلید کی مطابقت پذیری کو ٹھیک نہیں کرتی ہیں۔ S4

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 اصلاحات کی پیروی کرتا ہے۔ ٹکڑوں میں پیچ کا جائزہ لینے کے لیے نمائندہ تبدیلیوں کی وضاحت ہوتی ہے۔ وہ مکمل نہیں ہیں، آزادانہ طور پر مرتب کی جانے والی اصلاحات۔ اپنی مرضی کے مطابق تعمیرات کے لیے، مکمل کمٹ، ارد گرد کے کوڈ اور ٹیسٹس کا جائزہ لیں، اور مکمل تعاون یافتہ ریلیز کو ترجیح دیں۔ S5S6S7S8S9

6.1 CVE-2026-15176: URI کو alias پاتھ میپنگ کو مسترد کرنے کی شرائط کو شامل کرنے کے لیے دوبارہ لکھا گیا ہے۔

src/http/ngx_http_core_module.c میں اپ اسٹریم کمٹ میں ترمیم شدہ ngx_http_map_uri_to_path():

- if (alias && !r->valid_location) {
+ if (alias && (!r->valid_location || r->uri_changed)) {

جائزہ فوکس: URI تبدیل ہونے پر فائل سسٹم کے راستے کا حساب لگانا جاری نہیں رکھا جا سکتا لیکن alias کے متعلقہ مقام کے الفاظ اب قابل بھروسہ نہیں ہیں۔ یہ ریاست سے پہلے کی رکاوٹ میں اضافہ ہے۔ یہ کوئی آسان جانچ نہیں ہے کہ آیا درخواست URI غیر قانونی حروف پر مشتمل ہے۔ S5

6.2 CVE-2026-93479: آؤٹ پٹ ڈیٹا کی لمبائی اور محفوظ لمبائی کے درمیان درست طریقے سے فرق کریں

اپ اسٹریم کمٹ src/http/ngx_http_script.c اور src/stream/ngx_stream_script.c کو ایک ہی وقت میں اپ ڈیٹ کرتا ہے۔ بنیادی نیت کا خلاصہ یوں کیا جا سکتا ہے:

- 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

آڈیٹنگ اور بیک پورٹ کرتے وقت، HTTP/Stream کے متعلقہ ایویلیویٹر کا بھی احاطہ کیا جانا چاہیے۔ صرف map کی کنفیگریشن نحوی فائل کو چیک کرنے سے یہ ثابت نہیں ہو سکتا کہ خرابی ٹھیک ہو گئی ہے۔

6.3 CVE-2026-97205: 8 بٹ غیر مطابقت پذیر آپریشن کی گنتی کے لیے حفاظتی حد مقرر کریں

src/http/ngx_http_request.h پر Upstream شامل کیا گیا:

#define NGX_HTTP_MAX_BLOCKED 250

اور اسی طرح کے اندراجات کو غیر مطابقت پذیر فائل ریڈنگ، کیشے ویٹنگ، آؤٹ پٹ فلٹرنگ اور تھریڈ آپریشن میں شامل کریں:

if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
    /* 使用同步路径，或者拒绝新的异步操作 */
}

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

6.4 CVE-2026-95101: نامعلوم فریموں کے لیے الگ سے skip کی حیثیت برقرار رکھیں

اپ اسٹریم HTTP/3 پارسر اسٹیٹس اسٹرکچر میں skip فیلڈ کو شامل کرتا ہے اور اسٹیٹس سیپریشن انجام دیتا ہے:

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

6.5 CVE-2026-97629: مکمل TLS کلیدی سلاٹ سرنی کو ہم آہنگ کریں

اپ اسٹریم تبدیلیاں src/event/ngx_event_openssl.c پر واقع ہیں:

  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

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 مثالیں جو طویل عرصے سے اپ ڈیٹ نہیں ہوئی ہیں نہ صرف اکتوبر کے نئے شمارے سے متاثر ہوئی ہیں۔ مستقبل قریب میں نمائندہ مرمت نوڈس درج ذیل ہیں: S1S2

سی وی ای	پہلے فکس ریلیز	اہم خطرات اور شرائط جن کے لیے آڈٹ کی ضرورت ہوتی ہے۔
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

CVE-2026-42945 پر کیوں خصوصی توجہ دیں۔

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

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

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
• F5 NGINX Plus / NGINX انگریس کنٹرولر: پلس، کنٹرولر اور گیٹ وے فیبرک میں ہر ایک میں اضافی سیکیورٹی بلیٹنز، مختلف پیکیجنگ ورژن اور منفرد پالیسی کے خطرات ہوسکتے ہیں۔ ایک پرت کو اپ گریڈ کرنے کا مطلب خود بخود دوسری پرت کو اپ ڈیٹ کرنا نہیں ہے۔ S19
• Kubernetes کمیونٹی ingress-nginx: Kubernetes حکام پہلے ہی اعلان کر چکے ہیں کہ کنٹرولر نے مارچ 2026 میں دیکھ بھال بند کر دی ہے، اور اس کے گودام کو F5 کنٹرولر کے ساتھ الجھایا نہیں جا سکتا۔ متاثرہ کاروباروں کو نئے سیکیورٹی ورژن کا انتظار کرنے کی بجائے ہموار منتقلی کی منصوبہ بندی کرنی چاہیے اور Ingress تشریحات اور Gateway API سیمنٹک اختلافات کی تصدیق کرنی چاہیے۔ S21

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 آفیشل سیکیورٹی بلیٹن

• https://nginx.org/en/security_advisories.html

اپ اسٹریم سے متاثرہ ورژنز، فکس برانچز، اور پانچ اکتوبر CVEs کے آفیشل سیوریٹی لیول پر مشتمل ہے، اور 2026 تک تاریخی کمزوریوں کا بھی احاطہ کرتا ہے۔

S2 — NGINX آفیشل ورژن ریلیز ریکارڈ

• https://nginx.org/news.html
• https://nginx.org/en/CHANGES-1.30

تصدیق کریں۔ 1.30.6 / 1.31.7 کی 2026-10-14 , 1.31.8 کی 2026-10-21 ، اور مئی سے ستمبر تک اہم سیکیورٹی ریلیز سنگ میل۔

S3 - سنگاپور کی سائبر سیکیورٹی ایجنسی: F5 NGINX تین اہم خطرات

• https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-150/

CVSS v4.0 9.2 اسکورز، ترتیب کی مطلوبہ شرائط، اور CVE-2026-15176، CVE-2026-93479، اور CVE-2026-97205 کے لیے عبوری تخفیف کی سفارشات کی تفصیل۔

S4 - NHS انگلینڈ: F5 NGINX ہائی رسک ایڈوائزری

• https://digital.nhs.uk/cyber-alerts/2026/cc-4872

میموری کی حفاظت کے مسائل کے DoS / ممکنہ RCE اثرات، اور ASLR کو بند یا نظرانداز کرنے جیسی رکاوٹوں کی وضاحت کرتا ہے۔

S5 - سرکاری ذریعہ کمٹ: CVE-2026-15176

• https://github.com/nginx/nginx/commit/f8a23425bd6840c4c36b4264edf576ba3646156f

ngx_http_map_uri_to_path() میں alias اور r->uri_changed کے اسٹیٹس چیک سے مماثل ہے۔

S6 — سرکاری ذریعہ کمٹ: CVE-2026-93479

• https://github.com/nginx/nginx/commit/6aa4b3fdd4fdc156153f2981eb4070690624447c

HTTP/Stream اسکرپٹ کی لمبائی اور محفوظ بفر مختص منطق کے مطابق۔

S7 - سرکاری ذریعہ کمٹ: CVE-2026-97205

• https://github.com/nginx/nginx/commit/6adfc05ece48f92446383ec1f145446848694698

r->main->blocked کاؤنٹ تھریشولڈ NGX_HTTP_MAX_BLOCKED 250 اور غیر مطابقت پذیر پاتھ فال بیک سے مماثل ہے۔

S8 - سرکاری ذریعہ کمٹ: CVE-2026-95101

• https://github.com/nginx/nginx/commit/1c173a2d8767730e678c27446138d7ae5dd6fd64

حیثیت کی علیحدگی HTTP/3 نامعلوم فریم کی باقی لمبائی اور DATA درخواست کے جسم کی لمبائی کے مطابق ہے۔

S9 — سرکاری ذریعہ کمٹ: CVE-2026-97629

• https://github.com/nginx/nginx/commit/1916f26e6ca49296568633d309777e36527e5bb2

سنکرونائزیشن TLS سیشن ٹکٹ کی گردش کے دوران تمام کلیدی سلاٹس سے مماثل ہے۔

S10 — F5: CVE-2026-15176 وینڈر کا اعلان

• https://my.f5.com/manage/s/article/K000162416

محرک عوامل کی فہرست بنائیں جیسے alias, rewrite, $request_filename اور رسائی کے نوشتہ جات۔

S11 — F5: CVE-2026-93479 وینڈر کا اعلان

• https://my.f5.com/manage/s/article/K000162607

نقشہ ریجیکس کیپچر، root پاتھ، اور لاگ متغیر تشخیصی حالات کی فہرست بنائیں۔

S12 — NGINX آفیشل TLS/SSL ماڈیول دستاویزات

• https://nginx.org/en/docs/http/ngx_http_ssl_module.html

تفصیل ssl_session_cache, ssl_session_tickets, ssl_session_ticket_key اور کلائنٹ سرٹیفکیٹ کی توثیق اور دیگر ہدایات۔

S13 — سیکیورٹی ایڈوائزری: Ubuntu USN-8955-1 (2026-10-26)

• https://ubuntu.com/security/notices/USN-8955-1

Ubuntu 22.04 / 24.04 / 26.04 / 26.10. کا مکمل سافٹ ویئر پیکیج فکسڈ ورژن اور تقسیم کا دائرہ فراہم کریں۔

S14 — سیکیورٹی ایڈوائزری: Debian DSA-6575-1 (2026-10-21)

• https://lists.debian.org/debian-security-announce/2026/msg00490.html

Debian 13 / trixie کے لیے سیکیورٹی فکس پیکیج 1.26.3-3+deb13u10 کی تصدیق کریں، اور CVE-2026-93479 کے لیے بیک پورٹ ایسوسی ایشن کو ریکارڈ کریں۔

S15 — خطرے سے باخبر رہنا: Debian Security Tracker: CVE-2026-15176

• https://security-tracker.debian.org/tracker/CVE-2026-15176

Debian 12 / bookworm اور Debian 13 / trixie کی ڈسٹری بیوشن فکس اسٹیٹس کی تصدیق کے لیے استعمال کیا جاتا ہے۔ یہ حیثیت مستقبل کے سیکیورٹی اپ ڈیٹس کے ساتھ بدل سکتی ہے۔

S16 — خطرے سے باخبر رہنا: Debian Security Tracker: CVE-2026-95101

• https://security-tracker.debian.org/tracker/CVE-2026-95101

مختلف Debian برانچوں پر HTTP/3 خطرے کی سیکیورٹی کی حیثیت کی اضافی تصدیق۔

S17 — سیکیورٹی ایڈوائزری: Red Hat: CVE-2026-93479

• https://access.redhat.com/security/cve/cve-2026-93479

اکتوبر کے رجعت کے خطرے اور جولائی CVE-2026-42533 کے لیے طے شدہ باہمی تعلق کی ضمنی تفہیم۔

S18 — NGINX آفیشل ریورس پراکسی ماڈیول دستاویز

• https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• https://nginx.org/en/docs/http/ngx_http_core_module.html

کنفیگریشنز کی سیمنٹکس اور ڈیفالٹ ویلیوز جیسے proxy_request_buffering، client_max_body_size، alias، aio، وغیرہ سے استفسار کریں۔

S19 — NGINX Plus آفیشل ریلیز نوٹس

• https://docs.nginx.com/nginx/releases/

پلس CR/LTS برانچز، ورژن، پیچ اور اپ گریڈ مطابقت کی یاد دہانیوں کی فہرست بنائیں۔

S20 — NGINX JavaScript / njs آفیشل سیکیورٹی بلیٹن

• https://nginx.org/en/docs/njs/security.html
• https://nginx.org/en/docs/njs/changes.html

اکتوبر 2026 njs 1.0.2 اور متعلقہ XML کی توثیق، میموری کی تھکن کے مسائل پر مشتمل ہے۔

S21 — Kubernetes: کمیونٹی ingress-nginx سرکاری ریٹائرمنٹ ہدایات

• https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
• https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/

نوٹ کریں کہ پروجیکٹ نے مارچ 2026 میں نئی ریلیزز اور سیکیورٹی فکسز کو روک دیا تھا، اور یہ تجویز کیا جاتا ہے کہ برقرار رکھے ہوئے کنٹرولر یا Gateway API کو منتقل کیا جائے۔

S22 — NGINX آفیشل سروس کنٹرول اور آن لائن بائنری اپ گریڈ ہدایات

• https://nginx.org/en/docs/control.html

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

S23 - حکومتی سیکورٹی نوٹس: مئی 2026 NGINX دوبارہ لکھنے کا خطرہ

• https://its.ny.gov/2026-051
• https://www.govcert.gov.hk/en/alerts_detail.php?id=1881

CVE-2026-42945 کے لیے تاریخی خطرے کا پس منظر اور سیکیورٹی اپ ڈیٹ کی تجاویز فراہم کریں۔ جنگل میں ہونے والے استحصال سے متعلق فیصلے اس وقت ایجنسی کے اعلان اور واقعے کے مزید شواہد پر مبنی ہونے چاہئیں۔

S24 — F5: CVE-2026-95101 اور CVE-2026-97629 وینڈر کے اعلانات

• https://my.f5.com/manage/s/article/K000162613
• https://my.f5.com/manage/s/article/K000162606

بالترتیب HTTP/3 درخواست باڈی انجیکشن اور خودکار TLS ٹکٹ کلید گردش کے خطرات کا احاطہ کرتا ہے۔

S25 — F5: CVE-2026-97205 وینڈر کا اعلان

• https://my.f5.com/manage/s/article/K000162608

تفصیل SSI/AIO محرک حالات اور ممکنہ میموری کی خرابی کے خطرات۔

NGINX سیکیورٹی اپ ڈیٹ: کنفیگریشن چیک، اپ گریڈ اور تصدیق