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 + regex + পরিবর্তনশীল মূল্যায়ন, 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 রেজেক্স ক্যাপচার এবং 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 একা সিভিই স্কোরের পরিবর্তে স্থাপনার এক্সপোজারকে অগ্রাধিকার দিন

স্থাপনার ফর্ম	মূল তদন্ত পয়েন্ট	নিষ্পত্তি অগ্রাধিকার সুপারিশ
কাস্টমাইজড 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 ব্যবহার করুন	প্রকল্পটি নিরাপত্তা রক্ষণাবেক্ষণ বন্ধ করে দেয়, এবং ঝুঁকিগুলি এই পাঁচটি CVE-এর মধ্যে সীমাবদ্ধ নয়	একটি পৃথক নিয়ামক মাইগ্রেশন পরিকল্পনা করুন

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 ম্যাপিং দ্বারা ব্যবহৃত অনুমানগুলি আর ধরে নাও থাকতে পারে।

ngx_http_map_uri_to_path()-এ alias স্থিতি পরীক্ষা করার সময় প্রভাবিত প্রক্রিয়াকরণ পথটি পর্যাপ্তভাবে পরীক্ষা করেনি যে অনুরোধটি পুনরায় লেখা হয়েছে কিনা। যখন কনফিগারেশনটি পুনরায় লেখার পরে $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

অংশগ্রহণমূলক উপাদান	কেন এটা মনোযোগ দিতে মূল্য
map এ regex	ক্যাপচার পরিবর্তনশীল মূল্যায়নের স্বাধীন জীবনচক্র এবং ক্যাশিং আচরণ থাকতে পারে
বেনামী ক্যাপচার যেমন $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 রেজেক্স একা বেনামী আক্রমণকারীদের দ্বারা শোষণ করতে সক্ষম হবে। 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

এই দুর্বলতার সরাসরি পরিণতি ব্যাকএন্ড অনুরোধের অখণ্ডতা এবং নিরাপত্তা সীমানা পরিবর্তনের অন্তর্গত, যা সরাসরি NGINX কোরে সম্পূর্ণ হওয়া RCE এর সমতুল্য অভিব্যক্তি নয়। চূড়ান্ত ব্যবসায়িক প্রভাব নির্ভর করে কিভাবে এই বাইটগুলিকে পার্স করা হয় এবং আপস্ট্রিমে বিশ্বাস করা হয়। 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-এ বন্য শোষণ কার্যক্রমের রিপোর্ট রয়েছে; এই ঐতিহাসিক সত্যকে সরাসরি অনুমান করা উচিত নয় যে অক্টোবরের পাঁচটি সিভিই সফলভাবে বৃহৎ পরিসরে কাজে লাগানো হয়েছে। 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 পাঁচটি CVE-এর আপস্ট্রিম প্রভাবের সুযোগ

নিম্নলিখিত ব্যাপ্তিগুলি 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 দ্বারা দেখানো আপস্ট্রিম অংশ থেকে এটি ঠিক করা হবে কিনা সে সম্পর্কে সিদ্ধান্তে আঁকবেন না। যেমন 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) এই পাঁচটি CVE-কে কভার করে এবং 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 কোর একটি সম্পর্কিত কিন্তু স্বাধীন সফ্টওয়্যার বিতরণ চেইন। তাদের নিজ নিজ কন্ট্রোলার, ছবি এবং রিলিজ নোট দিয়ে প্রাসঙ্গিক দুর্বলতা ঠিক করুন। আপনি পডে শুধুমাত্র একটি 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/আলমা/রকি/SUSE/অন্যান্য বিতরণ	নির্দিষ্ট ডিস্ট্রিবিউশন সিকিউরিটি বুলেটিন এবং প্যাকেজ ভার্সন অনুযায়ী আপগ্রেড করুন	সংশ্লিষ্ট বিক্রেতা CSAF/ঘোষণা, Ubuntu/Debian সংস্করণ প্রয়োগ করা যাবে না
অফিসিয়াল বা কাস্টম কন্টেইনার ইমেজ	যাচাইকৃত মেরামতের চিত্রটি পুনর্নির্মাণ করুন বা টানুন এবং এটিকে ঘূর্ণায়মান ভিত্তিতে প্রতিস্থাপন করুন	ইমেজ ডাইজেস্ট, বিল্ড SBOM, চলমান পড/কন্টেইনার ইমেজ আইডি
স্ব-সংকলিত NGINX, OpenResty, Tengine বা তৃতীয় পক্ষের মডিউলগুলির সাথে প্যাচ করা সংস্করণ	রক্ষণাবেক্ষণকারীর সম্পূর্ণ নিরাপত্তা সংস্করণ ব্যবহারকে অগ্রাধিকার দিন; প্রয়োজনে লক্ষ্য উৎস গাছের জন্য পর্যালোচনা করা প্যাচ ব্যাকপোর্ট সঞ্চালন করুন	পাঁচটি দুর্বলতা সংশোধন, ABI/মডিউল সামঞ্জস্য, ইউনিট এবং ব্যবসায়িক রিগ্রেশন

