CVE-2026-41940 — cPanel & WHM पूर्व-प्रमाणीकरण रूट बायपास: सत्र-फ़ाइल CRLF इंजेक्शन

रक्षक-केंद्रित तकनीकी गहराई से समझना

1. कार्यकारी सारांश

cPanel और WHM साझा और पुनर्विक्रेता वेब होस्टिंग के लिए प्रमुख नियंत्रण-पैनल सॉफ्टवेयर है। cPanel ग्राहक-मुखी खाता इंटरफ़ेस है; WHM होस्टिंग प्रदाताओं और सर्वर मालिकों द्वारा उपयोग किया जाने वाला रूट-स्तरीय प्रशासनिक इंटरफ़ेस है। दोनों एक ही Perl डेमॉन, cpsrvd द्वारा प्रदान किए जाते हैं, जो प्रत्येक सतह के लिए युग्मित पोर्ट पर सुनता है (cPanel: 2082/2083, WHM: 2086/2087, वेबमेल: 2095/2096)।

CVE-2026-41940 एक हमलावर को बिना किसी क्रेडेंशियल के प्रमाणीकरण होने से पहले डिस्क पर सत्र की स्थिति में हेरफेर करने की अनुमति देता है, जिससे cpsrvd बाद में हमलावर द्वारा प्रदान किए गए डेटा को वैध, पूर्णतः प्रमाणित, रूट-विशेषाधिकार प्राप्त सत्र विशेषताओं के रूप में पुनर्व्याख्यायित करता है। परिणाम बॉक्स पर होस्ट की गई प्रत्येक वेबसाइट और खाते के प्रबंधन तल का पूर्ण समझौता है — यह एकल-किरायेदार मुद्दा नहीं, बल्कि होस्ट-व्यापी, प्रदाता-व्यापी, और कुल मिलाकर उद्योग-व्यापी मुद्दा है, cPanel की बाजार एकाग्रता को देखते हुए।

2. यह भेद्यता अपने CVSS स्कोर से अधिक क्यों मायने रखती है

9.8 का CVSS स्कोर इतना सामान्य है कि इसे पढ़ते हुए बेहोशी आ सकती है। तीन संरचनात्मक कारक CVE-2026-41940 को व्यवहार में असामान्य रूप से गंभीर बनाते हैं:

1. विस्फोट त्रिज्या पूरे सर्वर की है, किसी खाते की नहीं। WHM समझौता रूट समझौता है। उस सर्वर पर हर ग्राहक खाता, हर डेटाबेस, हर TLS निजी कुंजी, हर बैकअप, और हर DNS ज़ोन तुरंत दायरे में आ जाता है।

2. यह लगभग दो महीने तक एक वास्तविक जीरो-डे था। KnownHost के टेलीमेट्री के अनुसार प्रारंभिक शोषण लगभग 23 फरवरी, 2026 से शुरू हुआ, जो 28 अप्रैल के पैच से काफी पहले है। कोई भी संगठन जो उस अवधि के दौरान इंटरनेट-एक्सपोज़्ड था, उसे समझौता संभावित मानना चाहिए, न कि केवल सैद्धांतिक, और उसे पूर्वव्यापी समझौता आकलन करना चाहिए न कि "हमने पैच कर लिया, इसलिए हम सुरक्षित हैं" पर निर्भर रहना चाहिए।

3. अधिकांश प्रभावित संगठन स्वयं इसे पैच नहीं कर सकते। cPanel आमतौर पर होस्टिंग प्रदाताओं द्वारा किरायेदारों की ओर से तैनात किया जाता है। अंतिम ग्राहकों का फिक्स पर कोई कोड-स्तरीय नियंत्रण नहीं होता और वे पूरी तरह से अपने प्रदाता की पैच गति पर निर्भर होते हैं — यही कारण है कि कई प्रमुख होस्ट (Namecheap, KnownHost, HostPapa, InMotion) ने हर किरायेदार के अपडेट करने की प्रतीक्षा करने के बजाय प्रभावित पोर्ट पर इनबाउंड ट्रैफ़िक को पूर्व-प्रतिबंधित करना चुना।

यह तीसरा बिंदु ध्यान देने योग्य है। cPanel का नियंत्रण-पैनल बाजार में अनुमानित 94% हिस्सा है। एक विक्रेता के सत्र-हैंडलिंग कोड में एक एकल तर्क दोष, कुछ हफ्तों की अवधि के लिए, एक वास्तविक उद्योग-व्यापी रूट-एक्सेस भेद्यता बन गया। यह एकाग्रता जोखिम एक आवर्ती विषय है जिसे इस विशिष्ट CVE से स्वतंत्र रूप से आत्मसात किया जाना चाहिए।

3. आर्किटेक्चरल पृष्ठभूमि

3.1 cpsrvd और पोर्ट मॉडल

cpsrvd एक लंबे समय तक चलने वाला Perl डेमॉन है जो तीनों cPanel उत्पाद सतहों को एक ही बाइनरी और, महत्वपूर्ण रूप से, एक ही सत्र-हैंडलिंग कोड पथ से प्रदान करता है:

