Apache HTTP/2 ତ୍ରୁଟି CVE-2026-119618: ଆପଣଙ୍କ ସର୍ଭରଗୁଡ଼ିକୁ କିପରି ଯାଞ୍ଚ କରିବେ ଏବଂ 2.4.71 କୁ ପ୍ୟାଚ୍ କରିବେ

HTTP/2 ବ୍ୟବହାର କରୁଥିବା ଏକ ୱେବ୍ ସର୍ଭରକୁ କେବେ ବି ଲଗଇନ୍ ନକରିଥିବା ଜଣେ ଅଜଣା ବ୍ୟକ୍ତି ନିଜ ନିୟନ୍ତ୍ରଣକୁ ନେଇପାରେ। Apache HTTP Server ର HTTP/2 ମଡ୍ୟୁଲ୍‌ରେ ଥିବା ଏକ ଗୁରୁତର ତ୍ରୁଟି CVE-2026-119618 ପଛରେ ଥିବା ବିପଦ ଏହା ହିଁ ଅଟେ, ଏବଂ ଏହାର ସମାଧାନ ପୂର୍ବରୁ ଆସିସାରିଛି।

ଆଜି ନଭେମ୍ବର 13, 2026। ଏହି ତ୍ରୁଟିକୁ ବନ୍ଦ କରିବା ପାଇଁ Apache ନଭେମ୍ବର 11 ରେ ସଂସ୍କରଣ 2.4.71 ଜାରି କରିଛି, ଏବଂ ସୁରକ୍ଷା ଟିମ୍‌ଗୁଡ଼ିକ ଏବେ ସମାନ ପ୍ରଶ୍ନ ପଚାରୁଛନ୍ତି: ଆମେ ପ୍ରକୃତରେ ବିପଦର ସମ୍ମୁଖୀନ କି? ସଚ୍ଚୋଟ ଉତ୍ତର କେବଳ ଏକ ସଂସ୍କରଣ ନମ୍ବର ଉପରେ ନିର୍ଭର କରେ ନାହିଁ। ଏହା ନିର୍ଭର କରେ HTTP/2 ଚାଲୁ ଅଛି କି ନାହିଁ, ଆପଣଙ୍କ Linux ଭେଣ୍ଡର ଏହାର ପ୍ୟାକେଜ୍‌କୁ ପୂର୍ବରୁ ପ୍ୟାଚ୍ କରିସାରିଛି କି ନାହିଁ, ଏବଂ ଟ୍ରାଫିକ୍ କିପରି Apache ପାଖରେ ପହଞ୍ଚୁଛି। ଏହି ଗାଇଡ୍‌ରେ ଆମେ Acme ନାମକ ଏକ କମ୍ପାନୀର ସିଷ୍ଟମ୍ ଆଡମିନିଷ୍ଟ୍ରେଟର୍ ରୋହିତଙ୍କୁ ଉଦାହରଣ ଭାବରେ ନେଇ ଏହି ତିନୋଟି ବିଷୟ ବିସ୍ତୃତ ଭାବେ ବୁଝାଇଛୁ।

ସରଳ ଭାଷାରେ କହିଲେ ପ୍ରକୃତରେ କ’ଣ ଘଟିଲା

HTTP/2 ହେଉଛି ୱେବ୍‌ର ମୁଖ୍ୟ ପ୍ରୋଟୋକଲ୍‌ର ଏକ ନୂତନ ସଂସ୍କରଣ। ଏହାର ମୁଖ୍ୟ ଉଦ୍ଦେଶ୍ୟ ହେଉଛି ଅନେକ ଅନୁରୋଧ ଏବଂ ପ୍ରତିକ୍ରିୟା ଏକାସାଙ୍ଗରେ ଗୋଟିଏ କନେକ୍ସନ୍ ଅଂଶୀଦାର କରିପାରିବେ, ଯାହା ୱେବସାଇଟ୍‌ଗୁଡ଼ିକୁ ଦ୍ରୁତଗାମୀ କରିଥାଏ। Apache ରେ, ଏହି ସୁବିଧା ଏକ ମଡ୍ୟୁଲ୍‌ରୁ ଆସିଥାଏ ଯାହାର ନାମ ହେଉଛି mod_http2.

ଗୋଟିଏ କନେକ୍ସନ୍ ଅଂଶୀଦାର କରିବାର ଅର୍ଥ ହେଉଛି ସର୍ଭରର ଅନେକ ଅଂଶ ଏକାସାଙ୍ଗରେ କାମ କରନ୍ତି, ଏବଂ କିଏ ମେମୋରୀର କେଉଁ ଅଂଶ ବ୍ୟବହାର କରୁଛି ସେ ବିଷୟରେ ସେମାନଙ୍କୁ ସତର୍କ ରହିବାକୁ ପଡ଼ିବ। Red Hat ର ବୈଷୟିକ ମୂଲ୍ୟାଙ୍କନ ଅନୁଯାୟୀ, ଏହି କ୍ଷେତ୍ରରେ ସେହି ଯତ୍ନ ବାଧାପ୍ରାପ୍ତ ହୋଇଥିଲା। ଏକ worker thread (ଗୋଟିଏ ଅନୁରୋଧ ପରିଚାଳନା କରୁଥିବା ସର୍ଭରର ଏକ ଅଂଶ) ଏପରି ମେମୋରୀରେ ଲେଖିପାରୁଥିଲା ଯାହା connection thread (ସମଗ୍ର କନେକ୍ସନ୍ ପରିଚାଳନା କରୁଥିବା ଅଂଶ) ର ଅଧୀନରେ ଥିଲା, ଏକ ଅଂଶୀଦାରିତ ଲକ୍-ଫ୍ରି ମେମୋରୀ ଆଲୋକେଟର୍ ମାଧ୍ୟମରେ। ଏହି ସମସ୍ୟାଟି ଏପରି ଏକ ଫଙ୍କସନ୍‌ରେ ରହିଛି ଯାହାର ନାମ ହେଉଛି assign_headers(). ଯେତେବେଳେ ଦୁଇଟି ଅଂଶ ବିନା ସମନ୍ୱୟରେ ଗୋଟିଏ ମେମୋରୀରେ ଲେଖନ୍ତି, ଆଭ୍ୟନ୍ତରୀଣ ମେମୋରୀ କ୍ଷତିଗ୍ରସ୍ତ ହୋଇପାରେ, ଏବଂ ମେମୋରୀ କ୍ଷତିଗ୍ରସ୍ତ ହେବା ପ୍ରାୟତଃ ଆକ୍ରମଣକାରୀଙ୍କ କୋଡ୍ ଚଳାଇବାର ଦ୍ୱାର ଖୋଲିଦିଏ।