OpenResty এবং Tengine বিভিন্ন রিলিজ সিস্টেম; এই টেবিলটি শুধুমাত্র যাচাই পদ্ধতি বর্ণনা করে। এর মানে এই নয় যে এর সমস্ত সংস্করণ একই সময়ে স্ট্যান্ডার্ড NGINX-এর মতো প্রভাবিত হয়, বা আপস্ট্রিম কোড প্যাচ নিঃশর্তভাবে প্রয়োগ করা যায় না।

4. আনুষ্ঠানিক মেরামতের প্রক্রিয়া

4.1 বহিরাগত ট্র্যাফিক প্রাপ্তির প্রকৃত উদাহরণের ইনভেন্টরি

কমপক্ষে প্রতিটি এন্ট্রির জন্য কোলেট করুন:

• ডোমেন নাম, লোড ব্যালেন্সিং/CDN/এজ প্রক্সি লিঙ্ক, অরিজিন সাইট এক্সপোজার পদ্ধতি এবং নেটওয়ার্ক প্রোটোকল ব্যবহার করা হয়েছে।
• NGINX পণ্য (ওপেন সোর্স, প্লাস, ইনগ্রেস, ইত্যাদি), পূর্ণ সংস্করণ, প্যাকেজ রিপোজিটরি সোর্স, ইমেজ ডাইজেস্ট।
• nginx -V বিল্ডিং মডিউল এবং সংকলন পরামিতি প্রদর্শন করে; njs, Lua, OpenResty এবং তৃতীয় পক্ষের গতিশীল মডিউল আছে কিনা।
• বাস্তব চলমান master/worker পিআইডি, সার্ভিস ইউনিট/কন্টেইনার/পড, রেপ্লিকা এবং Worker নোড।
• প্রকৃত কার্যকর http/stream, server, location, include কনফিগারেশন।
• HTTP/3, mTLS, SSI/AIO, ডায়নামিক লগ পাথ, জটিল map এবং রেজেক্স ক্যাপচার সক্ষম করবেন কিনা।

শুধু ডিফল্ট /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

আপনি যদি systemd সকেট, কন্টেইনার এন্ট্রি স্ক্রিপ্ট বা একাধিক ইনস্টলেশনের মাধ্যমে NGINX পরিচালনা করেন, তাহলে systemctl restart nginx সমস্ত দৃষ্টান্ত কভার করে এমন সরাসরি অনুমান করার পরিবর্তে আপনার প্রকৃত লঞ্চ লক্ষ্য এবং প্রক্রিয়া পথ পরীক্ষা করা উচিত।

4.6 বাস্তব বাহ্যিক প্রবেশদ্বার থেকে ব্যবসায়িক রিগ্রেশন গ্রহণ করুন এবং করুন

এটি অন্তত সম্পাদন করার সুপারিশ করা হয়:

• সাধারণ HTTPS, পুনঃলিখিত রুট, স্ট্যাটিক রিসোর্স এবং alias ম্যাপিং পৃষ্ঠাগুলি কি সঠিক।
• নিয়মিত map বিতরণ, পরিবর্তনশীল root পাথ, অ্যাক্সেস লগ পাথ, SNI/শংসাপত্র রাউটিং, এবং Stream প্রক্সি সঠিক।
• স্বাভাবিক আপলোড, খণ্ডিত আপলোড, 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/ক্লাউডফ্লেয়ার খোলাই যথেষ্ট”	WAF সমস্ত NGINX কনফিগারেশন-নির্ভর মেমরি ত্রুটি বা TLS পুনরুদ্ধার ত্রুটিগুলিকে ব্লক করার জন্য প্রমাণিত হতে পারে না
”ইতিমধ্যে ASLR খোলা হয়েছে”	শুধু অসুবিধা প্রশমন সুবিধা গ্রহণ; অনুরোধ ইনজেকশন সহ DoS এখনও সম্ভব
”HTTP/3 সর্বজনীন নেটওয়ার্কের সংস্পর্শে আসে না, তাই আপগ্রেড করার কোন প্রয়োজন নেই”	অন্য চারটি CVE-এর এখনও স্বাধীন মূল্যায়ন প্রয়োজন; এবং লুকানো উত্সের সাথে সরাসরি সংযোগ থাকতে পারে
”জুলাইয়ের map দুর্বলতা সংশোধন করা হয়েছে”	অক্টোবর CVE-2026-93479 পরবর্তী স্ক্রিপ্ট মূল্যায়ন রিগ্রেশন সমস্যা জড়িত
”ক্যাশিং নিষ্ক্রিয় করা সমস্ত সমস্যার সমাধান করে”	শুধুমাত্র কিছু TLS ক্যাশে বা AIO পরিস্থিতি প্রভাবিত করে এবং উপনাম, স্ক্রিপ্ট, HTTP/3 কভার করে না