चूंकि तीनों सतहें कमजोर सत्र तर्क साझा करती हैं, इन छह पोर्टों में से किसी एक का एक्सपोज़र शोषण के लिए पर्याप्त है — उनमें कोई भी अर्थपूर्ण रूप से "कम एक्सपोज़्ड" सतह नहीं है। अच्छी तरह से विभाजित वातावरणों में, इनमें से कोई भी पोर्ट सीधे इंटरनेट-पहुंच योग्य नहीं होना चाहिए; व्यवहार में, प्रबंधन सुविधा, हाइब्रिड होस्टिंग व्यवस्थाएं, और फ़ायरवॉल बहाव का मतलब है कि कई थे।

3.2 दोहरा सत्र प्रतिनिधित्व

cPanel सत्र दो समानांतर ऑन-डिस्क प्रतिनिधित्व में बने रहते हैं, जाहिरा तौर पर प्रदर्शन कारणों से:

1. रॉ सत्र फ़ाइल (/var/cpanel/sessions/raw/<session-id>) — एक पंक्ति-उन्मुख, सादा-पाठ key=value प्रारूप, प्रति पंक्ति एक गुण।
2. JSON कैश (/var/cpanel/sessions/cache/<session-id>, अवधारणात्मक रूप से) — एक संरचित JSON दस्तावेज़, जिसे सामान्य अनुरोध पथ द्वारा प्राथमिकता से पढ़ा जाता है क्योंकि इसे पार्स करना सस्ता है।

सामान्य संचालन के तहत, JSON कैश आधिकारिक होता है और रॉ फ़ाइल एक स्थायित्व बैकस्टॉप है। भेद्यता ठीक इसलिए मौजूद है क्योंकि ऐसी परिस्थितियाँ हैं जिनके तहत रॉ फ़ाइल को पुनः पार्स किया जाता है और JSON कैश को पुनर्जीवित करने के लिए उपयोग किया जाता है, और दोनों प्रारूप इस बात पर असहमत हैं कि एक एम्बेडेड न्यूलाइन वर्ण का क्या अर्थ है।

4. मूल कारण: चार स्वतंत्र विफलताएँ जो एक श्रृंखला बनाती हैं

CVE-2026-41940 एक एकल गलती नहीं है। यह चार अलग-अलग कमजोरियों का उत्पाद है, जिनमें से प्रत्येक व्यक्तिगत रूप से एक पृथक डिज़ाइन निर्णय के रूप में प्रशंसनीय है, जो एक पूर्ण प्रमाणीकरण बायपास उत्पन्न करने के लिए संरेखित होते हैं। यह "स्विस चीज़" संरचना रक्षकों और कोड समीक्षकों के लिए इस विशिष्ट उत्पाद से परे शिक्षाप्रद है।

4.1 परत 1 — परंपरा द्वारा लागू स्वच्छता, स्वयं लेखन पथ द्वारा नहीं

cPanel के सत्र सबसिस्टम में पहले से ही एक स्वच्छता दिनचर्या थी जो सत्र मानों से खतरनाक वर्णों — कैरिज रिटर्न, लाइन फीड, और = — को हटाने के लिए जिम्मेदार थी। समस्या यह है कि उस दिनचर्या को कहाँ से आहूत किया गया था: यह उच्च-स्तरीय रैपर फ़ंक्शन (सत्र "बनाएँ"/"संशोधित करें" API) के अंदर रहता था, और सत्र डेटा को सीधे लिखने के बजाय उन रैपरों के माध्यम से रूट करना कॉलर की जिम्मेदारी थी।

cpsrvd के अंदर HTTP बेसिक ऑथेंटिकेशन हैंडलर — कोड पथ जो सीधे Authorization HTTP हेडर से क्रेडेंशियल स्वीकार करता है — ने सबमिट किए गए पासवर्ड को एक निचले-स्तरीय सेव रूटीन के माध्यम से पूर्व-प्रमाणीकरण सत्र फ़ाइल में संग्रहीत किया जो स्वच्छता रैपर को पूरी तरह से बायपास करता था। क्योंकि स्वच्छता डिस्क पर लिखने के बिंदु पर अनिवार्य होने के बजाय ऑप्ट-इन थी, इस एक कॉलर ने चुपचाप इसे छोड़ दिया।

यह "स्रोत पर मान्य करें, सिंक पर नहीं" की पाठ्यपुस्तक विफलता मोड है: जब तक एक सुरक्षा नियंत्रण को एक अलग फ़ंक्शन को कॉल करके बायपास किया जा सकता है, तब तक यह अंततः किया जाएगा, चाहे वह देखरेख, रिफैक्टरिंग, या एक कोड पथ के माध्यम से हो जिसे किसी ने इस विशिष्ट नियंत्रण के खिलाफ ऑडिट करने के बारे में नहीं सोचा था। cPanel द्वारा भेजा गया स्थायी फिक्स स्वच्छता कॉल को सेव फ़ंक्शन के अंदर ही ले जाता है, ताकि इसे अब किसी भी कॉलर, वर्तमान या भविष्य, द्वारा छोड़ा नहीं जा सके।

4.2 परत 2 — एन्क्रिप्शन जिसे हमलावर-नियंत्रित इनपुट अक्षम कर सकता है