Red Hat ଏହି ତ୍ରୁଟିକୁ 10 ରୁ 9.8 ର CVSS v3.1 ସ୍କୋର ଦେଇଛି। ସେହି ସ୍କୋରର ଅର୍ଥ ହେଉଛି ଆକ୍ରମଣ ନେଟୱାର୍କ ମାଧ୍ୟମରେ କାମ କରେ, କୌଣସି ପାସୱାର୍ଡର ଆବଶ୍ୟକତା ନାହିଁ ଏବଂ ବ୍ୟବହାରକାରୀଙ୍କ ଠାରୁ କୌଣସି ସାହାଯ୍ୟର ଆବଶ୍ୟକତା ନାହିଁ।

କେଉଁ ସଂସ୍କରଣଗୁଡ଼ିକ ପ୍ରଭାବିତ

Apache ଏହି ସୀମାଗୁଡ଼ିକୁ ପ୍ରଭାବିତ ବୋଲି ତାଲିକାଭୁକ୍ତ କରିଛି:

• Apache HTTP Server 2.4.55 ରୁ 2.4.70 ପର୍ଯ୍ୟନ୍ତ.
• ପୃଥକ ଭାବେ ଜାରି କରାଯାଇଥିବା mod_h2 GitHub ରୁ ମଡ୍ୟୁଲ୍, ସଂସ୍କରଣ 2.0.8 ରୁ 2.0.42 ପର୍ଯ୍ୟନ୍ତ.

ସଂଶୋଧିତ ରିଲିଜ୍ ହେଉଛି Apache HTTP Server 2.4.71, କିମ୍ବା ଏକ ଭେଣ୍ଡର ପ୍ୟାକେଜ୍ ଯେଉଁଥିରେ ସ୍ପଷ୍ଟ ଭାବରେ ଏହି ଫିକ୍ସ ଅନ୍ତର୍ଭୁକ୍ତ ଅଛି।

Red Hat ନିଜର ପ୍ଲାଟଫର୍ମଗୁଡ଼ିକ ପାଇଁ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ ବିବରଣୀ ଯୋଡ଼ିଛି:

• RHEL 8 ଏବଂ ପୂର୍ବ ସଂସ୍କରଣଗୁଡ଼ିକ ପ୍ରଭାବିତ ନୁହଁନ୍ତି, କାରଣ ସେହି ଦୁର୍ବଳ କୋଡ୍ ସେଥିରେ ନାହିଁ।
• RHEL 9 ଏବଂ RHEL 10 କୁ Critical ପରିବର୍ତ୍ତେ Important ଭାବରେ ମୂଲ୍ୟାଙ୍କନ କରାଯାଇଛି। ସେଗୁଡ଼ିକର HTTP/2 ଷ୍ଟ୍ରିମ୍ ପୃଥକ ଆଲୋକେଟର୍ ବ୍ୟବହାର କରନ୍ତି, ଯାହା ଶୋଷଣକୁ ବହୁତ କଷ୍ଟକର କରିଥାଏ। ତଥାପି ସେଗୁଡ଼ିକୁ ଅପଡେଟ୍ ଆବଶ୍ୟକ, ଏବଂ Red Hat ନଭେମ୍ବର 11 ରେ ଅନେକ RHEL 9 ଏବଂ 10 ଷ୍ଟ୍ରିମ୍ ପାଇଁ ସମାଧାନ ଜାରି କରିଛି।

ଜଣେ ଆକ୍ରମଣକାରୀ ପ୍ରକୃତରେ କ’ଣ ହାସଲ କରିପାରିବେ

ସଫଳ ଶୋଷଣ ଜଣେ ଆକ୍ରମଣକାରୀଙ୍କୁ ନିୟନ୍ତ୍ରଣ ଦେଇପାରେ web-server processର। ତାହା ସ୍ୱତଃସ୍ପୃତ ଭାବରେ ମେସିନ୍ ଉପରେ ସମ୍ପୂର୍ଣ୍ଣ ନିୟନ୍ତ୍ରଣ ସହିତ ସମାନ ନୁହେଁ। ଆକ୍ରମଣକାରୀ କେଉଁ ପର୍ଯ୍ୟନ୍ତ ପହଞ୍ଚିପାରିବେ ତାହା ନିର୍ଭର କରେ Apache ପ୍ରକ୍ରିୟା କେଉଁଠାରେ ପହଞ୍ଚିପାରେ: ଆପ୍ଲିକେସନ୍‌ର ଡାଟା, ଏହା ଲେଖିପାରୁଥିବା ୱେବସାଇଟ୍ ଫୋଲ୍ଡରଗୁଡ଼ିକ, config ଫାଇଲ୍‌ରେ ସଂରକ୍ଷିତ କ୍ରେଡେନସିଆଲ୍ସ, ଏବଂ ଆଭ୍ୟନ୍ତରୀଣ ନେଟୱାର୍କରେ ଥିବା ଡାଟାବେସ୍ ଭଳି ଯେକୌଣସି ବ୍ୟାକଏଣ୍ଡ ସେବା।