6. অফিসিয়াল প্যাচ বাস্তবায়ন ধারনা এবং পর্যালোচনা পয়েন্ট

এই বিভাগটি অক্টোবর 2026 আপস্ট্রিম 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 এ যোগ করা হয়েছে:

#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/থ্রেড, HTTP/3, OpenSSL টিকিট সব কভার করা হয়েছে
সংকলিত সামঞ্জস্যপূর্ণ	OpenSSL, PCRE, মডিউল ABI, গতিশীল মডিউল এবং লিঙ্ক নির্ভরতা সামঞ্জস্যপূর্ণ
কার্যকরী রিগ্রেশন	alias পুনর্লিখন, গতিশীল লগ, SSI/AIO, HTTP/3 আপলোড, mTLS সেশন পুনঃসূচনা
রানটাইম	সমস্ত Worker/Pods নতুন যাচাইকৃত বিল্ডগুলি চালায়, কোনও উত্তরাধিকারী ছবি অবশিষ্ট নেই

যে দলগুলি তাদের নিজস্ব রিলিজগুলি বজায় রাখে তাদের জন্য, প্রতিটি CVE-এর জন্য নিরীক্ষণযোগ্য প্যাচ আইডি, প্যাকেজ সংস্করণ, বিল্ড লগ এবং রিগ্রেশন রিপোর্ট রাখার সুপারিশ করা হয়; সাধারণ অপারেশন এবং রক্ষণাবেক্ষণের জন্য, সবচেয়ে নিরাপদ সমাধান হল বিক্রেতার সম্পূর্ণ নিরাপত্তা আপডেটগুলি ইনস্টল করা।

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 আপস্ট্রিম বা gRPC-তে নির্দিষ্ট কনফিগারেশন, বড় অনুরোধ হেডার কন্ডিশন বাফার ওভারফ্লো ট্রিগার করে
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, অক্ষর সেট, এবং 2026 সালে ঘোষিত SMTPও অফিসিয়াল নিরাপত্তা বুলেটিন অনুযায়ী তদন্ত করা উচিত; এই টেবিলটি ইচ্ছাকৃতভাবে সাধারণ ইভেন্টগুলিতে ফোকাস করে যা বর্তমান NGINX পাবলিক-ফেসিং রিভার্স প্রক্সি স্থাপনার সাথে সবচেয়ে প্রাসঙ্গিক এবং মেমরি নিরাপত্তা বা অনুরোধের অখণ্ডতার প্রভাব রয়েছে। 2026-এর সমস্ত CVE নয়। তালিকা। S1

কেন বিশেষ মনোযোগ CVE-2026-42945

সরকারী সংস্থাগুলির নিরাপত্তা বুলেটিন রয়েছে যা মে মাসে এই rewrite দুর্বলতার জন্য বন্য শোষণ কার্যকলাপ এবং পাবলিক এক্সপ্লয়েট কোড তথ্য রেকর্ড করে। অতএব, মে থেকে এখন পর্যন্ত দীর্ঘ সময়ের জন্য প্যাচ করা হয়নি এবং পাবলিক নেটওয়ার্কে জটিল রেগুলার এক্সপ্রেশন রিরাইটের জন্য খোলা আছে, মেরামত সম্পূর্ণ করার পাশাপাশি, অস্বাভাবিক Worker ক্র্যাশ, অ্যাক্সেস লগ এবং সেই সময়ে সন্দেহজনক পরিবর্তনগুলি অতিরিক্তভাবে পর্যালোচনা করা উচিত। S23

