OpenSSH की एक ऑथेंटिकेशन खामी PAM के बिना musl libc इस्तेमाल करने वाले कुछ खास Linux सिस्टम पर अनधिकृत SSH एक्सेस दे सकती है। दुरुपयोग की कोशिशें देखी गई हैं। एडमिनिस्ट्रेटर को अपना एक्सपोज़र (exposure) जांचना चाहिए, वेंडर का फ़िक्स लागू करना चाहिए और SSH डेमन (daemon) को रीस्टार्ट करना चाहिए।
5 नवंबर, 2026 को OpenSSH ने एक पासवर्ड-ऑथेंटिकेशन बायपास (authentication bypass) को ठीक करने के लिए वर्शन 10.6p2 जारी किया। CVE-2026-123158 के रूप में ट्रैक की जा रही यह समस्या किसी हमलावर को वैध पासवर्ड जाने बिना कुछ अकाउंट तक पहुंच दे सकती है। प्रभावित डिस्ट्रीब्यूशन में Alpine Linux खास तौर पर अहम है, क्योंकि इसका स्टैंडर्ड OpenSSH सर्वर पैकेज PAM के बिना बनाया जाता है।
Alpine, musl पर भी आधारित है, जो एक कॉम्पैक्ट C स्टैंडर्ड लाइब्रेरी है। C लाइब्रेरी उन बुनियादी फ़ंक्शन का सेट है जिन पर प्रोग्राम निर्भर रहते हैं, जिनमें पासवर्ड को हैश करने वाला फ़ंक्शन भी शामिल है। Red Hat के बिल्ड एक अलग लाइब्रेरी, glibc, इस्तेमाल करते हैं, और यह बात इस लेख में आगे मायने रखती है।
यह OpenSSH का सार्वभौमिक कंप्रोमाइज़ नहीं है। किसी सिस्टम के कमज़ोर होने के लिए उसे ऑथेंटिकेशन और अकाउंट से जुड़ी कई शर्तें पूरी करनी होती हैं। लेकिन प्रभावित सिस्टम पर, अनधिकृत अकाउंट एक्सेस संवेदनशील फ़ाइलों या बढ़े हुए प्रिविलेज तक पहुंचने का रास्ता बन सकता है।
OpenSSH रिलीज़ नोट्स वर्कअराउंड की पुष्टि करते हैं। Alpine की 5 नवंबर की एडवाइज़री प्रभावित कॉन्फ़िगरेशन, सुधारे गए पैकेज और ज़रूरी सुधार कदमों की पहचान करती है।
एक नज़र में कमज़ोरी
| विवरण | स्रोत क्या कहते हैं |
|---|---|
| पहचानकर्ता | CVE-2026-123158 |
| खुलासा | 5 नवंबर, 2026 (OpenSSH रिलीज़ और Alpine एडवाइज़री, जिसमें कहा गया था कि तब तक कोई CVE पहचानकर्ता जारी नहीं हुआ था) |
| कमज़ोरी का प्रकार | पासवर्ड-ऑथेंटिकेशन बायपास |
| संबंधित सिस्टम | PAM बंद होने के साथ musl libc इस्तेमाल करने वाला OpenSSH, जब नीचे बताई गई अतिरिक्त शर्तें भी मौजूद हों |
| संभावित असर | अनधिकृत अकाउंट लॉगिन, और जहां अकाउंट की अनुमतियां इजाज़त दें वहां संभवतः उसके बाद प्रिविलेज एस्केलेशन |
| अपस्ट्रीम सुधार | Portable OpenSSH 10.6p2 |
| गतिविधि | हनीपॉट में ऐसे अवलोकन जो दुरुपयोग की कोशिशों से मेल खाते हैं, व्यापक कंप्रोमाइज़ का सबूत नहीं |
| प्रशासनिक कार्रवाई | कॉन्फ़िगरेशन का आकलन, पैकेज अपडेट, sshd (SSH सर्वर प्रोग्राम) को रीस्टार्ट करना, संदिग्ध ऑथेंटिकेशन गतिविधि की जांच |
वे शर्तें जिनसे कोई सिस्टम प्रभावित होता है
Alpine अपने प्रभावित कॉन्फ़िगरेशन में नीचे दी गई सभी शर्तों की पहचान करता है:
- SSH सर्वर नॉन-PAM ऑथेंटिकेशन पाथ इस्तेमाल करता है। इसमें Alpine का
openssh-serverयाUsePAM noके साथ कॉन्फ़िगर किया गया उसका PAM-सक्षम बिल्ड शामिल है। PasswordAuthentication yesसंबंधित पासवर्ड-लॉगिन पाथ की अनुमति देता है।- किसी टारगेट अकाउंट के पासवर्ड फ़ील्ड में
*है। ऐसे अकाउंट पासवर्ड लॉगिन के बजाय SSH-की एक्सेस के लिए बनाए गए हो सकते हैं। - कम से कम एक अन्य लोकल अकाउंट का पासवर्ड हैश
$5$(SHA-256) या$6$(SHA-512) है। - हमलावर SSH सर्विस तक पहुंच सकता है और उसके पास इस्तेमाल करने लायक टारगेट अकाउंट नाम है।
PAM का मतलब है Pluggable Authentication Modules। यह एक फ़्रेमवर्क है जिसके ज़रिए ऐप्लिकेशन कॉन्फ़िगर किए गए ऑथेंटिकेशन तरीकों का इस्तेमाल कर सकते हैं। PAM बंद होने पर प्रभावित व्यवहार एक अलग पाथ से होता है।
कोई सिस्टम सिर्फ़ इसलिए इस खास पाथ से एक्सपोज़ नहीं होता कि वह Alpine इस्तेमाल करता है या उसमें musl लाइब्रेरी मौजूद है। जो कंटेनर sshd नहीं चलाते, वे SSH सर्वर के रूप में प्रभावित नहीं हैं। Alpine, PasswordAuthentication no और UsePAM yes वाले PAM-सक्षम सर्वर को उन कॉन्फ़िगरेशन में गिनता है जिन पर इस समस्या का असर नहीं है।
Red Hat की रिपोर्ट के अनुसार RHEL समेत उसके प्रोडक्ट प्रभावित नहीं हैं, क्योंकि उनके OpenSSH बिल्ड glibc से लिंक होते हैं और डिफ़ॉल्ट रूप से PAM इस्तेमाल करते हैं। स्रोत: Alpine एडवाइज़री और Red Hat का CVE आकलन।
बायपास कैसे काम करता है
Linux आम तौर पर मूल पासवर्ड के बजाय एक पासवर्ड हैश (password hash) स्टोर करता है, जो पासवर्ड से निकाली गई एक वैल्यू होती है। कुछ अकाउंट जानबूझकर ऐसे रखे जाते हैं जिनका कोई इस्तेमाल करने लायक पासवर्ड हैश नहीं होता। उनके पासवर्ड फ़ील्ड में इसके बजाय एक खास मार्कर, *, हो सकता है, जिससे पासवर्ड लॉगिन की अनुमति नहीं मिलनी चाहिए।
musl लाइब्रेरी का crypt() फ़ंक्शन असामान्य रूप से लंबा पासवर्ड मिलने पर एरर संकेत के रूप में भी * लौटा सकता है। कमज़ोर नॉन-PAM OpenSSH पासवर्ड-जांच पाथ में, इस एरर नतीजे को अकाउंट में स्टोर किए गए * मार्कर से मेल मान लिया जा सकता है। किसी संगत पासवर्ड हैश वाले एक और लोकल अकाउंट की मौजूदगी भी रिपोर्ट की गई शर्तों का हिस्सा है।
नतीजा एक गंभीर ट्रस्ट-बाउंड्री (trust boundary) विफलता है: निचले स्तर की लाइब्रेरी से आई एक एरर को सफल ऑथेंटिकेशन का सबूत मान लिया जा सकता है, भले ही अकाउंट का कोई वैध पासवर्ड न हो। OpenSSH 10.6p2 नोट्स कहते हैं कि मूल कारण sshd के बाहर है, लेकिन असुरक्षित व्यवहार को sshd में ही रोका जा सकता है।
यह कमज़ोरी सॉफ़्टवेयर सुरक्षा के एक सामान्य नियम को दिखाती है: किसी एरर स्टेटस को कभी भी सफल ऑथराइज़ेशन या ऑथेंटिकेशन नहीं समझा जाना चाहिए।
दुरुपयोग के अवलोकन और वे क्या साबित करते हैं
8 नवंबर को SANS Internet Storm Center ने अपने Cowrie SSH हनीपॉट (honeypot) से जुटाई गई लंबे पासवर्ड वाली गतिविधि की रिपोर्ट दी। हनीपॉट ऐसे नकली सर्वर होते हैं जो दर्ज करते हैं कि हमलावर क्या आज़माते हैं। प्रकाशित गिनती 4 नवंबर को 58, 5 नवंबर को 232, 6 नवंबर को 713, 7 नवंबर को 246 और 8 नवंबर को 15:44 UTC के रिपोर्ट अपडेट तक 51 थी।
ये लंबे पासवर्ड के अवलोकन हैं, न कि पुष्ट सफल कंप्रोमाइज़, और न ही ये सिर्फ़ इस CVE से जुड़ी कोशिशें हैं। SANS बताता है कि पहले की कुछ गतिविधि इससे असंबंधित थी। उसने 5 नवंबर को कमज़ोरी से जुड़े खास पैटर्न के पहले पहचाने जा सकने वाले इस्तेमाल के रूप में चिह्नित किया। 8 नवंबर की आंशिक गिनती की तुलना पहले के पूरे दिनों से सीधे नहीं की जा सकती।
यह अवलोकन हमले में दिलचस्पी साबित करने और तेज़ बचाव कार्रवाई को सही ठहराने के लिए काफ़ी है। इससे दुनिया भर में दुरुपयोग की मात्रा या कंप्रोमाइज़ हुए प्रोडक्शन सिस्टम की संख्या साबित नहीं होती।
पैच वर्शन और तुरंत राहत के उपाय
अपस्ट्रीम सुरक्षा सुधार OpenSSH 10.6p2 में है। Linux डिस्ट्रीब्यूटर इस फ़िक्स को बैकपोर्ट (backport) कर सकते हैं, यानी उसे ऐसे पैकेज में लागू कर सकते हैं जिन पर पहले के अपस्ट्रीम वर्शन नंबर होते हैं।
Alpine ने ये सुधारे गए पैकेज रिविज़न प्रकाशित किए:
| Alpine ब्रांच | फ़िक्स किया गया OpenSSH पैकेज |
|---|---|
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
अन्य पुरानी ब्रांच Alpine की पूरी पैच मैट्रिक्स में सूचीबद्ध हैं। यह मान लेने के बजाय कि 10.6p2 से नीचे का हर वर्शन बिना पैच का है, असली डिस्ट्रीब्यूशन एडवाइज़री और इंस्टॉल किए गए पैकेज रिविज़न की जांच करें।
Alpine के लिए उसकी एडवाइज़री अपग्रेड और सर्विस रीस्टार्ट का यह क्रम देती है:
apk upgrade -U -a
rc-service sshd restartचल रहे डेमन को रीस्टार्ट करना ज़रूरी है। Alpine साफ़ चेतावनी देता है कि पैकेज अपडेट करने से पहले से चल रहा sshd प्रोसेस नहीं बदलता। बदलाव किसी अधिकृत मेंटेनेंस प्रक्रिया के ज़रिए लागू करें, जिसमें कंसोल या कोई वैकल्पिक मैनेजमेंट पाथ पुष्ट रूप से उपलब्ध हो।
अगर पैचिंग में देर करनी पड़े, तो Alpine प्रभावी sshd कॉन्फ़िगरेशन में PasswordAuthentication no सेट करके SSH पासवर्ड ऑथेंटिकेशन बंद करने की सलाह देता है। सर्विस को रीस्टार्ट या रीलोड करने से पहले SSH-की एक्सेस की जांच करें और लॉकआउट से बचने के लिए एक चालू एडमिनिस्ट्रेटिव सेशन खुला रखें। यह एक अस्थायी राहत उपाय (mitigation) है, सुरक्षा अपडेट को अनिश्चित समय तक टालने का कारण नहीं।
संभावित अनधिकृत एक्सेस की जांच
पैचिंग आगे के लिए ज्ञात कमज़ोर पाथ को बंद कर देती है। इससे पहले हुआ कोई अनधिकृत लॉगिन पलटता नहीं है।
जिन सिस्टम पर एक्सपोज़र की शर्तें पूरी होती थीं, उन पर ऐसे सफल पासवर्ड लॉगिन के लिए SSH ऑथेंटिकेशन रिकॉर्ड देखें जिनमें केवल की से लॉगिन के लिए बनाए गए अकाउंट शामिल हों। अकाउंट या ऑथराइज़्ड-की में बिना वजह हुए बदलाव, प्रिविलेज बढ़ाने की गतिविधि और फ़ाइलों में संदिग्ध बदलावों की भी जांच करें। लॉग की कोई एक अनपेक्षित घटना जांच के लायक है, लेकिन अपने आप में इस बात का सबूत नहीं कि इस CVE का दुरुपयोग हुआ। दुरुपयोग हो चुके फ़िक्स के बाद क्या करें पर हमारा लेख एज डिवाइस के लिए यही सिद्धांत बताता है: फ़िक्स यह नहीं बताता कि उससे पहले कौन अंदर आ चुका था।
Alpine कुछ आधिकारिक tiny-cloud इमेज के साथ एक अतिरिक्त चिंता पर ज़ोर देता है, जो Alpine की क्लाउड वर्चुअल मशीन इमेज हैं। उनके alpine अकाउंट का कोई इस्तेमाल करने लायक पासवर्ड नहीं हो सकता, जबकि उसी अकाउंट के पास बिना पासवर्ड वाले doas प्रिविलेज भी हो सकते हैं (doas एक टूल है जो यूज़र को एडमिनिस्ट्रेटर के रूप में कमांड चलाने देता है)। ये इमेज पहली बार बूट होने पर ज़रूरी नहीं कि दुरुपयोग के लायक हों, लेकिन अकाउंट और पासवर्ड-हैश स्थितियों का प्रभावित मेल असर को बढ़ा सकता है।
Alpine के अनुसार 3.21.10, 3.22.8, 3.23.8 और 3.24.4 या उसके बाद के रिलीज़ से बनी इमेज में फ़िक्स किया गया पैकेज शामिल है। पहले की इमेज से शुरू किए गए इंस्टेंस को अब भी पैकेज अपडेट या पासवर्ड सेटिंग में बदलाव की ज़रूरत है। देखें Alpine का असर और पहचान से जुड़ा मार्गदर्शन।
एडमिनिस्ट्रेटर को अभी क्या करना चाहिए
Alpine या musl पर आधारित अन्य संबंधित SSH डिप्लॉयमेंट चलाने वाले संगठन पांच कदमों में काम कर सकते हैं:
- तय करें कि दस्तावेज़ में बताई गई शर्तें मौजूद हैं या नहीं।
- वेंडर का सुधारा गया पैकेज लागू करें।
- असली SSH डेमन, यानी चल रहे प्रोसेस, को रीस्टार्ट करें।
- प्रभावी ऑथेंटिकेशन कॉन्फ़िगरेशन की जांच करें।
- जहां पहले एक्सपोज़र की संभावना हो, वहां ऑथेंटिकेशन लॉग की समीक्षा करें।
हर OpenSSH इंस्टॉलेशन को कंप्रोमाइज़ मानने का कोई आधार नहीं है। यह मानने का भी कोई आधार नहीं है कि केवल SSH-की वाला अकाउंट सुरक्षित है, अगर सर्वर अब भी कमज़ोर पासवर्ड-ऑथेंटिकेशन पाथ की अनुमति देता है। जो टीमें Alpine या किसी अन्य musl सिस्टम पर कोई SSH सर्वर नहीं चलातीं, उन्हें इस खास समस्या के लिए कुछ नहीं करना है और वे इसे एक केस स्टडी की तरह देख सकती हैं।
तुरंत प्राथमिकता है कॉन्फ़िगरेशन के हिसाब से आकलन, वेंडर पैचिंग और चल रही सर्विस की जांच।
और गहराई से
- Alpine Linux सुरक्षा एडवाइज़री, 5 नवंबर, 2026: प्रभावित कॉन्फ़िगरेशन, तकनीकी व्याख्या, फ़िक्स किए गए वर्शन, सुधार और पहचान।
- OpenSSH portable 10.6p2 रिलीज़ नोट्स, 5 नवंबर, 2026: अपस्ट्रीम वर्कअराउंड और तकनीकी सीमाएं।
- Red Hat CVE-2026-123158 आकलन: डिस्ट्रीब्यूशन के हिसाब से लागू होना।
- SANS ISC, 8 नवंबर, 2026: देखी गई स्कैनिंग और सबूत की सीमाएं।