ତେଣୁ ଏକ କମ୍-ବିଶେଷାଧିକାର (low-privilege) ବ୍ୟବହାରକାରୀ ଭାବରେ ଚାଲୁଥିବା ସୁସଂଗଠିତ ଭାବେ ପୃଥକୀକୃତ ସର୍ଭରରେ କ୍ଷତିର ପରିମାଣ ଏପରି ଏକ ସର୍ଭର ତୁଳନାରେ କମ୍ ହୋଇଥାଏ ଯେଉଁଠାରେ Apache ମେସିନ୍‌ରେ ଥିବା ପ୍ରତ୍ୟେକ ଗୋପନୀୟ ତଥ୍ୟ ପଢ଼ିପାରେ। ଏହାକୁ ମଧ୍ୟ ଯାଞ୍ଚ କରିବା ପାଇଁ ଏହା ଏକ ଭଲ ସମୟ।

ଆପଣଙ୍କ ସର୍ଭର ପ୍ରକୃତରେ ବିପଦର ସମ୍ମୁଖୀନ କି?

ଏହିଠାରେ ଅନେକ ଟିମ୍ ଉଭୟ ଦିଗରେ ଭୁଲ୍ ବୁଝନ୍ତି। କେବଳ ଏକ ସଂସ୍କରଣ ନମ୍ବର ବିପଦର ପ୍ରମାଣ ନୁହେଁ, ଏବଂ ଏକ ସୁରକ୍ଷିତ ଦେଖାଯାଉଥିବା ସାର୍ବଜନୀନ ୱେବସାଇଟ୍ ସୁରକ୍ଷାର ପ୍ରମାଣ ନୁହେଁ।

କେବଳ ମଡ୍ୟୁଲ୍ ଲୋଡ୍ କରିବା ଯଥେଷ୍ଟ ନୁହେଁ। ଲକ୍ସମବର୍ଗର CIRCL ଉଲ୍ଲେଖ କରିଛି ଯେ ଦୁର୍ବଳ ପାଥ୍ (vulnerable path) କେବଳ ସେତେବେଳେ ଉପଲବ୍ଧ ହୁଏ ଯେତେବେଳେ ସେବା ପ୍ରକୃତରେ HTTP/2 ଗ୍ରହଣ କରେ। ଯଦି mod_http2 ଲୋଡ୍ ହୋଇଛି କିନ୍ତୁ କୌଣସି ଲିସନର୍ HTTP/2 ପ୍ରଦାନ କରୁନାହିଁ, ତେବେ ସେହି ପାଥ୍ ପହଞ୍ଚିବା ଯୋଗ୍ୟ ନୁହେଁ।

ଉଭୟ ପ୍ରକାରର HTTP/2 ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ। TLS ମାଧ୍ୟମରେ ଏନକ୍ରିପ୍ଟ ହୋଇଥିବା HTTP/2 କୁ କୁହାଯାଏ h2। TLS ବିନା କ୍ଲିଅରଟେକ୍ସଟ୍ (cleartext) HTTP/2 କୁ କୁହାଯାଏ h2c। ଯେକୌଣସି ଲିସନର୍‌ରେ ଏଥିମଧ୍ୟରୁ ଯେକୌଣସି ଗୋଟିଏ ସକ୍ଷମ ଥିଲେ ତାହା ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ।

Virtual hosts ଭିନ୍ନ ହୋଇପାରନ୍ତି। Apache ଆପଣଙ୍କୁ ସମଗ୍ର ସର୍ଭର ପାଇଁ ଏବଂ ପୁନର୍ବାର ପ୍ରତ୍ୟେକ virtual host ପାଇଁ ପ୍ରୋଟୋକଲ୍ ସେଟ୍ କରିବାକୁ ଅନୁମତି ଦିଏ। କେବଳ ମୁଖ୍ୟ config ଫାଇଲ୍ ସମୀକ୍ଷା କଲେ ଏପରି ଏକ ସାଇଟ୍ ବାଦ୍ ପଡ଼ିପାରେ ଯାହା ନିଜେ HTTP/2 ଚାଲୁ କରିଛି।

ପ୍ରକ୍ସିଗୁଡ଼ିକ ସ୍ଥିତିକୁ ବଦଳାଇ ଦିଅନ୍ତି। ଯଦି ଏକ CDN, load balancer କିମ୍ବା reverse proxy ଆଗରେ ରହି ଦର୍ଶକଙ୍କ ସହ HTTP/2 ରେ କଥାବାର୍ତ୍ତା କରେ କିନ୍ତୁ Apache ସହିତ କେବଳ HTTP/1.1 ବ୍ୟବହାର କରେ, ତେବେ ବାହାର HTTP/2 ସେସନ୍ ନିଜେ ଏହି ବଗ୍‌କୁ ଉନ୍ମୁକ୍ତ କରେ ନାହିଁ। କିନ୍ତୁ origin ସର୍ଭରକୁ ସିଧାସଳଖ ଆକ୍ସେସ୍, ଏକ ଆଭ୍ୟନ୍ତରୀଣ ଲିସନର୍, କିମ୍ବା ଏକ ପ୍ରକ୍ସି ଯାହା Apache କୁ HTTP/2 ଫରୱାର୍ଡ କରେ, ତାହା ବିପଦ ସୃଷ୍ଟି କରିବ।