“একটি আক্রমণের প্রচেষ্টা ঘটেছে” স্বয়ংক্রিয়ভাবে প্রমাণ করে না যে আক্রমণকারী প্রতিটি টার্গেটে নির্ভরযোগ্যভাবে কমান্ডগুলি কার্যকর করেছে; যখন ঘটনার প্রতিক্রিয়া জড়িত থাকে, তখন আপস সূচক এবং প্রক্রিয়া ক্র্যাশগুলি বিশেষাধিকার বৃদ্ধি বা অধ্যবসায়ের সত্য প্রমাণ থেকে আলাদাভাবে তদন্ত করা উচিত।

পুরানো সংস্করণ এবং বিতরণ ব্যাকপোর্টের জন্য 7.2 প্রতিকার

NGINX বিভিন্ন শাখার নিজস্ব সমর্থন চক্র এবং বিভিন্ন দুর্বলতার পরিচয়ের সময় রয়েছে। পাঁচটি নতুন প্যাচ পর্যালোচনা ছাড়াই সমস্ত প্রাথমিক উত্স গাছগুলিতে রোল আউট করা যাবে না।

দৃশ্য	প্রস্তাবিত কৌশল
রিলিজ সংস্করণ সম্পূর্ণ নিরাপত্তা প্যাচ ঘোষণা করেছে	বিক্রেতা প্যাকেজ ব্যবহার করুন এবং নথি সম্পূর্ণ প্যাকেজ সংস্করণ; বেমানান আপস্ট্রিম বেয়ার বাইনারি দিয়ে প্রতিস্থাপন করা এড়িয়ে চলুন
Debian 12 এবং অন্যান্য প্রভাবিত রিলিজ যেগুলি এখনও এই ব্যাচের সমস্ত CVE দ্বারা কভার করা হয়নি	ঝুঁকিপূর্ণ কাজের আদেশ জমা দিন, বহিরাগত এক্সপোজার সীমিত করুন এবং সরবরাহকারী/ELTS স্থিতি পরীক্ষা করুন; স্থানান্তর করুন বা প্রয়োজনে একটি যাচাইযোগ্য রক্ষণাবেক্ষণ রিলিজ চেইন ব্যবহার করুন
আপস্ট্রিম সমর্থন শেষ হয়েছে যে ঐতিহাসিক শাখা	সমর্থিত সংস্করণে স্থানান্তরকে অগ্রাধিকার দিন; যদি স্বল্প-মেয়াদী ব্যাকপোর্টিং প্রয়োজন হয়, রক্ষণাবেক্ষণকারীরা নির্ভরতা এবং প্যাচ সামঞ্জস্যের মূল্যায়ন করবে এবং সম্পূর্ণ পরীক্ষা লিখবে।
NGINX ফর্কের সাথে আসে (OpenResty, Tengine, কাস্টমাইজড গেটওয়ে)	প্রথমে সংশ্লিষ্ট কোড পাথ অন্তর্ভুক্ত কিনা তা নির্ধারণ করুন এবং তারপর ফর্ক রক্ষণাবেক্ষণকারীর নিরাপত্তা বিবৃতি ব্যবহার করুন। এটি সরাসরি আপস্ট্রিম সংস্করণের সমতুল্য হতে পারে না।
নিরাপত্তা প্যাচ ব্যবসা কার্যকারিতা পরিবর্তনের দিকে পরিচালিত করে	পর্যায়ভুক্ত রোলআউট, সংস্করণগুলির মধ্যে ট্রাফিক স্যুইচিং এবং কনফিগারেশন অভিযোজন গ্রহণ করুন; বিচ্ছিন্নতা ছাড়াই পাবলিক নেটওয়ার্কের আনফিক্সড সংস্করণ পুনরুদ্ধার করা উপযুক্ত নয়।

7.3 njs, প্রবেশ এবং NGINX কোরের জন্য পৃথক প্রতিকার

