Apache HTTP/2 സുരക്ഷാ പിഴവ് CVE-2026-119618: നിങ്ങളുടെ സെർവറുകൾ എങ്ങനെ പരിശോധിക്കാം, 2.4.71-ലേക്ക് എങ്ങനെ പാച്ച് ചെയ്യാം

HTTP/2 ഉപയോഗിക്കുന്ന ഒരു വെബ് സെർവർ ഒരിക്കലും ലോഗിൻ ചെയ്യാത്ത ഒരു അപരിചിതന് കൈക്കലാക്കാൻ കഴിഞ്ഞേക്കാം. Apache HTTP Server-ന്റെ HTTP/2 മൊഡ്യൂളിലെ അതീവ ഗുരുതരമായ സുരക്ഷാ പിഴവായ CVE-2026-119618-ന് പിന്നിലെ അപകടസാധ്യത ഇതാണ്, ഇതിനുള്ള പരിഹാരം ഇതിനകം ലഭ്യമാക്കിയിട്ടുണ്ട്.

ഇന്ന് 2026 നവംബർ 13. ഈ സുരക്ഷാ വിടവ് അടയ്ക്കുന്നതിനായി Apache നവംബർ 11-ന് പതിപ്പ് 2.4.71 പുറത്തിറക്കി. ഇപ്പോൾ സുരക്ഷാ ടീമുകൾ ഒരേ ചോദ്യം തന്നെയാണ് ചോദിക്കുന്നത്: ഞങ്ങൾ യഥാർത്ഥത്തിൽ അപകടസാധ്യതയിലാണോ? ഇതിനുള്ള കൃത്യമായ ഉത്തരം വെറുമൊരു പതിപ്പ് നമ്പറിനെ മാത്രം ആശ്രയിച്ചുള്ളതല്ല. HTTP/2 ഓൺ ചെയ്തിട്ടുണ്ടോ, നിങ്ങളുടെ Linux വെണ്ടർ അവരുടെ പാക്കേജ് ഇതിനകം പാച്ച് ചെയ്തിട്ടുണ്ടോ, ട്രാഫിക് Apache-ലേക്ക് എങ്ങനെ എത്തുന്നു എന്നിവയെ ആശ്രയിച്ചാണിത്. Acme എന്ന് ഞങ്ങൾ വിളിക്കുന്ന ഒരു കമ്പനിയിലെ സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്ററായ Rohit-നെ ഉദാഹരണമാക്കി ഈ ഗൈഡ് ഇവ മൂന്നും വിശദീകരിക്കുന്നു.

ലളിതമായ വാക്കുകളിൽ എന്താണ് സംഭവിച്ചത്

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 സ്ട്രീമുകൾ പ്രത്യേക അലോക്കേറ്ററുകൾ ഉപയോഗിക്കുന്നു, ഇത് ചൂഷണം ചെയ്യുന്നത് കൂടുതൽ ദുഷ്കരമാക്കുന്നു. എന്നിരുന്നാലും അവയ്ക്ക് അപ്‌ഡേറ്റ് ആവശ്യമാണ്, കൂടാതെ നവംബർ 11-ന് നിരവധി RHEL 9, 10 സ്ട്രീമുകൾക്കായി Red Hat പരിഹാരങ്ങൾ പുറത്തിറക്കി.

ഒരു ആക്രമണകാരിക്ക് യഥാർത്ഥത്തിൽ എന്തൊക്കെ ലഭിക്കാം

വിജയകരമായ ചൂഷണം വഴി ആക്രമണകാരിക്ക് web-server process-ന്റെ നിയന്ത്രണം ലഭിച്ചേക്കാം. അത് സിസ്റ്റത്തിന്റെ പൂർണ്ണ നിയന്ത്രണത്തിന് തുല്യമാകണമെന്നില്ല. ആക്രമണകാരിക്ക് എന്തിലൊക്കെ പ്രവേശിക്കാൻ കഴിയും എന്നത് Apache പ്രോസസിന് ആക്സസ് ചെയ്യാൻ കഴിയുന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു: ആപ്ലിക്കേഷന്റെ ഡാറ്റ, അതിന് എഴുതാൻ കഴിയുന്ന വെബ്സൈറ്റ് ഫോൾഡറുകൾ, കോൺഫിഗറേഷൻ ഫയലുകളിൽ സൂക്ഷിച്ചിരിക്കുന്ന ക്രെഡൻഷ്യലുകൾ, ആന്തരിക നെറ്റ്‌വർക്കിലെ ഡാറ്റാബേസുകൾ പോലുള്ള ഏതെങ്കിലും ബാക്കെൻഡ് സേവനങ്ങൾ എന്നിവ.