ରୋହିତଙ୍କ ପରିସ୍ଥିତି ଦର୍ଶାଉଛି ଯେ ଏହା କାହିଁକି ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ। Acme ର ମୁଖ୍ୟ ୱେବସାଇଟ୍ ଏକ CDN ପଛରେ ଅଛି, ତେଣୁ ଏକ ସାର୍ବଜନୀନ ସ୍କାନ୍ ସବୁଠି HTTP/2 ଦେଖାଏ। ଭିତରେ, ସେ ତିନୋଟି ପରିସ୍ଥିତି ପାଇଲେ: ମୁଖ୍ୟ ସାଇଟ୍‌ର Apache କେବଳ CDN ରୁ HTTP/1.1 ଗ୍ରହଣ କରେ, ଏକ ଆଭ୍ୟନ୍ତରୀଣ ୱିକି ସିଧାସଳଖ h2 ମାଧ୍ୟମରେ ପହଞ୍ଚିଥାଏ, ଏବଂ ଏକ ପୁରୁଣା ମାର୍କେଟିଂ virtual host ନିଜେ h2c ସକ୍ଷମ କରେ। ତିନୋଟି ମଧ୍ୟରୁ ଦୁଇଟିରେ ଜରୁରୀ କାର୍ଯ୍ୟ ଆବଶ୍ୟକ, ଏବଂ ସାର୍ବଜନୀନ ସ୍କାନ୍ ତାଙ୍କୁ ଏ ବିଷୟରେ କିଛି କହିନଥାନ୍ତା।

ପଦକ୍ଷେପ ଅନୁଯାୟୀ: ରୋହିତ ଆଜି କ’ଣ କରନ୍ତି

ପଦକ୍ଷେପ 1: ପ୍ରତ୍ୟେକ Apache ସର୍ଭର ଏବଂ ଏହାର ସଂସ୍କରଣ ଖୋଜନ୍ତୁ

ସର୍ଭରଗୁଡ଼ିକର ତାଲିକା ପ୍ରସ୍ତୁତ କରନ୍ତୁ, ତା’ପରେ ପ୍ରତ୍ୟେକଟି ଯାଞ୍ଚ କରନ୍ତୁ। distribution ଅନୁସାରେ କମାଣ୍ଡ ନାମ ଭିନ୍ନ ହୋଇଥାଏ।

# RHEL, Rocky, Alma, Fedora
httpd -v
# Debian, Ubuntu
apache2 -v

ମନେରଖନ୍ତୁ ଯେ ଭେଣ୍ଡରମାନେ ପ୍ରାୟତଃ ମୁଖ୍ୟ ସଂସ୍କରଣ ନମ୍ବର ପରିବର୍ତ୍ତନ ନକରି ଏକ ବଗ୍ ଠିକ୍ କରନ୍ତି (ଏହାକୁ କୁହାଯାଏ backporting)। କେବଳ ସଂସ୍କରଣ ଷ୍ଟ୍ରିଙ୍ଗ୍ ନୁହେଁ, ଆପଣଙ୍କ ଭେଣ୍ଡରଙ୍କ ପରାମର୍ଶ ବିରୁଦ୍ଧରେ ପ୍ୟାକେଜ୍ ଯାଞ୍ଚ କରନ୍ତୁ।

# RHEL family: is the fix for this CVE available or installed?
dnf updateinfo list --cve CVE-2026-119618
# Debian and Ubuntu: does the installed package mention the CVE?
apt changelog apache2 | grep -i CVE-2026-119618

ପଦକ୍ଷେପ 2: HTTP/2 ପ୍ରକୃତରେ ପ୍ରଦାନ କରାଯାଉଛି କି ନାହିଁ ଯାଞ୍ଚ କରନ୍ତୁ

ପ୍ରଥମେ ଦେଖନ୍ତୁ ଯେ ମଡ୍ୟୁଲ୍ ଲୋଡ୍ ହୋଇଛି କି ନାହିଁ, ତା’ପରେ virtual hosts ସମେତ ପ୍ରୋଟୋକଲ୍ ସେଟିଙ୍ଗ୍ସ ପାଇଁ ପ୍ରତ୍ୟେକ config ଫାଇଲ୍ ସନ୍ଧାନ କରନ୍ତୁ।

# Is mod_http2 loaded?
apachectl -M 2>/dev/null | grep -i http2
# Where is HTTP/2 enabled? Look for h2 or h2c on any Protocols line
grep -RniE '^\s*Protocols' /etc/httpd/ /etc/apache2/ 2>/dev/null

ତା’ପରେ ବାହାରୁ ଏବଂ ଭିତରୁ ପରୀକ୍ଷା କରନ୍ତୁ। --http2 TLS ମାଧ୍ୟମରେ h2 ପାଇଁ ଅନୁରୋଧ କରେ, ଏବଂ --http2-prior-knowledge କ୍ଲିଅରଟେକ୍ସଟ୍ h2c ଚେଷ୍ଟା କରେ। ଏକ ଫଳାଫଳ 2 ର ଅର୍ଥ ହେଉଛି HTTP/2 ବ୍ୟବହୃତ ହୋଇଥିଲା।

curl -s -o /dev/null -w '%{http_version}\n' --http2 https://app.example.com/
curl -s -o /dev/null -w '%{http_version}\n' --http2-prior-knowledge http://203.0.113.10/

କେବଳ ସାର୍ବଜନୀନ ୱେବସାଇଟ୍ ନୁହେଁ, origin ଠିକଣା ଏବଂ ଆଭ୍ୟନ୍ତରୀଣ ନାମଗୁଡ଼ିକ ବିରୁଦ୍ଧରେ ମଧ୍ୟ ଏଗୁଡ଼ିକୁ ଚଲାନ୍ତୁ।

ପଦକ୍ଷେପ 3: 2.4.71 କିମ୍ବା ଭେଣ୍ଡରଙ୍କ ସଂଶୋଧିତ ପ୍ୟାକେଜ୍‌କୁ ପ୍ୟାଚ୍ କରନ୍ତୁ

