Apache HTTP/2 खामी CVE-2026-119618: अपने सर्वरों की जांच कैसे करें और 2.4.71 पर पैच कैसे करें

HTTP/2 का उपयोग करने वाले वेब सर्वर पर किसी भी अजनबी द्वारा बिना लॉगिन किए नियंत्रण किया जा सकता है। यह CVE-2026-119618 के पीछे का जोखिम है, जो Apache HTTP Server के HTTP/2 मॉड्यूल में एक गंभीर खामी है, और इसका समाधान पहले ही जारी किया जा चुका है।

आज 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 प्रक्रिया कहाँ तक पहुँच सकती है: एप्लिकेशन का डेटा, वेबसाइट फ़ोल्डर जिनमें यह लिख सकती है, कॉन्फ़िग फ़ाइलों में संग्रहीत क्रेडेंशियल, और आंतरिक नेटवर्क पर डेटाबेस जैसी कोई भी बैकएंड सेवाएँ।

इसलिए कम-विशेषाधिकार वाले उपयोगकर्ता के रूप में चलने वाले अच्छी तरह से अलग-थलग सर्वर पर नुकसान उस सर्वर की तुलना में कम होता है जहाँ Apache सिस्टम के हर रहस्य को पढ़ सकता है। इसकी भी जांच करने का यह एक अच्छा समय है।

क्या आपका सर्वर वास्तव में इसके जोखिम में है?

यहीं पर कई टीमें दोनों दिशाओं में गलती करती हैं। केवल एक संस्करण संख्या खतरे का प्रमाण नहीं है, और सुरक्षित दिखने वाली सार्वजनिक वेबसाइट सुरक्षा का प्रमाण नहीं है।

केवल मॉड्यूल लोड करना पर्याप्त नहीं है। लक्ज़मबर्ग का CIRCL नोट करता है कि संवेदनशील पथ केवल तभी पहुँच योग्य होता है जब सेवा वास्तव में HTTP/2 स्वीकार करती है। यदि mod_http2 लोड है लेकिन कोई लिसनर HTTP/2 की पेशकश नहीं करता है, तो वह पथ पहुँच योग्य नहीं है।

HTTP/2 के दोनों प्रकार मायने रखते हैं। TLS पर एन्क्रिप्टेड HTTP/2 को कहा जाता है h2। बिना TLS वाले क्लियरटेक्स्ट HTTP/2 को कहा जाता है h2c। किसी भी लिसनर पर दोनों में से किसी एक का भी सक्षम होना मायने रखता है।

वर्चुअल होस्ट भिन्न हो सकते हैं। Apache आपको पूरे सर्वर के लिए और फिर प्रत्येक वर्चुअल होस्ट के लिए प्रोटोकॉल सेट करने की अनुमति देता है। केवल मुख्य कॉन्फ़िग फ़ाइल की समीक्षा करने से ऐसी साइट छूट सकती है जो स्वयं HTTP/2 चालू करती है।

प्रॉक्सी स्थिति बदल देते हैं। यदि कोई CDN, लोड बैलेंसर या रिवर्स प्रॉक्सी आगे मौजूद है और आगंतुकों से HTTP/2 में बात करता है लेकिन Apache से केवल HTTP/1.1 में बात करता है, तो बाहरी HTTP/2 सत्र अपने आप में इस बग को उजागर नहीं करता है। लेकिन मूल सर्वर तक सीधी पहुँच, एक आंतरिक लिसनर, या एक प्रॉक्सी जो HTTP/2 को Apache पर अग्रेषित करती है, वह इसे उजागर कर देगी।

रोहित की स्थिति दर्शाती है कि यह क्यों मायने रखता है। Acme की मुख्य वेबसाइट CDN के पीछे है, इसलिए सार्वजनिक स्कैन में हर जगह HTTP/2 दिखता है। आंतरिक रूप से, उसे तीन मामले मिलते हैं: मुख्य साइट का Apache केवल CDN से HTTP/1.1 प्राप्त करता है, एक आंतरिक विकी तक सीधे h2 पर पहुँचा जाता है, और एक पुराना मार्केटिंग वर्चुअल होस्ट अपने दम पर h2c को सक्षम करता है। तीनों में से दो पर तत्काल काम करने की आवश्यकता है, और सार्वजनिक स्कैन से उसे इनके बारे में कुछ भी पता नहीं चलता।

चरण-दर-चरण: रोहित आज क्या करता है

चरण 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 वास्तव में पेश किया जा रहा है

पहले देखें कि क्या मॉड्यूल लोड है, फिर वर्चुअल होस्ट सहित प्रत्येक कॉन्फ़िग फ़ाइल में प्रोटोकॉल सेटिंग्स खोजें।

# 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 तक सीमित करें। इसे मुख्य कॉन्फ़िग में और प्रत्येक वर्चुअल होस्ट में रखें जो अपने स्वयं के प्रोटोकॉल सेट करता है, और किसी भी 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: पहले हुई गड़बड़ी के संकेतों की तलाश करें

पैचिंग दरवाज़ा बंद कर देती है, लेकिन यह आपको यह नहीं बताती कि क्या कोई पहले इसके अंदर आया था। CIRCL अप्रत्याशित Apache वर्कर क्रैश, अजीब चाइल्ड प्रोसेस, वेब फ़ोल्डरों में अनधिकृत फ़ाइल परिवर्तन, और सर्वर से असामान्य आउटबाउंड कनेक्शन की समीक्षा करने का सुझाव देता है। इनमें से कोई भी अपने दम पर किसी हमले को साबित नहीं करता है, लेकिन प्रत्येक की जांच की जानी चाहिए।

शोषण रिपोर्टों के बारे में