അതുകൊണ്ട്, കുറഞ്ഞ പ്രിവിലേജുള്ള ഉപയോക്താവായി പ്രവർത്തിക്കുന്നതും കൃത്യമായി വേർതിരിച്ചതുമായ (well-isolated) ഒരു സെർവറിലെ ആഘാതം, സിസ്റ്റത്തിലെ എല്ലാ രഹസ്യങ്ങളും വായിക്കാൻ Apache-ന് കഴിയുന്ന ഒരു സെർവറിനെ അപേക്ഷിച്ച് വളരെ കുറവായിരിക്കും. അക്കാര്യം കൂടി പരിശോധിക്കാൻ ഏറ്റവും അനുയോജ്യമായ സമയമാണിത്.

നിങ്ങളുടെ സെർവർ യഥാർത്ഥത്തിൽ അപകടസാധ്യതയിലാണോ?

ഇവിടെയാണ് പല ടീമുകൾക്കും രണ്ട് രീതിയിലും തെറ്റുപറ്റുന്നത്. ഒരു പതിപ്പ് നമ്പർ മാത്രം അപകടത്തിന്റെ തെളിവല്ല, സുരക്ഷിതമായി തോന്നുന്ന ഒരു പബ്ലിക് വെബ്സൈറ്റ് സുരക്ഷിതത്വത്തിന്റെ തെളിവുമല്ല.

മൊഡ്യൂൾ ലോഡ് ചെയ്യുന്നത് കൊണ്ട് മാത്രം കാര്യമില്ല. സേവനം യഥാർത്ഥത്തിൽ HTTP/2 സ്വീകരിക്കുമ്പോൾ മാത്രമേ ഈ സുരക്ഷാ പിഴവുള്ള പാതയിലേക്ക് പ്രവേശിക്കാൻ കഴിയൂ എന്ന് Luxembourg-ന്റെ CIRCL ചൂണ്ടിക്കാണിക്കുന്നു. mod_http2 ലോഡ് ചെയ്തിട്ടുണ്ടെങ്കിലും ഒരു ലിസണറും HTTP/2 നൽകുന്നില്ലെങ്കിൽ, ആ പാതയിലേക്ക് കടക്കാനാവില്ല.

രണ്ട് തരത്തിലുള്ള HTTP/2-ഉം കണക്കിലെടുക്കണം. TLS വഴിയുള്ള എൻക്രിപ്റ്റ് ചെയ്ത HTTP/2-നെ h2എന്നും TLS ഇല്ലാത്ത ക്ലിയർടെക്സ്റ്റ് HTTP/2-നെ h2cഎന്നും വിളിക്കുന്നു. ഏത് ലിസണറിലും ഇവയിൽ ഏതെങ്കിലും ഒന്ന് പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ടെങ്കിലും അത് പ്രധാനമാണ്.

Virtual host-കൾ വ്യത്യാസപ്പെടാം. മുഴുവൻ സെർവറിനുമായി പ്രോട്ടോക്കോളുകൾ സജ്ജീകരിക്കാനും ഓരോ virtual host-നും വെവ്വേറെ സജ്ജീകരിക്കാനും Apache നിങ്ങളെ അനുവദിക്കുന്നു. പ്രധാന കോൺഫിഗറേഷൻ ഫയൽ മാത്രം പരിശോധിച്ചാൽ, സ്വന്തമായി HTTP/2 ഓൺ ചെയ്തിട്ടുള്ള ഒരു സൈറ്റ് ശ്രദ്ധയിൽപ്പെടാതെ പോയേക്കാം.