ଆପଣଙ୍କ ଭେଣ୍ଡରଙ୍କ ଅପଡେଟ୍ ପ୍ରୟୋଗ କରନ୍ତୁ (କିମ୍ବା ଯଦି ଆପଣ ସୋର୍ସରୁ Apache ଚଳାଉଛନ୍ତି ତେବେ 2.4.71 ବିଲ୍ଡ କରନ୍ତୁ), ତା’ପରେ ସେବାକୁ ରିଷ୍ଟାର୍ଟ କରନ୍ତୁ ଯାହାଦ୍ୱାରା ନୂତନ କୋଡ୍ ପ୍ରକୃତରେ ଚାଲିବ। ପ୍ୟାକେଜ୍ ଅପଡେଟ୍ ପରେ ଏକ ରିଲୋଡ୍ ସର୍ବଦା ଯଥେଷ୍ଟ ନୁହେଁ; ଏକ ରିଷ୍ଟାର୍ଟ ହେଉଛି ସୁରକ୍ଷିତ ବିକଳ୍ପ।

# RHEL family
sudo dnf update httpd mod_http2
sudo systemctl restart httpd
# Debian and Ubuntu
sudo apt update && sudo apt install --only-upgrade apache2
sudo systemctl restart apache2

ତା’ପରେ ଚାଲୁଥିବା ବିଲ୍ଡ ସଂଶୋଧିତ ହୋଇଛି ବୋଲି ନିଶ୍ଚିତ କରିବାକୁ ପଦକ୍ଷେପ 1 ପୁନରାବୃତ୍ତି କରନ୍ତୁ।

ପଦକ୍ଷେପ 4: ଯଦି ଆପଣ ଏପର୍ଯ୍ୟନ୍ତ ପ୍ୟାଚ୍ କରିପାରିବେ ନାହିଁ, ତେବେ HTTP/2 ବନ୍ଦ କରନ୍ତୁ

ଏକ ଅସ୍ଥାୟୀ ପଦକ୍ଷେପ ଭାବରେ, ପ୍ରୋଟୋକଲ୍‌କୁ HTTP/1.1 ରେ ସୀମିତ କରନ୍ତୁ। ଏହାକୁ ମୁଖ୍ୟ config ରେ ଏବଂ ନିଜସ୍ୱ ପ୍ରୋଟୋକଲ୍ ସେଟ୍ କରୁଥିବା ପ୍ରତ୍ୟେକ virtual host ରେ ରଖନ୍ତୁ, ଯେକୌଣସି h2 ଏବଂ h2c ପ୍ରବିଷ୍ଟିଗୁଡ଼ିକୁ ହଟାଇ ଦିଅନ୍ତୁ:

Protocols http/1.1

config କୁ ବୈଧ କରନ୍ତୁ, ଏହାକୁ ଲାଗୁ କରନ୍ତୁ, ଏବଂ ପଦକ୍ଷେପ 2 ରୁ curl କମାଣ୍ଡ ସହିତ ପୁନର୍ବାର ପରୀକ୍ଷା କରନ୍ତୁ। ଆପଣ ଦେଖିବାକୁ ଚାହାଁନ୍ତି 1.1, ଏହା ନୁହେଁ 2.

apachectl configtest && sudo systemctl reload httpd    # or apache2

Debian ଏବଂ Ubuntu ରେ ଆପଣ ଏହା ସହିତ ମଡ୍ୟୁଲ୍‌କୁ ମଧ୍ୟ ଅକ୍ଷମ କରିପାରିବେ sudo a2dismod http2, ଏବଂ ଏହା ପରେ ଏକ ରିଷ୍ଟାର୍ଟ କରନ୍ତୁ। ପ୍ୟାଚ୍ କରିବା ପରେ HTTP/2 ଫେରିବା ପର୍ଯ୍ୟନ୍ତ କିଛି ଭିଜିଟରଙ୍କ ପାଇଁ ପେଜ୍ ଲୋଡ୍ ସାମାନ୍ୟ ମନ୍ଥର ହେବାର ଆଶା କରନ୍ତୁ।

ପଦକ୍ଷେପ 5: ପୂର୍ବରୁ ହୋଇଥିବା ସମସ୍ୟାର ସଙ୍କେତ ଖୋଜନ୍ତୁ

ପ୍ୟାଚିଂ ଦ୍ୱାର ବନ୍ଦ କରିଦିଏ, କିନ୍ତୁ କେହି ପ୍ରଥମେ ଏହା ମାଧ୍ୟମରେ ପ୍ରବେଶ କରିଥିଲେ କି ନାହିଁ ତାହା ଏହା ଆପଣଙ୍କୁ କହେ ନାହିଁ। CIRCL ଅପ୍ରତ୍ୟାଶିତ Apache worker କ୍ରାସ୍, ଅଦ୍ଭୁତ child processes, ୱେବ୍ ଫୋଲ୍ଡରଗୁଡ଼ିକରେ ଅଣ-ଅନୁମୋଦିତ ଫାଇଲ୍ ପରିବର୍ତ୍ତନ, ଏବଂ ସର୍ଭରରୁ ଅସ୍ୱାଭାବିକ ଆଉଟବାଉଣ୍ଡ କନେକ୍ସନ୍‌ଗୁଡ଼ିକୁ ସମୀକ୍ଷା କରିବାକୁ ପରାମର୍ଶ ଦିଏ। ଏଗୁଡ଼ିକ ମଧ୍ୟରୁ କୌଣସିଟି ନିଜେ ଏକ ଆକ୍ରମଣ ବୋଲି ପ୍ରମାଣ କରେ ନାହିଁ, କିନ୍ତୁ ପ୍ରତ୍ୟେକଟି ଉପରେ ନଜର ପକାଇବା ଉଚିତ।