स्रोतों में असहमति है, इसलिए सुर्खियों को ध्यान से पढ़ें। Red Hat का कहना है कि सार्वजनिक शोध ने mod_http2 सक्षम वाले एक डिफ़ॉल्ट सर्वर के खिलाफ विश्वसनीय शोषण दिखाया है। 11 नवंबर को Wiz ने कहा कि कोई शोषण उपलब्ध नहीं था और उस समय तक वास्तविक परिवेश में कोई हमला नहीं देखा गया था। 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 में एक नल-पॉइंटर डिरेफ़्रेंस जो 2.4.30 से 2.4.70 तक के संस्करणों में एक चाइल्ड प्रोसेस को क्रैश कर सकता है।
• CVE-2026-109163 (Low): mod_vhost_alias में एक स्टैक-बफ़र ओवरराइट, संस्करण 2.4.69 और 2.4.70 में।

निष्कर्ष

CVE-2026-119618 गंभीर है: कोई लॉगिन नहीं, नेटवर्क से पहुँच योग्य, वेब सर्वर पर संभावित नियंत्रण। लेकिन वास्तविक जोखिम इस बात पर निर्भर करता है कि क्या HTTP/2 या h2c की पेशकश की गई है, आपके वेंडर के पैकेज पर, और ट्रैफ़िक Apache तक कैसे पहुँचता है। प्रत्येक सर्वर का पता लगाएं, प्रत्येक वर्चुअल होस्ट की जांच करें, 2.4.71 या वेंडर के समाधान पर पैच करें, जहाँ आपको प्रतीक्षा करनी हो वहाँ HTTP/2 को बंद कर दें, और फिर पहले के दुरुपयोग के संकेतों की तलाश करें।

फायदे

• समाधान पहले ही जारी किया जा चुका है, इसलिए सुरक्षा का एक स्पष्ट मार्ग मौजूद है।
• एक अस्थायी उपाय के रूप में केवल एक कॉन्फ़िग लाइन के साथ HTTP/2 को बंद किया जा सकता है।
• RHEL 8 और पुराने संस्करण प्रभावित नहीं हैं, और RHEL 9 तथा 10 का शोषण करना अधिक कठिन है।
• एक प्रॉक्सी जो Apache से केवल HTTP/1.1 में बात करती है, जोखिम को कम करती है।
• यह समीक्षा इस बात को नियंत्रित करने का एक अच्छा अवसर है कि Apache प्रक्रिया क्या एक्सेस कर सकती है।

नुकसान

• इस खामी के लिए किसी लॉगिन की आवश्यकता नहीं है और इसका स्कोर 9.8 है, इसलिए असुरक्षित सर्वर वास्तविक जोखिम में हैं।
• संस्करण स्ट्रिंग भ्रामक हो सकती हैं क्योंकि वेंडर समाधानों को बैकपोर्ट करते हैं।
• प्रत्येक-वर्चुअल-होस्ट सेटिंग्स के कारण किसी एक असुरक्षित साइट के छूट जाने की संभावना बढ़ जाती है।
• HTTP/2 को बंद करने से कुछ पेज थोड़े धीमे लोड हो सकते हैं।
• पैचिंग से यह पता नहीं चलता कि समाधान से पहले सर्वर पर हमला हुआ था या नहीं।

सावधानी

यह लेख शैक्षणिक उद्देश्यों के लिए है। होस्ट नाम, IP पते और कंपनी का नाम Acme प्लेसहोल्डर हैं और इन्हें आपके अपने विवरणों से बदला जाना चाहिए। कमांड विभिन्न डिस्ट्रीब्यूशन और संस्करणों के बीच भिन्न होते हैं, इसलिए अपने वेंडर की एडवाइजरी पढ़ें और पहले गैर-उत्पादन सर्वर पर परिवर्तनों का परीक्षण करें। शोषण और प्रभावित श्रेणियों के बारे में दावे यहाँ संक्षेपित वेंडर और शोधकर्ताओं के बयानों से आते हैं और बदल सकते हैं, इसलिए उन पर निर्भर होने से पहले आधिकारिक Apache और वेंडर एडवाइजरी के साथ उन्हें सत्यापित करें।

अक्सर पूछे जाने वाले प्रश्न

• CVE-2026-119618 क्या है? — यह Apache HTTP Server के HTTP/2 मॉड्यूल में एक गंभीर मेमोरी-करप्शन खामी है जो बिना प्रमाणीकरण के रिमोट कोड निष्पादन की अनुमति दे सकती है।
• 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 या लोड बैलेंसर के पीछे सुरक्षित हूँ? — केवल तभी जब प्रॉक्सी Apache से HTTP/1.1 में बात करती है और कोई भी सीधे HTTP/2 पर मूल सर्वर तक नहीं पहुँच सकता है।
• क्या RHEL प्रभावित है? — RHEL 8 और पुराने संस्करण प्रभावित नहीं हैं; RHEL 9 और 10 को Important रेट किया गया है और उन्हें Red Hat के अपडेट लागू करने चाहिए।
• मैं Apache में अस्थायी रूप से HTTP/2 को कैसे अक्षम करूँ? — सेट करें Protocols http/1.1 मुख्य कॉन्फ़िग और प्रत्येक वर्चुअल होस्ट में, एक कॉन्फ़िग परीक्षण चलाएँ, फिर Apache को रीलोड करें।
• क्या वास्तविक परिवेश में इस खामी का शोषण किया जा रहा है? — यहाँ उद्धृत रिपोर्टें एक सार्वजनिक प्रदर्शन का वर्णन करती हैं, लेकिन वास्तविक परिवेश में किसी पुष्ट हमले का नहीं, इसलिए किसी अभियान को माने बिना इसे शीघ्रता से पैच करें।

टैग

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