Proxy-കൾ സ്ഥിതിഗതികളെ മാറ്റുന്നു. ഒരു CDN, ലോഡ് ബാലൻസർ അല്ലെങ്കിൽ റിവേഴ്സ് പ്രോക്സി മുൻപിൽ പ്രവർത്തിക്കുകയും സന്ദർശകരുമായി HTTP/2 ഉപയോഗിക്കുകയും എന്നാൽ Apache-ലേക്ക് HTTP/1.1 മാത്രം ഉപയോഗിക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, പുറത്തുനിന്നുള്ള HTTP/2 സെഷൻ സ്വയം ഈ ബഗ് തുറന്നുകാട്ടുന്നില്ല. എന്നാൽ ഒറിജിൻ സെർവറിലേക്കുള്ള നേരിട്ടുള്ള ആക്സസ്, ഒരു ആന്തരിക ലിസണർ, അല്ലെങ്കിൽ HTTP/2-നെ Apache-ലേക്ക് ഫോർവേഡ് ചെയ്യുന്ന ഒരു പ്രോക്സി എന്നിവ അപകടസാധ്യത ഉണ്ടാക്കും.

ഇത് എന്തുകൊണ്ട് പ്രധാനമാണെന്ന് Rohit-ന്റെ സാഹചര്യം വ്യക്തമാക്കുന്നു. Acme-ന്റെ പ്രധാന വെബ്സൈറ്റ് ഒരു CDN-ന് പിന്നിലാണ്, അതിനാൽ ഒരു പബ്ലിക് സ്കാൻ എല്ലായിടത്തും HTTP/2 കാണിക്കുന്നു. അകത്ത് പരിശോധിച്ചപ്പോൾ അദ്ദേഹം മൂന്ന് സാഹചര്യങ്ങൾ കണ്ടെത്തുന്നു: പ്രധാന സൈറ്റിലെ Apache CDN-ൽ നിന്ന് HTTP/1.1 മാത്രമേ സ്വീകരിക്കുന്നുള്ളൂ, ഒരു ആന്തരിക വിക്കിയിലേക്ക് നേരിട്ട് h2 വഴി എത്താം, കൂടാതെ പഴയൊരു മാർക്കറ്റിംഗ് virtual host സ്വന്തമായി h2c പ്രവർത്തനക്ഷമമാക്കിയിരിക്കുന്നു. ഈ മൂന്നെണ്ണത്തിൽ രണ്ടെണ്ണത്തിന് അടിയന്തിര ശ്രദ്ധ ആവശ്യമാണ്, എന്നാൽ ഒരു പബ്ലിക് സ്കാനിംഗിലൂടെ ഇവയെക്കുറിച്ച് ഒന്നും അറിയാൻ കഴിയില്ലായിരുന്നു.

ഘട്ടം ഘട്ടമായി: Rohit ഇന്ന് എന്താണ് ചെയ്യുന്നത്

ഘട്ടം 1: എല്ലാ Apache സെർവറുകളും അവയുടെ പതിപ്പുകളും കണ്ടെത്തുക

സെർവറുകൾ ലിസ്റ്റ് ചെയ്യുക, തുടർന്ന് ഓരോന്നും പരിശോധിക്കുക. ഡിസ്ട്രിബ്യൂഷൻ അനുസരിച്ച് കമാൻഡ് നാമം വ്യത്യാസപ്പെടുന്നു.

# 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 host-കൾ ഉൾപ്പെടെയുള്ള എല്ലാ കോൺഫിഗറേഷൻ ഫയലുകളിലും പ്രോട്ടോക്കോൾ ക്രമീകരണങ്ങൾക്കായി തിരയുക.

# 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/

പബ്ലിക് വെബ്സൈറ്റിൽ മാത്രമല്ല, ഒറിജിൻ അഡ്രസ്സിലും ആന്തരിക നാമങ്ങളിലും ഇവ റൺ ചെയ്യുക.

ഘട്ടം 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 ആയി പരിമിതപ്പെടുത്തുക. പ്രധാന കോൺഫിഗറേഷനിലും സ്വന്തമായി പ്രോട്ടോക്കോളുകൾ സജ്ജീകരിക്കുന്ന ഓരോ virtual host-ലും ഇത് നൽകുക, ഒപ്പം ഏതെങ്കിലും h2 കൂടാതെ h2c എന്നീ എൻട്രികൾ നീക്കം ചെയ്യുക:

Protocols http/1.1