ଏକ୍ସପ୍ଲୋଇଟ୍ ରିପୋର୍ଟ ବିଷୟରେ

ଉତ୍ସଗୁଡ଼ିକ ଭିନ୍ନ ମତ ଦିଅନ୍ତି, ତେଣୁ ଶିରୋନାମାଗୁଡ଼ିକୁ ଯତ୍ନର ସହ ପଢ଼ନ୍ତୁ। Red Hat କହିଛି ଯେ ସାର୍ବଜନୀନ ଗବେଷଣା mod_http2 ସକ୍ଷମ ଥିବା ଏକ ଡିଫଲ୍ଟ ସର୍ଭର ବିରୁଦ୍ଧରେ ବିଶ୍ୱସନୀୟ ଶୋଷଣ ଦର୍ଶାଇଛି। Wiz, ନଭେମ୍ବର 11 ରେ କହିଥିଲା ଯେ କୌଣସି ଏକ୍ସପ୍ଲୋଇଟ୍ ଉପଲବ୍ଧ ନାହିଁ ଏବଂ ସେହି ସମୟରେ ପ୍ରକୃତ କ୍ଷେତ୍ରରେ କୌଣସି ଆକ୍ରମଣ ଦେଖାଯାଇ ନାହିଁ। CIRCL ଉଲ୍ଲେଖ କରିଛି ଯେ ଏକ ଡେମୋନଷ୍ଟ୍ରେସନ୍ ପ୍ରକୃତ କ୍ଷେତ୍ରରେ ଆକ୍ରମଣକୁ ପ୍ରମାଣ କରେ ନାହିଁ।

Wiz ମଧ୍ୟ ରିପୋର୍ଟ କରିଛି ଯେ ଏହାର ନିଜସ୍ୱ ଡାଟାରେ ଥିବା 64% କ୍ଲାଉଡ୍ ପରିବେଶରେ ଏହି ତ୍ରୁଟି ପ୍ରତି ଦୁର୍ବଳ ଥିବା ଉତ୍ସଗୁଡ଼ିକ ରହିଛି। ସେହି ସଂଖ୍ୟା Wiz ର ଡାଟାସେଟ୍‌କୁ ବର୍ଣ୍ଣନା କରେ, ଇଣ୍ଟରନେଟ୍‌ରେ ଥିବା ସମସ୍ତ Apache ସର୍ଭରର ଅଂଶକୁ ନୁହେଁ।

ସୁରକ୍ଷିତ ଧାରଣା: ଏହି ରିପୋର୍ଟଗୁଡ଼ିକରେ କୌଣସି ନିଶ୍ଚିତ ଆକ୍ରମଣ ଅଭିଯାନ ନାହିଁ, କିନ୍ତୁ ଏକ କାର୍ଯ୍ୟକ୍ଷମ କୌଶଳ ଦେଖାଯାଇଛି, ତେଣୁ ଶୀଘ୍ର ପ୍ୟାଚ୍ କରନ୍ତୁ।

ଏହାକୁ କିଏ ଖୋଜି ବାହାର କରିଥିଲେ, ଏବଂ 2.4.71 ଅନ୍ୟ କ’ଣ ସମାଧାନ କରେ

Apache ଏହାର ଶ୍ରେୟ Anthropic ର OSS Scanner ଏବଂ Google Cloud Vulnerability Research ର Anthony Weems ଏବଂ Simon Scannell ଙ୍କୁ ଦେଇଛି। ଟାଇମଲାଇନ୍ ଅକ୍ଟୋବର 26 ରେ Anthropic ଠାରୁ ଏକ ରିପୋର୍ଟ, ନଭେମ୍ବର 3 ରେ Google ଠାରୁ ଏକ ରିପୋର୍ଟ, ଏବଂ ନଭେମ୍ବର 11 ରେ ସମାଧାନ ତଥା ରିଲିଜ୍ ଦର୍ଶାଉଛି।

ସଂସ୍କରଣ 2.4.71 ଦୁଇଟି ଛୋଟ ସମସ୍ୟାର ମଧ୍ୟ ସମାଧାନ କରେ:

• CVE-2026-106023 (Important): mod_md ରେ ଏକ null-pointer dereference ଯାହା ଏକ child process କୁ କ୍ରାସ୍ କରିପାରେ, 2.4.30 ରୁ 2.4.70 ସଂସ୍କରଣରେ।
• CVE-2026-109163 (Low): mod_vhost_alias ରେ ଏକ stack-buffer overwrite, 2.4.69 ଏବଂ 2.4.70 ସଂସ୍କରଣରେ।

ଉପସଂହାର

CVE-2026-119618 ଗୁରୁତର ଅଟେ: କୌଣସି ଲଗଇନ୍ ନାହିଁ, ନେଟୱାର୍କରେ ପହଞ୍ଚିବା ଯୋଗ୍ୟ, ୱେବ୍ ସର୍ଭରର ସମ୍ଭାବ୍ୟ ନିୟନ୍ତ୍ରଣ। କିନ୍ତୁ ପ୍ରକୃତ ବିପଦ ନିର୍ଭର କରେ HTTP/2 କିମ୍ବା h2c ପ୍ରଦାନ କରାଯାଉଛି କି ନାହିଁ, ଆପଣଙ୍କ ଭେଣ୍ଡରଙ୍କ ପ୍ୟାକେଜ୍ ଉପରେ, ଏବଂ ଟ୍ରାଫିକ୍ କିପରି Apache ପାଖରେ ପହଞ୍ଚୁଛି ତାହା ଉପରେ। ପ୍ରତ୍ୟେକ ସର୍ଭର ଖୋଜନ୍ତୁ, ପ୍ରତ୍ୟେକ virtual host ଯାଞ୍ଚ କରନ୍ତୁ, 2.4.71 କିମ୍ବା ଭେଣ୍ଡର ଫିକ୍ସକୁ ପ୍ୟାଚ୍ କରନ୍ତୁ, ଯେଉଁଠାରେ ଆପଣଙ୍କୁ ଅପେକ୍ଷା କରିବାକୁ ପଡ଼ିବ ସେଠାରେ HTTP/2 ବନ୍ଦ କରନ୍ତୁ, ଏବଂ ତା’ପରେ ପୂର୍ବରୁ ହୋଇଥିବା ଅପବ୍ୟବହାରର ସଙ୍କେତ ଖୋଜନ୍ତୁ।