सत्र लेखक संवेदनशील फ़ील्ड (विशेष रूप से पासवर्ड फ़ील्ड) को प्रति-सत्र सममित कुंजी का उपयोग करके एन्क्रिप्ट करता है। वह कुंजी ग्राहक द्वारा प्रस्तुत सत्र कुकी में एम्बेडेड एक घटक से प्राप्त होती है। कमजोर कोड में, यदि वह कुंजी घटक अनुरोध से अनुपस्थित था — कुछ पूरी तरह से हमलावर के नियंत्रण में, क्योंकि वे चुनते हैं कि कौन सी कुकी भेजनी है — तो एन्क्रिप्शन चरण को लिखने से मना करने के बजाय चुपचाप छोड़ दिया गया था।

दूसरे शब्दों में: एक हमलावर जो जानबूझकर अपने सत्र कुकी के एक भाग को छोड़ता या काटता है, वह अपने स्वयं के सबमिट किए गए डेटा को डिस्क पर अनएन्क्रिप्टेड लिख सकता है। जिस एन्क्रिप्शन का सक्रियण अविश्वसनीय पक्ष द्वारा इनपुट प्रदान करने के आधार पर बंद किया जा सकता है, वह एक सार्थक सुरक्षा सीमा नहीं है; इसे बंद विफल होना चाहिए (बनाए रखने से मना करें, या अनुरोध को अस्वीकार करें) बजाय खुला विफल होने (बिना सुरक्षा के बनाए रखना) के।

4.3 परत 3 — रॉ फ़ाइल और JSON कैश के बीच प्रारूप असहमति

यह CRLF इंजेक्शन में "इंजेक्शन" का मूल है। रॉ सत्र फ़ाइल पंक्ति-सीमांकित है: एक कैरिज रिटर्न / लाइन फीड अनुक्रम एक key=value रिकॉर्ड को समाप्त करता है और अगला शुरू करता है। इसके विपरीत, JSON कैश प्रारूप उसी वर्ण अनुक्रम को एक एकल JSON स्ट्रिंग मान के अंदर एक एस्केप्ड उपस्ट्रिंग के रूप में दर्शाता है — शब्दार्थ रूप से निष्क्रिय, सिर्फ डेटा।

जब तक एक सत्र केवल JSON कैश में मौजूद है, तब तक पासवर्ड जैसे फ़ील्ड में एक एम्बेडेड CRLF हानिरहित है — यह एक स्ट्रिंग के अंदर सिर्फ बाइट्स है। खतरा उस कोड पथ में दिखाई देता है जो रॉ फ़ाइल को पुनः पार्स करता है और कैश को पुनर्जीवित करता है। यह, सार्वजनिक तकनीकी विश्लेषणों के अनुसार, तब होता है जब एक अनुरोध URL-बाउंड सुरक्षा-टोकन जांच में विफल रहने के लिए अस्वीकार कर दिया जाता है; उस अस्वीकृति के लिए जिम्मेदार हैंडलर कैश को बायपास करके और रॉ फ़ाइल को पंक्ति-दर-पंक्ति पुनः पढ़कर सत्र को पुनः लोड करता है, फिर उस पुनः-पार्स से JSON कैश को फिर से लिखता है।

उस क्षण में, हमलावर द्वारा अपने सबमिट किए गए "पासवर्ड" में एम्बेड किए गए CRLF अनुक्रम एक फ़ील्ड के अंदर निष्क्रिय बाइट्स नहीं रह जाते हैं और रिकॉर्ड विभाजक बन जाते हैं, जो एक एकल मान को कई स्वतंत्र key=value पंक्तियों में विभाजित करता है। उनमें से प्रत्येक पंक्ति — जिसमें वे पंक्तियाँ भी शामिल हैं जिनके नाम और मान को हमलावर पूरी तरह से नियंत्रित करता है — को फिर पुनर्जीवित JSON सत्र कैश में एक शीर्ष-स्तरीय प्रविष्टि के रूप में पदोन्नत किया जाता है, जो कोडबेस के बाकी हिस्सों के लिए एक वैध रूप से निर्धारित सत्र विशेषता से अप्रभेद्य है।

सामान्य सबक: जब भी दो पार्सर समान बाइट अनुक्रम को अलग-अलग व्याख्या कर सकते हैं — रॉ बनाम कैश, फॉर्म-एन्कोडेड बनाम JSON, एक एस्केपिंग परिपाटी बनाम दूसरी — वह असहमति एक गुप्त इंजेक्शन प्रिमिटिव है। इससे कोई फर्क नहीं पड़ता कि कौन सा पार्सर "अधिक सही" है; मायने यह रखता है कि अविश्वसनीय डेटा दूसरे पार्सर के व्याकरण के विरुद्ध पुनः मान्य किए बिना दो प्रतिनिधित्वों के बीच पार कर सकता है।

4.4 परत 4 — बिना किसी क्रिप्टोग्राफिक बाइंडिंग के एक "पहले से प्रमाणित" फ़्लैग

श्रृंखला में अंतिम कड़ी पासवर्ड-जांच तर्क में ही है। यदि एक सत्र में पहले से ही एक फ़ील्ड है जो एक हालिया सफल आंतरिक प्रमाणीकरण टाइमस्टैम्प रिकॉर्ड करता है, तो पासवर्ड चुनौती को पूरी तरह से छोड़ दिया जाता है — उस फ़ील्ड की उपस्थिति अकेले ही यह साबित करने के लिए पर्याप्त मानी जाती है कि प्रमाणीकरण पहले ही सफल हो चुका है। एक साथी दो-कारक-सत्यापित फ़्लैग समान रूप से केवल अपनी उपस्थिति के आधार पर 2FA चुनौती को दबा देता है।