കോൺഫിഗറേഷൻ സാധൂകരിക്കുക, അത് പ്രയോഗിക്കുക, ഘട്ടം 2-ലെ curl കമാൻഡുകൾ ഉപയോഗിച്ച് വീണ്ടും പരിശോധിക്കുക. നിങ്ങൾക്ക് കാണേണ്ടത് 1.1ആണ്, അല്ലാതെ 2.

apachectl configtest && sudo systemctl reload httpd    # or apache2

Debian, Ubuntu എന്നിവയിൽ നിങ്ങൾക്ക് sudo a2dismod http2ഉപയോഗിച്ച് മൊഡ്യൂൾ പ്രവർത്തനരഹിതമാക്കാം, തുടർന്ന് റീസ്റ്റാർട്ട് ചെയ്യുക. പാച്ചിംഗിന് ശേഷം HTTP/2 തിരികെ വരുന്നത് വരെ ചില സന്ദർശകർക്ക് പേജ് ലോഡ് ചെയ്യുന്നതിൽ ചെറിയ കാലതാമസം ഉണ്ടായേക്കാം.

ഘട്ടം 5: മുമ്പുണ്ടായ പ്രശ്നങ്ങളുടെ ലക്ഷണങ്ങൾ പരിശോധിക്കുക

പാച്ചിംഗ് വഴി വാതിലുകൾ അടയ്ക്കുന്നുണ്ടെങ്കിലും, അതിന് മുമ്പ് ആരെങ്കിലും അതിലൂടെ കടന്നുവന്നിട്ടുണ്ടോ എന്ന് അതുകൊണ്ട് അറിയാൻ കഴിയില്ല. പ്രതീക്ഷിക്കാത്ത Apache worker ക്രാഷുകൾ, അസാധാരണമായ ചൈൽഡ് പ്രോസസുകൾ, വെബ് ഫോൾഡറുകളിൽ അനുമതിയില്ലാതെ സംഭവിച്ച ഫയൽ മാറ്റങ്ങൾ, സെർവറിൽ നിന്നുള്ള അസാധാരണ ഔട്ട്ബൗണ്ട് കണക്ഷനുകൾ എന്നിവ അവലോകനം ചെയ്യാൻ CIRCL നിർദ്ദേശിക്കുന്നു. ഇവയൊന്നും തനിയെ ഒരു ആക്രമണത്തിന്റെ തെളിവല്ലെങ്കിലും, ഓരോന്നും പരിശോധിക്കേണ്ടതുണ്ട്.

ചൂഷണ റിപ്പോർട്ടുകളെക്കുറിച്ച് (Exploit reports)

വിവിധ സ്രോതസ്സുകൾ വ്യത്യസ്ത വിവരങ്ങൾ നൽകുന്നു, അതിനാൽ വാർത്തകൾ ശ്രദ്ധാപൂർവ്വം വായിക്കുക. mod_http2 പ്രവർത്തനക്ഷമമാക്കിയ ഒരു ഡിഫോൾട്ട് സെർവറിനെതിരെ വിശ്വസനീയമായ ചൂഷണം സാധ്യമാണെന്ന് പബ്ലിക് റിസർച്ച് വ്യക്തമാക്കിയതായി Red Hat പറയുന്നു. എന്നാൽ നവംബർ 11-ന് Wiz അറിയിച്ചത് ചൂഷണം (exploit) ഒന്നും ലഭ്യമല്ലെന്നും അക്കാലത്ത് ഇൻ-ദി-വൈൽഡ് (in the wild) ആക്രമണങ്ങളൊന്നും കണ്ടിട്ടില്ലെന്നുമാണ്. ഒരു ഡെമോൺസ്ട്രേഷൻ ഇൻ-ദി-വൈൽഡ് ആക്രമണങ്ങളെ തെളിയിക്കുന്നില്ലെന്ന് CIRCL ചൂണ്ടിക്കാണിക്കുന്നു.

തങ്ങളുടെ സ്വന്തം ഡാറ്റയിലെ 64% ക്ലൗഡ് പരിതസ്ഥിതികളിലും ഈ പിഴവിന് വിധേയമായ റിസോഴ്സുകൾ അടങ്ങിയിട്ടുണ്ടെന്നും Wiz റിപ്പോർട്ട് ചെയ്തു. ആ കണക്ക് Wiz-ന്റെ ഡാറ്റാസെറ്റിനെയാണ് പ്രതിനിധീകരിക്കുന്നത്, അല്ലാതെ ഇന്റർനെറ്റിലെ എല്ലാ Apache സെർവറുകളുടെയും പങ്കിനെയല്ല.