ସୁବିଧାଗୁଡ଼ିକ

• ଏହି ସମାଧାନ ପୂର୍ବରୁ ଜାରି କରାଯାଇଛି, ତେଣୁ ସୁରକ୍ଷା ପାଇଁ ଏକ ସ୍ପଷ୍ଟ ପଥ ରହିଛି।
• ଏକ ଅସ୍ଥାୟୀ ସମାଧାନ ଭାବରେ ଗୋଟିଏ config ଧାଡ଼ି ସହିତ HTTP/2 ବନ୍ଦ କରାଯାଇପାରିବ।
• RHEL 8 ଏବଂ ପୁରୁଣା ସଂସ୍କରଣଗୁଡ଼ିକ ପ୍ରଭାବିତ ନୁହଁନ୍ତି, ଏବଂ RHEL 9 ତଥା 10 କୁ ଶୋଷଣ କରିବା ଅଧିକ କଷ୍ଟକର।
• Apache ସହିତ କେବଳ HTTP/1.1 ବ୍ୟବହାର କରୁଥିବା ଏକ ପ୍ରକ୍ସି ବିପଦକୁ ହ୍ରାସ କରିଥାଏ।
• Apache ପ୍ରକ୍ରିୟା କେଉଁଠାରେ ପହଞ୍ଚିପାରିବ ତାହାକୁ କଡ଼ାକଡ଼ି କରିବା ପାଇଁ ଏହି ସମୀକ୍ଷା ଏକ ଉତ୍ତମ ସୁଯୋଗ।

ଅସୁବିଧାଗୁଡ଼ିକ

• ଏହି ତ୍ରୁଟି ପାଇଁ କୌଣସି ଲଗଇନ୍ ଆବଶ୍ୟକ ନାହିଁ ଏବଂ ଏହାର ସ୍କୋର 9.8, ତେଣୁ ଉନ୍ମୁକ୍ତ ଥିବା ସର୍ଭରଗୁଡ଼ିକ ପ୍ରକୃତ ବିପଦରେ ଅଛନ୍ତି।
• ଭେଣ୍ଡରମାନେ ସମାଧାନକୁ backport କରୁଥିବାରୁ ସଂସ୍କରଣ ଷ୍ଟ୍ରିଙ୍ଗ୍ ଭ୍ରମିତ କରିପାରେ।
• ପ୍ରତ୍ୟେକ virtual host ଅନୁଯାୟୀ ସେଟିଙ୍ଗ୍ସ ଯୋଗୁଁ ଗୋଟିଏ ଉନ୍ମୁକ୍ତ ସାଇଟ୍ ବାଦ୍ ପଡ଼ିଯିବା ସହଜ ହୋଇଯାଏ।
• HTTP/2 ବନ୍ଦ କରିବା ଦ୍ୱାରା କିଛି ପୃଷ୍ଠା ଲୋଡ୍ ହେବା ସାମାନ୍ୟ ମନ୍ଥର ହୋଇପାରେ।
• ସମାଧାନ ପୂର୍ବରୁ ଏକ ସର୍ଭର ଆକ୍ରମଣର ଶିକାର ହୋଇଥିଲା କି ନାହିଁ ତାହା ପ୍ୟାଚିଂ ପ୍ରକାଶ କରେ ନାହିଁ।

ସତର୍କତା

ଏହି ଆର୍ଟିକିଲ୍‌ଟି ଶିକ୍ଷଣୀୟ ଉଦ୍ଦେଶ୍ୟରେ ଲେଖାଯାଇଛି। ହୋଷ୍ଟ ନାମ, IP ଠିକଣା ଏବଂ Acme କମ୍ପାନୀର ନାମ କାଳ୍ପନିକ ଅଟେ ଏବଂ ଏହାକୁ ଆପଣଙ୍କ ନିଜସ୍ୱ ବିବରଣୀ ସହିତ ବଦଳାଇବାକୁ ପଡ଼ିବ। distribution ଏବଂ ସଂସ୍କରଣ ମଧ୍ୟରେ କମାଣ୍ଡଗୁଡ଼ିକ ଭିନ୍ନ ହୋଇଥାଏ, ତେଣୁ ଆପଣଙ୍କ ଭେଣ୍ଡରଙ୍କ ପରାମର୍ଶ ପଢ଼ନ୍ତୁ ଏବଂ ପ୍ରଥମେ ଏକ non-production ସର୍ଭରରେ ପରିବର୍ତ୍ତନଗୁଡ଼ିକ ପରୀକ୍ଷା କରନ୍ତୁ। ଏକ୍ସପ୍ଲୋଇଟ୍ ଏବଂ ପ୍ରଭାବିତ ପରିସର ବିଷୟରେ ଦାବିଗୁଡ଼ିକ ଏଠାରେ ସଂକ୍ଷିପ୍ତ ଭାବରେ ପ୍ରଦତ୍ତ ଭେଣ୍ଡର ତଥା ଗବେଷକଙ୍କ ବିବୃତ୍ତିରୁ ଆସିଛି ଏବଂ ଏହା ପରିବର୍ତ୍ତନ ହୋଇପାରେ, ତେଣୁ ସେଗୁଡ଼ିକ ଉପରେ ନିର୍ଭର କରିବା ପୂର୍ବରୁ ଅଫିସିଆଲ୍ Apache ଏବଂ ଭେଣ୍ଡରଙ୍କ ପରାମର୍ଶ ବିରୁଦ୍ଧରେ ସେଗୁଡ଼ିକୁ ଯାଞ୍ଚ କରନ୍ତୁ।