दोनों फ़ील्ड वैध आंतरिक उद्देश्यों के लिए मौजूद हैं (cPanel घटकों के बीच सिंगल साइन-ऑन हैंड-ऑफ, आंतरिक उपकरण जिन्होंने पहले से ही किसी अन्य माध्यम से एक उपयोगकर्ता को मान्य किया है)। डिज़ाइन दोष यह है कि कोई भी फ़ील्ड किसी वास्तविक प्रमाणीकरण घटना से क्रिप्टोग्राफिक रूप से बंधी नहीं है — वे सादे सत्र विशेषताएँ हैं, जिन्हें एक बार परत 3 हमलावर को मनमानी सत्र विशेषताओं को लिखने की अनुमति देती है, आसानी से जाली बनाया जा सकता है। एक फ़्लैग जिसका अर्थ है "मुझ पर भरोसा करो, यह पहले ही जाँचा जा चुका है" केवल तभी सार्थक है जब इसे भरोसा किए जा रहे पक्ष द्वारा सेट नहीं किया जा सकता है।

4.5 सम्मिलित प्रभाव

इन चारों कमजोरियों में से कोई भी स्वतंत्र रूप से विनाशकारी नहीं है:

• एक गुम स्वच्छता कॉल एक गुप्त बग है जब तक कि कोई चीज़ दूषित डेटा को लिखे जाने से अलग पढ़ती है।
• गुम-कुंजी पर एन्क्रिप्शन-छोड़ना एक गोपनीयता चिंता है जब तक कि सादा पाठ सामग्री स्वयं शोषक न हो जाए।
• एक दोहरा-प्रतिनिधित्व प्रारूप बेमेल तब तक निष्क्रिय है जब तक कि कोई चीज़ एक प्रतिनिधित्व को दूसरे से पुनः व्युत्पन्न नहीं करती।
• एक अप्रमाणित-विश्वास फ़्लैग तब तक सुरक्षित है जब तक कि कुछ और हमलावर को इसे सेट करने न दे।

एक साथ जुड़कर, वे एक पूर्ण, बिना प्रमाणीकरण के, दूरस्थ रूट समझौता उत्पन्न करते हैं। यह ठीक उस प्रकार की भेद्यता है जिसे व्यक्तिगत फ़ंक्शन तक सीमित इकाई परीक्षण पकड़ नहीं पाएंगे, क्योंकि अलगाव में कोई भी एक फ़ंक्शन "गलत" नहीं है — दोष उन उपप्रणालियों के बीच परस्पर क्रिया में रहता है जिनके बारे में प्रत्येक को स्वतंत्र रूप से तर्क दिया गया था।

5. अवधारणात्मक आक्रमण प्रवाह

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

चरण 5 से आगे, एक हमलावर के पास सामान्य, पूरी तरह से अधिकृत WHM API पहुंच होती है। WHM का वैध फीचर सेट — कस्टम हुक, पैकेज/टेम्पलेट प्रबंधन, PHP हैंडलर कॉन्फ़िगरेशन, क्रॉन और खाता प्रबंधन, DNS ज़ोन संपादन — पूरी तरह से "समर्थित" प्रशासनिक कार्यक्षमता के माध्यम से इसे इंटरैक्टिव रूट कोड निष्पादन में बढ़ाने के लिए पर्याप्त है, किसी और भेद्यता की आवश्यकता नहीं है।

सार्वजनिक रिपोर्टिंग नोट करती है कि अंत-से-अंत श्रृंखला के लिए केवल थोड़ी संख्या में HTTP अनुरोधों की आवश्यकता होती है और इसमें कैश पुनर्जनन के दौरान Perl के गैर-नियतात्मक हैश कुंजी क्रम के आसपास एक सौम्य दौड़ की स्थिति शामिल होती है — जिसका अर्थ है कि पूर्ण विश्वसनीयता के लिए थोड़ी संख्या में पुनर्प्रयासों की आवश्यकता हो सकती है, एक विवरण जिसका पता लगाने का मूल्य है (§7.3 देखें)।

6. समयरेखा

7. पता लगाने की इंजीनियरिंग

7.1 फ़ाइलसिस्टम-आधारित संकेतक (उच्चतम संकेत)

सबसे मजबूत सबूत स्वयं रॉ सत्र भंडार में रहता है, /var/cpanel/sessions/raw/। एक सत्र जो एक असफल या गैर-विशेषाधिकार प्राप्त लॉगिन से उत्पन्न हुआ है, उसमें कभी भी वैध रूप से निम्नलिखित शीर्ष-स्तरीय फ़ील्ड नहीं होने चाहिए:

• user=root
• hasroot=1
• tfa_verified=1
• successful_internal_auth_with_timestamp=<value>

...जब तक कि उस सत्र ने वास्तव में सामान्य लॉगिन प्रवाह के माध्यम से एक उचित रूट प्रमाणीकरण और 2FA चुनौती पूरी नहीं की हो। एक ऐसे सत्र पर इन फ़ील्डों की उपस्थिति जिसका मूल मेटाडेटा एक असफल पासवर्ड प्रयास दिखाता है, शोषण का एक मजबूत संकेतक है।