സുരക്ഷിതമായ നിഗമനം: ഈ റിപ്പോർട്ടുകളിൽ സ്ഥിരീകരിച്ച ആക്രമണ ക്യാമ്പെയ്‌നുകളൊന്നും ഇല്ല, എങ്കിലും പ്രവർത്തിക്കുന്ന ഒരു രീതി തെളിയിക്കപ്പെട്ടിട്ടുണ്ട്, അതിനാൽ എത്രയും വേഗം പാച്ച് ചെയ്യുക.

ഇത് ആരാണ് കണ്ടെത്തിയത്, 2.4.71 മറ്റെന്തൊക്കെ പരിഹരിക്കുന്നു

Anthropic-ന്റെ OSS Scanner-നും Google Cloud Vulnerability Research-ലെ Anthony Weems, Simon Scannell എന്നിവർക്കും Apache ക്രെഡിറ്റ് നൽകുന്നു. ഒക്ടോബർ 26-ന് Anthropic-ൽ നിന്നുള്ള റിപ്പോർട്ടും, നവംബർ 3-ന് Google-ൽ നിന്നുള്ള റിപ്പോർട്ടും, നവംബർ 11-ന് ഇതിനുള്ള പരിഹാരവും റിലീസും ടൈംലൈൻ കാണിക്കുന്നു.

പതിപ്പ് 2.4.71 മറ്റ് രണ്ട് ചെറിയ പ്രശ്നങ്ങൾ കൂടി പരിഹരിക്കുന്നു:

• CVE-2026-106023 (Important): 2.4.30 മുതൽ 2.4.70 വരെയുള്ള പതിപ്പുകളിൽ, ഒരു ചൈൽഡ് പ്രോസസ്സ് ക്രാഷ് ചെയ്യാൻ സാധ്യതയുള്ള mod_md-യിലെ null-pointer dereference.
• CVE-2026-109163 (Low): പതിപ്പുകൾ 2.4.69, 2.4.70 എന്നിവയിൽ mod_vhost_alias-ലെ stack-buffer overwrite.

ഉപസംഹാരം

CVE-2026-119618 അതീവ ഗൗരവമുള്ളതാണ്: ലോഗിൻ ആവശ്യമില്ല, നെറ്റ്‌വർക്ക് വഴി പ്രവേശിക്കാം, വെബ് സെർവറിന്റെ നിയന്ത്രണം സാധ്യമാണ്. എന്നാൽ യഥാർത്ഥ അപകടസാധ്യത എന്നത് HTTP/2 അല്ലെങ്കിൽ h2c ലഭ്യമാക്കിയിട്ടുണ്ടോ, നിങ്ങളുടെ വെണ്ടറുടെ പാക്കേജ് എന്താണ്, ട്രാഫിക് Apache-ലേക്ക് എങ്ങനെ എത്തുന്നു എന്നിവയെ ആശ്രയിച്ചിരിക്കുന്നു. എല്ലാ സെർവറുകളും കണ്ടെത്തുക, ഓരോ virtual host-ഉം പരിശോധിക്കുക, 2.4.71-ലേക്ക് അല്ലെങ്കിൽ വെണ്ടറുടെ ഫിക്സിലേക്ക് പാച്ച് ചെയ്യുക, കാത്തിരിക്കേണ്ടി വരുന്നിടത്ത് HTTP/2 ഓഫ് ചെയ്യുക, തുടർന്ന് മുമ്പുണ്ടായ ദുരുപയോഗത്തിന്റെ ലക്ഷണങ്ങൾ പരിശോധിക്കുക.

നേട്ടങ്ങൾ