ବାରମ୍ବାର ପଚରାଯାଉଥିବା ପ୍ରଶ୍ନଗୁଡ଼ିକ

• CVE-2026-119618 କ’ଣ? — ଏହା Apache HTTP Server ର HTTP/2 ମଡ୍ୟୁଲ୍‌ରେ ଏକ ଗୁରୁତର memory-corruption ତ୍ରୁଟି ଯାହା ବିନା ପ୍ରମାଣୀକରଣରେ ରିମୋଟ୍ କୋଡ୍ ଏକ୍ସିକ୍ୟୁସନ୍‌କୁ ଅନୁମତି ଦେଇପାରେ।
• କେଉଁ Apache ସଂସ୍କରଣଗୁଡ଼ିକ ପ୍ରଭାବିତ? — Apache HTTP Server 2.4.55 ରୁ 2.4.70 ପର୍ଯ୍ୟନ୍ତ, ଏବଂ ପୃଥକ mod_h2 ମଡ୍ୟୁଲ୍ ସଂସ୍କରଣ 2.0.8 ରୁ 2.0.42 ପର୍ଯ୍ୟନ୍ତ।
• କେଉଁ ସଂସ୍କରଣ ଏହାର ସମାଧାନ କରେ? — Apache HTTP Server 2.4.71, ଯାହା ନଭେମ୍ବର 11, 2026 ରେ ଜାରି କରାଯାଇଛି, କିମ୍ବା ଏକ ଭେଣ୍ଡର ପ୍ୟାକେଜ୍ ଯେଉଁଥିରେ ସ୍ପଷ୍ଟ ଭାବରେ ଏହି ସମାଧାନ ଅନ୍ତର୍ଭୁକ୍ତ।
• ଯଦି mod_http2 ଲୋଡ୍ ଅଛି କିନ୍ତୁ HTTP/2 ସକ୍ଷମ ନାହିଁ, ତେବେ ମୋର ସର୍ଭର ସୁରକ୍ଷିତ କି? — ଦୁର୍ବଳ ପାଥ୍ ପାଇଁ ସେବା HTTP/2 ଗ୍ରହଣ କରିବା ଆବଶ୍ୟକ, ତେଣୁ କୌଣସି ଲିସନର୍‌ରେ h2 କିମ୍ବା h2c ପ୍ରଦାନ କରୁନଥିବା ଏକ ସର୍ଭର ଏହି ତ୍ରୁଟି ମାଧ୍ୟମରେ ପହଞ୍ଚିବା ଯୋଗ୍ୟ ନୁହେଁ।
• ମୁଁ ଏକ CDN କିମ୍ବା load balancer ପଛରେ ସୁରକ୍ଷିତ କି? — କେବଳ ଯଦି ପ୍ରକ୍ସି Apache ସହିତ HTTP/1.1 ରେ ଯୋଗାଯୋଗ କରେ ଏବଂ କେହି ସିଧାସଳଖ HTTP/2 ମାଧ୍ୟମରେ origin ସର୍ଭରରେ ପହଞ୍ଚିପାରିବେ ନାହିଁ।
• RHEL ପ୍ରଭାବିତ କି? — RHEL 8 ଏବଂ ପୂର୍ବ ସଂସ୍କରଣ ପ୍ରଭାବିତ ନୁହଁନ୍ତି; RHEL 9 ଏବଂ 10 କୁ Important ଭାବରେ ମୂଲ୍ୟାଙ୍କନ କରାଯାଇଛି ଏବଂ Red Hat ର ଅପଡେଟ୍ ଲାଗୁ କରିବା ଉଚିତ।
• ମୁଁ Apache ରେ ଅସ୍ଥାୟୀ ଭାବରେ HTTP/2 କିପରି ଅକ୍ଷମ କରିବି? — ସେଟ୍ କରନ୍ତୁ Protocols http/1.1 ମୁଖ୍ୟ config ଏବଂ ପ୍ରତ୍ୟେକ virtual host ରେ, ଏକ config test ଚଲାନ୍ତୁ, ତା’ପରେ Apache ରିଲୋଡ୍ କରନ୍ତୁ।
• ଏହି ତ୍ରୁଟି ପ୍ରକୃତ କ୍ଷେତ୍ରରେ (in the wild) ଶୋଷଣ କରାଯାଉଛି କି? — ଏଠାରେ ଉଲ୍ଲେଖ କରାଯାଇଥିବା ରିପୋର୍ଟଗୁଡ଼ିକ ଏକ ସାର୍ବଜନୀନ ପ୍ରଦର୍ଶନ ବର୍ଣ୍ଣନା କରେ କିନ୍ତୁ ପ୍ରକୃତ କ୍ଷେତ୍ରରେ କୌଣସି ନିଶ୍ଚିତ ଆକ୍ରମଣ ହୋଇନାହିଁ, ତେଣୁ କୌଣସି ଅଭିଯାନ ଅନୁମାନ ନକରି ଶୀଘ୍ର ପ୍ୟାଚ୍ କରନ୍ତୁ।

ଟ୍ୟାଗ୍‌ଗୁଡ଼ିକ

#apache #cybersecurity #cve2026119618 #http2 #modhttp2 #vulnerabilitymanagement #patchmanagement #linuxsecurity #webserver #devsecops