• njs: NGINX প্রধান প্রোগ্রাম ছাড়াও, আপনাকে NGINX জাভাস্ক্রিপ্ট মডিউলের সংস্করণটিও পরীক্ষা করতে হবে। njs 1.0.2 একটি অক্টোবর 2026 XML পার্সিং মেমরি ক্লান্তি এবং XML যাচাইকরণের অসামঞ্জস্যতা সমস্যার সমাধান করে সত্তা রেফারেন্স বৈশিষ্ট্যগুলির সাথে৷ nginx-saml ব্যবহার করে XML স্বাক্ষর যাচাইকরণের সাথে যুক্ত স্থাপনার জন্য, আপনাকে প্লাগ-ইন পরিস্থিতিগুলির জন্য অফিসিয়াল njs নির্দেশাবলী আরও পড়তে হবে। S20
• F5 NGINX Plus / NGINX ইনগ্রেস কন্ট্রোলার: প্লাস, কন্ট্রোলার এবং গেটওয়ে ফ্যাব্রিকের প্রতিটিতে অতিরিক্ত নিরাপত্তা বুলেটিন, বিভিন্ন প্যাকেজিং সংস্করণ এবং অনন্য নীতিগত দুর্বলতা থাকতে পারে। একটি স্তর আপগ্রেড করার অর্থ স্বয়ংক্রিয়ভাবে অন্য স্তর আপডেট করা নয়। S19
• Kubernetes কমিউনিটি ingress-nginx: Kubernetes কর্মকর্তারা ইতিমধ্যে ঘোষণা করেছেন যে কন্ট্রোলার মার্চ 2026 এ রক্ষণাবেক্ষণ বন্ধ করে দিয়েছে, এবং এর গুদাম F5 কন্ট্রোলারের সাথে বিভ্রান্ত করা যাবে না। প্রভাবিত ব্যবসায়গুলিকে মসৃণ স্থানান্তরের পরিকল্পনা করা উচিত এবং একটি নতুন সুরক্ষা সংস্করণের জন্য অপেক্ষা না করে ইনগ্রেস টীকা এবং Gateway API শব্দার্থগত পার্থক্যগুলি যাচাই করা উচিত৷ S21

8. গ্রহণযোগ্যতার মানদণ্ড এবং ফলো-আপ পরিদর্শন

এটি সুপারিশ করা হয় যে নিম্নলিখিত তালিকাটি কাজের আদেশ পরিবর্তনের জন্য গ্রহণযোগ্যতার শর্ত হিসাবে ব্যবহার করা হবে:

প্রকল্প	যোগ্যতার মান	যে প্রমাণ রাখা যেতে পারে
সম্পদ এবং পোর্টাল কভারেজ	CDN বাইপাস করতে পারে এমন সমস্ত বাহ্যিক এবং সরাসরি-সংযুক্ত দৃষ্টান্তগুলি আবিষ্কার করা হয়েছে৷	ডোমেনের নাম, এলবি, আইপি, পড/কন্টেইনার তালিকা
প্যাকেজ উৎস এবং মেরামতের সুযোগ	সমস্ত প্রযোজ্য CVE কভার করার জন্য নিশ্চিত করা সংস্করণ ব্যবহার করুন	আপস্ট্রিম নিরাপত্তা পরামর্শ, USN/DSA, প্যাকেজ সংস্করণ, ইমেজ ডাইজেস্ট
পুরানো প্রক্রিয়া প্রস্থান করে	সমস্ত পুরানো master/worker/কন্টেইনারগুলি প্রতিস্থাপন করা হয়েছে	PID/শুরু করার সময়, রোলিং স্থাপনার অবস্থা, চলমান চিত্র
কনফিগারেশন অডিট	উচ্চ-ঝুঁকির সংমিশ্রণগুলি বাদ দেওয়া হয়েছে বা প্যাচ দ্বারা আচ্ছাদিত করা হয়েছে, এবং উত্তরাধিকার সম্পর্ক যাচাই করা হয়েছে	nginx -T এর সংক্ষিপ্ত সারাংশ এবং নিরীক্ষা রেকর্ড
TLS/mTLS	বিশ্বস্ত সার্টিফিকেট পাস; অবৈধ বা অনুপস্থিত শংসাপত্র প্রত্যাখ্যান করা হয়; সেশন পুনঃসূচনা প্রমাণীকরণ বাইপাস করে না	নেতিবাচক/ইতিবাচক অনুমোদন পরীক্ষা, নিয়ন্ত্রিত TLS পরীক্ষার ফলাফল
HTTP/3 অনুরোধের বডি	স্থির পথ সক্ষম করুন; আপস্ট্রিম রিকোয়েস্ট বডি এবং থ্রটলিং সঠিকভাবে আচরণ করে	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

আপস্ট্রিম প্রভাবিত সংস্করণ, ফিক্স শাখা, এবং পাঁচটি অক্টোবর CVE-এর অফিসিয়াল তীব্রতা স্তর রয়েছে এবং 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

alias এবং ngx_http_map_uri_to_path()-এ 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 জাভাস্ক্রিপ্ট / 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 নিরাপত্তা আপডেট: কনফিগারেশন চেক, আপগ্রেড এবং যাচাইকরণ