• പരിഹാരം ഇതിനകം പുറത്തിറങ്ങിയിട്ടുണ്ട്, അതിനാൽ സുരക്ഷിതത്വത്തിലേക്കുള്ള വ്യക്തമായ മാർഗ്ഗമുണ്ട്.
• ഒരു താൽക്കാലിക പരിഹാരമായി ഒറ്റ കോൺഫിഗറേഷൻ വരി ഉപയോഗിച്ച് HTTP/2 ഓഫ് ചെയ്യാൻ കഴിയും.
• RHEL 8-ഉം അതിൽ പഴയ പതിപ്പുകളും ബാധിക്കപ്പെടുന്നില്ല, RHEL 9-ഉം 10-ഉം ചൂഷണം ചെയ്യുന്നത് കൂടുതൽ പ്രയാസകരമാണ്.
• Apache-ലേക്ക് HTTP/1.1 മാത്രം ഉപയോഗിക്കുന്ന ഒരു പ്രോക്സി അപകടസാധ്യത കുറയ്ക്കുന്നു.
• Apache പ്രോസസിന് ആക്സസ് ചെയ്യാൻ കഴിയുന്ന കാര്യങ്ങൾ കർശനമായി നിയന്ത്രിക്കാനുള്ള നല്ലൊരു അവസരമാണ് ഈ പരിശോധന.

പോരായ്മകൾ

• ഈ സുരക്ഷാ പിഴവിന് ലോഗിൻ ആവശ്യമില്ല ഒപ്പം 9.8 സ്കോർ ഉള്ളതുമാണ്, അതിനാൽ എക്സ്പോസ്ഡ് ആയ സെർവറുകൾ യഥാർത്ഥ അപകടസാധ്യതയിലാണ്.
• വെണ്ടർമാർ ബാക്ക്പോർട്ട് ഫിക്സുകൾ നൽകാറുള്ളതിനാൽ പതിപ്പ് സ്ട്രിംഗുകൾ തെറ്റിദ്ധരിപ്പിച്ചേക്കാം.
• ഓരോ virtual host ക്രമീകരണങ്ങളും കാരണം അപകടസാധ്യതയുള്ള ഒരു സൈറ്റ് ശ്രദ്ധയിൽപ്പെടാതെ പോകാൻ സാധ്യതയുണ്ട്.
• HTTP/2 ഓഫാക്കുന്നത് ചില പേജുകൾ ലോഡ് ചെയ്യുന്ന വേഗത അല്പം കുറച്ചേക്കാം.
• പരിഹാരത്തിന് മുമ്പ് ഒരു സെർവർ ആക്രമിക്കപ്പെട്ടിട്ടുണ്ടോ എന്ന് പാച്ചിംഗ് വഴി വെളിപ്പെടുന്നില്ല.

മുന്നറിയിപ്പ്

ഈ ലേഖനം വിദ്യാഭ്യാസ ആവശ്യങ്ങൾക്കുള്ളതാണ്. ഹോസ്റ്റ് പേരുകൾ, IP വിലാസങ്ങൾ, Acme എന്ന കമ്പനിയുടെ പേര് എന്നിവ സാങ്കൽപ്പികമാണ്, അവ നിങ്ങളുടെ സ്വന്തം വിവരങ്ങൾ ഉപയോഗിച്ച് മാറ്റണം. ഡിസ്ട്രിബ്യൂഷനുകളും പതിപ്പുകളും തമ്മിൽ കമാൻഡുകൾ വ്യത്യാസപ്പെടുന്നു, അതിനാൽ നിങ്ങളുടെ വെണ്ടറുടെ അഡ്വൈസറി വായിക്കുകയും ആദ്യം നോൺ-പ്രൊഡക്ഷൻ സെർവറിൽ മാറ്റങ്ങൾ പരിശോധിക്കുകയും ചെയ്യുക. ചൂഷണങ്ങളെക്കുറിച്ചും ബാധിച്ച ശ്രേണികളെക്കുറിച്ചുമുള്ള വിവരങ്ങൾ ഇവിടെ സംഗ്രഹിച്ചിരിക്കുന്ന വെണ്ടർ, ഗവേഷക പ്രസ്താവനകളിൽ നിന്നുള്ളതാണ്, അവ മാറിയേക്കാം, അതിനാൽ അവയെ ആശ്രയിക്കുന്നതിന് മുമ്പ് ഔദ്യോഗിക Apache, വെണ്ടർ അഡ്വൈസറികളുമായി താരതമ്യം ചെയ്ത് സ്ഥിരീകരിക്കുക.

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