एक और भी उच्च-विश्वास संकेत: एकल सत्र फ़ाइल के भीतर एकाधिक pass= पंक्तियाँ। सामान्य संचालन के तहत एक सत्र में बिल्कुल एक पासवर्ड फ़ील्ड होती है। एकाधिक घटनाएँ केवल इस भेद्यता के अंतर्निहित CRLF-विभाजन व्यवहार द्वारा उत्पन्न होती हैं और इसे एक निश्चित समझौता संकेतक के रूप में माना जाना चाहिए।```bash

Sessions carrying privileged top-level fields

grep -lE '^(hasroot|tfa_verified|successful_internal_auth_with_timestamp)=1'
/var/cpanel/sessions/raw/* 2>/dev/null

Sessions with an embedded carriage return inside the password field

(indicative of CRLF-split injection rather than a single legitimate value)

grep -lP 'pass=.\r' /var/cpanel/sessions/raw/ 2>/dev/null

Sessions with more than one "pass=" line — should never legitimately occur

for f in /var/cpanel/sessions/raw/*; do n=$(grep -c '^pass=' "$f" 2>/dev/null) [ "${n:-0}" -gt 1 ] && echo "SUSPECT: $f ($n pass= lines)" done

### 7.2 एक्सेस-लॉग सहसंबंध (जब सत्र फ़ाइलें केंद्रीय रूप से अग्रेषित नहीं की जाती हैं)

यदि कच्ची सत्र फ़ाइलें पर्याप्त समय तक संग्रहीत नहीं की जाती हैं, या किसी केंद्रीय लॉगिंग सिस्टम को अग्रेषित नहीं की जाती हैं, तो `cpsrvd` से एक्सेस लॉग विकल्प के रूप में काम कर सकते हैं। दो सहसंबंध पैटर्न उपयोगी हैं:

**पैटर्न A — असफल लॉगिन जिसके तुरंत बाद एक अनुपयुक्त बेसिक-प्रमाणीकरण हेडर (Basic-auth header) आता है।** एक सामान्य क्लाइंट किसी मनमाने गैर-लॉगिन URL पर असफल पासवर्ड POST के तुरंत बाद उसी स्रोत से `Authorization: Basic` हेडर नहीं भेजता है। यह क्रम — लॉगिन एंडपॉइंट पर `401` और उसके बाद थोड़ी देर में कहीं और बेसिक-प्रमाणीकरण युक्त अनुरोध, जिसे स्रोत IP और/या सत्र कुकी द्वारा सहसंबद्ध किया गया हो — असामान्य है और इस पर अलर्ट किया जाना चाहिए।

**पैटर्न B — एक URL में `cpsess`-शैली का टोकन दिखाई देना इससे पहले कि वह कभी वैध रूप से जारी किया गया हो।** वैध प्रति-सत्र सुरक्षा टोकन सर्वर-साइड उत्पन्न होते हैं और पहली बार `Set-Cookie`/रीडायरेक्ट प्रतिक्रिया में दिखाई देते हैं, *उससे पहले* कि वे बाद के अनुरोध URL में उपयोग किए जाएँ। एक टोकन जो बिना किसी पूर्व सर्वर-जारी घटना के आने वाले अनुरोध URL में दिखाई देता है, सामान्य क्लाइंट व्यवहार के साथ असंगत है और इसे फ़्लैग किया जाना चाहिए, खासकर यदि टोकन अपेक्षित सर्वर-जनित प्रारूप से मेल नहीं खाता हो।

### 7.3 व्यवहारिक / पुनः प्रयास संकेत (Behavioral / retry signal)

क्योंकि कैश पुनर्जनन Perl के गैर-नियतात्मक हैश कुंजी क्रम के अधीन है, क्षेत्र में सफल शोषण में कभी-कभी पुनर्जीवित कैश में वांछित फ़ील्ड के "जीतने" से पहले थोड़ी संख्या में पुनः प्रयास की आवश्यकता देखी गई है। संरचनात्मक रूप से समान अनुरोधों का एक छोटा विस्फोट (एक ही स्रोत, एक ही सत्र, एक ही लक्ष्य URL पैटर्न, कुछ सेकंड के भीतर होने वाला) जिसके तुरंत बाद सफल प्रशासनिक API उपयोग होता है, यह एक द्वितीयक पुष्टिकारक संकेत है जिसे §7.1 और §7.2 के साथ महत्व देने योग्य है — अपने आप में यह अलर्ट करने के लिए बहुत सामान्य है, लेकिन यह ऊपर दिए गए फ़ाइलसिस्टम या एक्सेस-लॉग संकेतकों के साथ मिलकर आत्मविश्वास को मजबूत करता है।

### 7.4 शोषण के बाद के संकेतक (Post-compromise indicators)

क्योंकि WHM एक्सेस का अर्थ है रूट एक्सेस, पुष्टि किए गए शोषण को पूर्ण होस्ट समझौता जांच के रूप में मानें, न कि वेब-एप्लिकेशन घटना के रूप में। देखें:

- अप्रत्याशित WHM/रूट-स्तरीय उपयोगकर्ता खाते या रिसेलर खाते जो परिवर्तन-प्रबंधन प्रक्रियाओं के बाहर बनाए गए हों
- `root` या किसी भी होस्ट किए गए खाते के `~/.ssh/authorized_keys` में नई या अपरिचित SSH सार्वजनिक कुंजियाँ
- अपरिचित क्रॉन प्रविष्टियाँ, सिस्टम-व्यापी और प्रति-होस्टेड-खाता दोनों
- कस्टम WHM "हुक" जो ज्ञात प्रशासकों द्वारा प्रावधानित नहीं किए गए थे
- PHP हैंडलर कॉन्फ़िगरेशन, पैकेज/टेम्पलेट परिभाषाओं, या DNS ज़ोन फ़ाइलों में अप्रत्याशित परिवर्तन
- आउटबाउंड कनेक्शन या प्रक्रियाएँ जो root के रूप में चल रही हैं और ज्ञात cPanel/WHM सेवाओं के अनुरूप नहीं हैं

---

## 8. शमन और घटना प्रतिक्रिया प्लेबुक (Mitigation and Incident Response Playbook)

### 8.1 तत्काल कार्रवाइयाँ

1. अपने या अपने प्रदाता के नियंत्रण में प्रत्येक cPanel/WHM/WP Squared उदाहरण की **इन्वेंट्री** बनाएँ।
2. प्रकटीकरण और प्रकटीकरण-पूर्व विंडो के दौरान प्रत्येक उदाहरण के लिए **इंटरनेट एक्सपोज़र निर्धारित करें** (फरवरी 23 – अप्रैल 28, 2026 को चिंता की एक्सपोज़र विंडो मानें)।
3. एक निश्चित रिलीज़ में **पैच करें**:

| शाखा | न्यूनतम पैच किया गया संस्करण |
|---|---|
| 11.110.0.x | 11.110.0.97 |
| 11.118.0.x | 11.118.0.63 |
| 11.126.0.x | 11.126.0.54 |
| 11.132.0.x | 11.132.0.29 |
| 11.134.0.x | 11.134.0.20 |
| 11.136.0.x | 11.136.0.5 |
| WP Squared | 11.136.1.7 |

4. `/usr/local/cpanel/cpanel -V` के साथ लागू किए गए संस्करण की **पुष्टि करें**।
5. पैच करने के बाद `cpsrvd` को **पुनरारंभ करें** — एक अपुनरारंभित डेमॉन मेमोरी में असुरक्षित कोड चलाना जारी रख सकता है (`/scripts/restartsrv_cpsrvd`)।
6. यदि आप किसी तृतीय-पक्ष होस्ट पर निर्भर हैं, तो **प्रदाता से सीधे पैच स्थिति की पुष्टि करें**, यह मानने के बजाय कि यह लागू कर दिया गया है।
7. **ऑटो-अपडेट अक्षम या संस्करण-पिन** किए गए सर्वर स्वयं ठीक नहीं होंगे — इन्हें स्पष्ट मैनुअल हस्तक्षेप की आवश्यकता है और इन्हें प्राथमिकता दी जानी चाहिए, क्योंकि सांख्यिकीय रूप से इनके असुरक्षित रहने की सबसे अधिक संभावना है।

### 8.2 अल्पकालिक (पैच करने के कुछ दिनों के भीतर)

- §7 से फ़ाइलसिस्टम और लॉग-आधारित पहचान क्वेरी को पूर्ण एक्सपोज़र विंडो पर चलाएँ, न कि केवल "जब से हमने नोटिस किया"।
- अप्रत्याशित खातों, SSH कुंजियों, क्रॉन प्रविष्टियों और कस्टम हुक के लिए WHM का ऑडिट करें।
- ज्ञात-अच्छी बेसलाइन या बैकअप के विरुद्ध `/etc/`, `/usr/local/cpanel/`, और रूट के शेल कॉन्फ़िगरेशन/`authorized_keys` फ़ाइलों की अखंडता सत्यापित करें।
- रूट और रिसेलर के WHM पासवर्ड, API टोकन और SSH कुंजियाँ **घुमाएँ, भले ही समझौता संकेतक पाए गए हों या नहीं** — दो महीने की प्रकटीकरण-पूर्व शोषण विंडो को देखते हुए, उस अवधि के दौरान उजागर हुए होस्ट पर सबूतों की अनुपस्थिति अनुपस्थिति का मजबूत प्रमाण नहीं है।
- पैच करने के बाद सत्र स्थिति (`/var/cpanel/sessions/raw/` और JSON कैश निर्देशिका) को शुद्ध (purge) करें, ताकि कोई भी अवशिष्ट नकली सत्र पुनः चलाया न जा सके।

### 8.3 दीर्घकालिक कठोरीकरण (Long-term hardening)

- cPanel/WHM/Webmail पोर्ट (2082, 2083, 2086, 2087, 2095, 2096) तक आने वाली पहुँच को फ़ायरवॉल अनुमति सूची के माध्यम से ज्ञात प्रशासनिक IP श्रेणियों तक सीमित करें। ये प्रबंधन-तल पोर्ट सामान्य परिचालन स्थितियों में व्यापक रूप से इंटरनेट-पहुँच योग्य नहीं होने चाहिए।
- `cpsrvd` एक्सेस लॉग — और आदर्श रूप से सत्र-लेखन घटनाओं — को केंद्रीय रूप से बनाए रखे गए SIEM में अग्रेषित करें, क्योंकि ऑन-होस्ट सत्र फ़ाइलें क्षणिक होती हैं और यदि जल्दी संरक्षित नहीं की जाती हैं तो ट्राइएज के दौरान आसानी से खो जाती हैं।
- अपेक्षित WHM खातों, SSH कुंजियों और क्रॉन जॉब्स की एक बेसलाइन इन्वेंट्री स्थापित करें, और विचलन (drift) के लिए निगरानी करें।
- cPanel/WHM संस्करण और पैच कैडेंस को प्रथम-श्रेणी एसेट-प्रबंधन मीट्रिक के रूप में ट्रैक करें, विशेष रूप से किसी भी स्व-प्रबंधित (गैर-आउटसोर्स) उदाहरणों के लिए।

### 8.4 यदि समझौता पुष्टि हो जाती है

- **रूट-समझौता किए गए होस्ट के इन-प्लेस उपचार का प्रयास न करें।** एक बार रूट प्राप्त हो जाने पर, हमलावर के पास कुछ भी संशोधित करने की क्षमता थी, जिसमें वे उपकरण शामिल हैं जिनका उपयोग आप जांच के लिए करेंगे। इन-प्लेस "सफाई" को अविश्वसनीय मानें।
- पैच करने और संभावित रूप से समझौता किए गए सिस्टम को चलाने के बजाय **ज्ञात-स्वच्छ, पैच किए गए इमेज से पुनर्निर्माण करें**।
- **सर्वर-व्यापी सभी प्रशासनिक क्रेडेंशियल घुमाएँ**, न केवल वे जो सीधे शामिल थे।
- **सभी SSH कुंजियाँ बदलें**, जिनमें होस्ट किए गए ग्राहक खातों की भी शामिल हैं, क्योंकि रूट-स्तरीय हमलावर उनमें से किसी को भी काट सकता था या लगा सकता था।
- **मान लें कि बॉक्स पर होस्ट किया गया सभी ग्राहक डेटा उजागर हुआ था** और लागू उल्लंघन-सूचना दायित्वों का पालन करें।
- आसन्न आंतरिक नेटवर्क खंडों में **पार्श्व गति (lateral movement) की जाँच करें**, क्योंकि समझौता किया गया होस्टिंग बुनियादी ढाँचा कॉर्पोरेट वातावरणों में एक सामान्य पिवट बिंदु है (उदाहरण के लिए, क्रेडेंशियल्स, SSH विश्वास संबंधों, या कहीं और पुन: उपयोग किए गए साझा रहस्यों के माध्यम से)।

---

## 9. अक्सर पूछे जाने वाले प्रश्न (Frequently Asked Questions)

**क्या यह वर्मेबल / बड़े पैमाने पर स्वचालित शोषण के लिए उपयुक्त है?**
अंतर्निहित श्रृंखला पूरी तरह से अप्रमाणित है और इसमें HTTP अनुरोधों की एक छोटी, निश्चित संख्या शामिल है, यही कारण है कि CISA ने इसे KEV स्थिति में अपग्रेड किया और इस CVE को संदर्भित करने वाले बल्क स्कैनिंग टूल पहले ही सार्वजनिक रूप से सामने आ चुके हैं। किसी भी अपैच किए गए, इंटरनेट-पहुँच योग्य उदाहरण को अवसरवादी, स्वचालित समझौते के सक्रिय जोखिम पर मानें, न कि केवल लक्षित हमले के।

**क्या दो-कारक प्रमाणीकरण (2FA) इससे बचाता है?**
नहीं। इंजेक्शन सीधे "2FA पहले से सत्यापित" सत्र फ़्लैग को जाली बनाता है, इसलिए 2FA चुनौती पहली बार में प्रस्तुत नहीं की जाती है। 2FA इस विशिष्ट कमजोरी के लिए कोई शमन प्रदान नहीं करता है।

**क्या मेरा WAF इसे पकड़ लेगा?**
केवल यदि वह CRLF अनुक्रमों के लिए `Authorization: Basic` पेलोड को सामान्यीकृत/निरीक्षण करता है *और* एन्क्रिप्शन-स्किप स्थिति से जुड़े दुर्भावनापूर्ण/ट्रंकेटेड पैटर्न के लिए अलग से सत्र कुकी का निरीक्षण करता है। सामान्य WAF नियम सेट आमतौर पर इस मुद्दे के प्रकटीकरण-पूर्व शोषण का पता नहीं लगाते थे। WAF स्थिति की परवाह किए बिना पैचिंग अनिवार्य है।

**क्या यह cPanel DNSOnly तैनातियों को प्रभावित करता है?**
हाँ, विक्रेता सलाहकार के अनुसार — DNSOnly इंस्टॉलेशन दायरे में हैं।

**क्या पुराने, असमर्थित (पूर्व-11.40) cPanel संस्करण प्रभावित हैं?**
नहीं — सार्वजनिक विश्लेषण के अनुसार, असुरक्षित कोड पथ 11.40 शाखा से पहले के संस्करणों में मौजूद नहीं था, क्योंकि असमर्थित विरासत संस्करण प्रासंगिक सत्र-हैंडलिंग कार्यान्वयन से पहले के हैं।

**यदि मैं तुरंत पैच नहीं कर सकता तो क्या कोई वर्कअराउंड उपलब्ध है?**
पैच करने के अलावा कोई भी कार्यात्मक वर्कअराउंड मौजूद नहीं है जो कमजोरी को पूरी तरह से बंद करता हो। एकमात्र प्रभावी अंतरिम शमन नेटवर्क परिधि पर प्रभावित पोर्ट (2082/2083, 2086/2087, 2095/2096) तक आने वाली पहुँच को अवरुद्ध करना है, या `cpsrvd`/`cpdavd` सेवाओं को पूरी तरह से रोकना है, जिनमें से दोनों की कीमत वैध पहुँच की भी है।

---

## 10. सॉफ़्टवेयर और सुरक्षा इंजीनियरिंग के लिए व्यापक सबक (Broader Lessons for Software and Security Engineering)

cPanel से स्वतंत्र, यह कमजोरी कहीं और प्रमाणीकरण और सत्र-हैंडलिंग कोड की समीक्षा करने वाले किसी भी व्यक्ति के लिए एक उपयोगी केस स्टडी है:

1. **कॉलर के विवेक पर नहीं, बल्कि दृढ़ता के बिंदु पर सैनिटाइज़ करें।** कोई भी सुरक्षा नियंत्रण जिसे उसी उप-प्रणाली में एक अलग फ़ंक्शन कॉल करके बायपास किया जा सकता है, अंततः बायपास हो जाएगा — चाहे किसी हमलावर द्वारा जो अंतर पाता है, या किसी भविष्य के इंजीनियर द्वारा जो इसके अस्तित्व को नहीं जानता है।
2. **सुरक्षा नियंत्रण गुम या दुर्भावनापूर्ण इनपुट पर बंद (fail closed) होना चाहिए, कभी खुला (fail open) नहीं।** यदि कोई क्रिप्टोग्राफ़िक ऑपरेशन क्लाइंट-आपूर्ति सामग्री पर निर्भर करता है, तो उस सामग्री की अनुपस्थिति ऑपरेशन को रोक देनी चाहिए, न कि उस सुरक्षा को चुपचाप छोड़ देना चाहिए जो इसे प्रदान करने के लिए थी।
3. **एक ही डेटा का प्रत्येक दोहरा प्रतिनिधित्व एक संभावित तस्करी प्राइमिटिव (smuggling primitive) है।** जहाँ भी कोई सिस्टम एक ही स्थिति के दो क्रमांकन (सीरियलाइज़ेशन) बनाए रखता है (कच्चा बनाम कैश्ड, फ़ॉर्म-एन्कोडेड बनाम JSON, एस्केप्ड बनाम अनएस्केप्ड) और बाद में एक को दूसरे से पुनः प्राप्त करता है, उस पुनः-प्राप्ति पथ का विशेष रूप से ऑडिट करें कि क्या अविश्वसनीय डेटा बिना फ़िल्टर किए सीमा पार कर सकता है।
4. **विश्वास फ़्लैग को उस घटना से क्रिप्टोग्राफ़िक रूप से बंधा होना चाहिए जिसका वे दावा करते हैं, न कि केवल मौजूद होना चाहिए।** एक सत्र विशेषता जिसका अर्थ है "प्रमाणीकरण पहले ही सफल हो चुका है" तभी सुरक्षित है जब कोई हमलावर उस विशेषता को स्वतंत्र रूप से सेट नहीं कर सकता — एक हस्ताक्षर, MAC, या वास्तविक प्रमाणीकरण घटना के समतुल्य बंधन के माध्यम से, न कि अप्रमाणित भंडारण के माध्यम से।
5. **डिस्क पर कुछ भी लिखा गया जो किसी अप्रमाणित अनुरोध का परिणाम है, उसे हमलावर-नियंत्रित माना जाना चाहिए**, जिसमें वह डेटा भी शामिल है जिसे केवल *अन्य*, प्रतीत होने वाले असंबंधित कोड पथों द्वारा वापस पढ़ा जाता है। इस कमजोरी में खतरा उस कोड में नहीं था जिसने डेटा लिखा — यह एक पूरी तरह से अलग, बाद के कोड पथ में था जिसने इसे विभिन्न पार्सिंग नियमों के तहत पुनः व्याख्यायित किया।

---

## 11. संदर्भ (References)

- cPanel Security Advisory — *Critical Vulnerability with cPanel & WHM Login Authentication*, अप्रैल 28, 2026 — `docs.cpanel.net/release-notes/release-notes`
- watchTowr Labs — मूल कारण विश्लेषण और प्रमाण-की-अवधारणा, सीना ख़ैरख्वाह, अप्रैल 29, 2026 — `labs.watchtowr.com`
- Rapid7 — CVE-2026-41940 पर उभरता खतरा रिपोर्ट — `rapid7.com`
- Arctic Wolf — CVE-2026-41940 खतरा सारांश — `arcticwolf.com`
- Hadrian — *CVE-2026-41940: A Critical Authentication Bypass in cPanel* — `hadrian.io`
- Picus Security — *CVE-2026-41940 Explained: The cPanel & WHM Authentication Bypass That Hit 1.5M Servers* — `picussecurity.com`
- CISA Known Exploited Vulnerabilities (KEV) कैटलॉग प्रविष्टि CVE-2026-41940 के लिए — `cisa.gov`
- BleepingComputer, The Hacker News, CyberScoop — प्रकटीकरण और जंगली में शोषण की समसामयिक कवरेज
- WP Squared चेंजलॉग — `docs.wpsquared.com/changelogs`
- KnownHost सामुदायिक सलाहकार जिसमें प्रकटीकरण-पूर्व शोषण का संदेह प्रलेखित है