• എന്താണ് CVE-2026-119618? — പ്രാമാണീകരണമില്ലാതെ (without authentication) റിമോട്ട് കോഡ് എക്സിക്യൂഷൻ സാധ്യമാക്കുന്ന Apache HTTP Server-ന്റെ HTTP/2 മൊഡ്യൂളിലെ അതീവ ഗുരുതരമായ ഒരു മെമ്മറി-കറപ്ഷൻ പിഴവാണിത്.
• ഏതൊക്കെ Apache പതിപ്പുകളെയാണ് ബാധിക്കുന്നത്? — Apache HTTP Server 2.4.55 മുതൽ 2.4.70 വരെ, ഒപ്പം പ്രത്യേക mod_h2 മൊഡ്യൂൾ പതിപ്പുകൾ 2.0.8 മുതൽ 2.0.42 വരെ.
• ഏത് പതിപ്പാണ് ഇത് പരിഹരിക്കുന്നത്? — 2026 നവംബർ 11-ന് പുറത്തിറങ്ങിയ Apache HTTP Server 2.4.71, അല്ലെങ്കിൽ ഈ പരിഹാരം വ്യക്തമായി ഉൾപ്പെടുത്തിയിട്ടുള്ള ഒരു വെണ്ടർ പാക്കേജ്.
• mod_http2 ലോഡ് ചെയ്തിട്ടുണ്ടെങ്കിലും HTTP/2 പ്രവർത്തനക്ഷമമാക്കിയിട്ടില്ലെങ്കിൽ എന്റെ സെർവർ സുരക്ഷിതമാണോ? — സുരക്ഷാ പിഴവുള്ള പാതയിലേക്ക് പ്രവേശിക്കാൻ സർവീസ് HTTP/2 സ്വീകരിക്കേണ്ടതുണ്ട്, അതിനാൽ ഒരു ലിസണറിലും h2 അല്ലെങ്കിൽ h2c നൽകാത്ത ഒരു സെർവറിലേക്ക് ഈ പിഴവിലൂടെ പ്രവേശിക്കാൻ കഴിയില്ല.
• ഒരു CDN അല്ലെങ്കിൽ ലോഡ് ബാലൻസറിന് പിന്നിൽ ഞാൻ സുരക്ഷിതനാണോ? — പ്രോക്സി Apache-ലേക്ക് HTTP/1.1 സംസാരിക്കുകയും ആർക്കും ഒറിജിൻ സെർവറിലേക്ക് നേരിട്ട് HTTP/2 വഴി പ്രവേശിക്കാൻ കഴിയാത്ത അവസ്ഥയിലാണെങ്കിൽ മാത്രം.
• ഇത് RHEL-നെ ബാധിക്കുന്നുണ്ടോ? — RHEL 8-ഉം അതിനുമുമ്പുള്ള പതിപ്പുകളും ബാധിക്കപ്പെടുന്നില്ല; RHEL 9-ഉം 10-ഉം Important എന്ന് റേറ്റുചെയ്തിരിക്കുന്നു, ഒപ്പം Red Hat-ന്റെ അപ്‌ഡേറ്റുകൾ പ്രയോഗിക്കുകയും വേണം.
• Apache-ൽ HTTP/2 താൽക്കാലികമായി എങ്ങനെ പ്രവർത്തനരഹിതമാക്കാം? — പ്രധാന കോൺഫിഗറേഷനിലും ഓരോ virtual host-ലും Protocols http/1.1 എന്ന് സജ്ജീകരിക്കുക, കോൺഫിഗറേഷൻ ടെസ്റ്റ് നടത്തുക, തുടർന്ന് Apache റീലോഡ് ചെയ്യുക.
• ഈ സുരക്ഷാ പിഴവ് വ്യാപകമായി (in the wild) ചൂഷണം ചെയ്യപ്പെടുന്നുണ്ടോ? — ഇവിടെ പരാമർശിച്ചിരിക്കുന്ന റിപ്പോർട്ടുകൾ ഒരു പബ്ലിക് ഡെമോൺസ്ട്രേഷൻ വിവരിക്കുന്നുണ്ടെങ്കിലും ഇൻ-ദി-വൈൽഡ് ആക്രമണങ്ങളൊന്നും സ്ഥിരീകരിച്ചിട്ടില്ല, അതിനാൽ ഒരു ക്യാമ്പെയ്ൻ ഉണ്ടെന്ന് അനുമാനിക്കാതെ വേഗത്തിൽ പാച്ച് ചെയ്യുക.

ടാഗുകൾ

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