0xmrma/cve-2026-34828listmonk में पासवर्ड रीसेट और पासवर्ड बदलने के बाद सत्र बने रहना
listmonk में पासवर्ड रीसेट और पासवर्ड परिवर्तन के बाद सत्र दृढ़ता
मुझे यह समस्या listmonk की समीक्षा करते समय मिली, जो एक ओपन-सोर्स न्यूज़लेटर और मेलिंग सूची प्रबंधक है, और मेरे मन में एक सरल सुरक्षा प्रश्न था:
जब कोई उपयोगकर्ता पासवर्ड बदलता या रीसेट करता है, तो क्या एप्लिकेशन वास्तव में पहले से जारी सत्रों को समाप्त कर देता है?
इस मामले में, उत्तर नहीं था।
पहले जारी किए गए प्रमाणित सत्र दोनों ही स्थितियों के बाद मान्य बने रहे:
इसका मतलब था कि एक चोरी की गई सत्र कुकी उन सटीक सुरक्षा घटनाओं से बच सकती है जिन पर उपयोगकर्ता अपने खाते को पुनर्प्राप्त करने के लिए भरोसा करते हैं।
इस समस्या को स्वीकार किया गया और इसे CVE-2026-34828 निर्दिष्ट किया गया।
प्रोजेक्ट: GitHub पर listmonk
CVE: CVE-2026-34828
यह listmonk को प्रभावित करता है, जो 5M+ डॉकर पुल वाली एक व्यापक रूप से अपनाई गई परियोजना है।
stolen authenticated session → victim resets or changes password → old session remains valid → attacker retains account access after credential recovery
listmonk एक सेल्फ-होस्टेड मेलिंग सूची और न्यूज़लेटर प्रबंधक है।
यह प्रदान करता है:
इसका मतलब है कि इसका सत्र मॉडल एक वास्तविक सुरक्षा सीमा है।
यहाँ महत्वपूर्ण प्रश्न यह नहीं था कि listmonk पासवर्ड रीसेट का समर्थन करता है या नहीं।
असली प्रश्न था:
क्या पासवर्ड रीसेट या पासवर्ड परिवर्तन वास्तव में हमलावर की दृढ़ता को रद्द करता है यदि कोई सत्र पहले ही चोरी हो चुका है?
इस मामले में, ऐसा नहीं हुआ।
कई सुरक्षा समीक्षाएँ लॉगिन बायपास और स्पष्ट विशेषाधिकार वृद्धि पर बहुत संकीर्ण रूप से ध्यान केंद्रित करती हैं।
इससे कमजोरियों का एक महत्वपूर्ण वर्ग छूट जाता है:
पुनर्प्राप्ति विफलताएँ
यदि कोई उपयोगकर्ता पासवर्ड बदलता या रीसेट करता है, तो उस कार्रवाई का सार्थक होना चाहिए।
इसे पुराने क्रेडेंशियल्स और पुरानी प्रमाणीकरण स्थिति में भरोसा कम करना चाहिए।
यदि किसी हमलावर के पास पहले से ही एक मान्य सत्र है और वह सत्र पुनर्प्राप्ति घटना से बच जाता है, तो पीड़ित ने वास्तव में खाते को पूरी तरह से पुनर्प्राप्त नहीं किया है।
यही यहाँ समस्या थी।
यह लॉगिन सत्यापन बग नहीं था। यह क्रिप्टो समस्या नहीं थी। यह पासवर्ड हैशिंग विफलता नहीं थी।
यह एक सत्र जीवनचक्र विफलता थी:
एक वास्तविक भेद्यता पैदा करने के लिए यह पर्याप्त है।
मैंने listmonk तक यादृच्छिक रूप से एंडपॉइंट्स पर प्रहार करके और यह उम्मीद करके नहीं पहुँचा कि एक गिर जाएगा।
मजबूत रास्ता पहले उच्चतम-मूल्य वाली भरोसा सीमा की पहचान करना था।
प्रमाणीकरण-भारी सॉफ़्टवेयर के लिए, परीक्षण करने के लिए सबसे अच्छी सीमाओं में से एक यह है:
क्या सुरक्षा-संवेदनशील खाता परिवर्तन पहले से भरोसा किए गए सत्रों को रद्द करते हैं?
यह प्रश्न आमतौर पर इसके आसपास दिलचस्प हो जाता है:
listmonk में, सबसे मजबूत संकेत पहले दो से आया।
वहीं समस्या स्पष्ट हुई।
बग यह नहीं था कि पासवर्ड परिवर्तन विफल हुए।
बग यह था कि सत्र उनसे अधिक समय तक जीवित रहे।
स्रोत समीक्षा से, पासवर्ड रीसेट प्रवाह:
लेकिन पुराने सत्रों का कोई दृश्यमान निरसन नहीं था।
वही पैटर्न प्रमाणित पासवर्ड परिवर्तन प्रवाह में दिखाई दिया:
यह व्यवहार लाइव परिणामों से बिल्कुल मेल खाता था।
प्रासंगिक कोड क्षेत्र जिनकी मैंने समीक्षा की:
cmd/auth.go forgot/reset व्यवहार के लिएcmd/users.go प्रमाणित प्रोफ़ाइल अपडेट के लिएinternal/core/users.go पासवर्ड अपडेट हैंडलिंग के लिएक्योंकि सत्र चोरी एक वास्तविक हमले की स्थिति है।
एक बार जब हमलावर किसी भी माध्यम से एक मान्य प्रमाणित सत्र कुकी प्राप्त कर लेता है, जैसे:
पीड़ित को पासवर्ड बदलकर या रीसेट करके उस हमलावर की दृढ़ता को समाप्त करने में सक्षम होना चाहिए।
यहाँ, वे नहीं कर सके।
हमले की श्रृंखला सीधी थी:
यह पूरी भेद्यता है।
महत्वपूर्ण अंतर पुनर्प्राप्ति के बाद दृढ़ता है।
कई एप्लिकेशन पासवर्ड परिवर्तन को विशुद्ध रूप से क्रेडेंशियल-स्तरीय घटना मानते हैं। यह पर्याप्त नहीं है।
असली प्रश्न यह नहीं है:
“क्या स्टोरेज में पासवर्ड मान बदल गया?”
असली प्रश्न यह है:
“क्या पुराने सत्रों से जुड़ा भरोसा संबंध रद्द किया गया?”
listmonk में, ऐसा नहीं किया गया।
यह उसे अधूरी सुरक्षा पुनर्प्राप्ति में बदल देता है जो सामान्य खाता रखरखाव हो सकता था।
यही अंतर है:
मैंने इस समस्या को दो अलग-अलग प्रवाहों में मान्य किया।
पहले, मैंने एक सामान्य परीक्षण उपयोगकर्ता बनाया और लॉग इन किया, प्रमाणित सत्र कुकी सहेजी।
फिर मैंने forgot-password प्रवाह शुरू किया, रीसेट लिंक कैप्चर किया, और पासवर्ड रीसेट किया।
रीसेट के बाद:
एक प्रतिनिधि सत्यापन अनुरोध इस तरह दिखता था:
GET /api/profile HTTP/1.1
Host: 127.0.0.1:9000
Cookie: session=<old_pre_reset_session>
और सर्वर अभी भी लौटाता था:
HTTP/1.1 200 OK
Content-Type: application/json
प्रमाणित प्रोफ़ाइल के साथ।
इसने मुख्य दावा स्थापित किया:
फिर मैंने प्रमाणित पासवर्ड परिवर्तन प्रवाह में उसी प्रकार के बग को मान्य किया।
मैंने उसी उपयोगकर्ता के रूप में दो बार लॉग इन किया और दो मान्य प्रमाणित सत्र सहेजे:
सत्र A का उपयोग करके, मैंने प्रोफ़ाइल अपडेट एंडपॉइंट के माध्यम से पासवर्ड बदला।
उदाहरण अनुरोध:
PUT /api/profile HTTP/1.1
Host: 127.0.0.1:9000
Cookie: session=<session_A>
Content-Type: application/json
{
"name":"victim1",
"email":"[email protected]",
"password":"VictimChanged123"
}
उसके बाद:
सत्र B का उपयोग करते हुए एक अनुवर्ती अनुरोध अभी भी /api/profile से प्रमाणित डेटा लौटाता था।
इसने साबित किया कि समस्या केवल forgot/reset पथ तक सीमित नहीं थी।
यह सामान्य प्रमाणित पासवर्ड परिवर्तनों को भी प्रभावित करती थी।
एक पुनरुत्पादन भी समस्या दिखाने के लिए पर्याप्त होता।
लेकिन दोनों प्रवाहों को मान्य करना दो कारणों से मायने रखता था।
इसने दिखाया कि बग केवल एक एज-केस पुनर्प्राप्ति पथ तक सीमित नहीं था।
वही सुरक्षा गुण इसमें विफल हुआ:
इसने समस्या को आकस्मिक व्यावसायिक तर्क के रूप में खारिज करना कठिन बना दिया।
यह स्पष्ट रूप से एक व्यापक सत्र प्रबंधन कमजोरी थी:
इसने समस्या को बहुत अधिक सुरक्षा भार दिया।
मैंने TOTP-सक्षम खाते पर भी रीसेट प्रवाह का परीक्षण किया क्योंकि मैं जानना चाहता था कि क्या पासवर्ड रीसेट चुपचाप 2FA अपेक्षाओं को कमजोर या बायपास कर देगा।
मैंने जो पुष्टि की वह थी:
यह एक उपयोगी सीमा जांच थी।
इसने समस्या को सही ढंग से संकुचित किया।
भेद्यता यह नहीं थी:
असली समस्या बनी रही:
यह एक स्वच्छ और अधिक रक्षणीय निष्कर्ष है।
इस समस्या को उचित रूप से उच्च (High) के रूप में वर्गीकृत किया गया।
यहाँ मुख्य प्रभाव खाता सुरक्षा पुनर्प्राप्ति क्रियाओं के बाद स्थायी अनधिकृत पहुंच है।
सलाहकार वर्गीकरण था:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:Nयह समझ में आता है।
दावा यह नहीं है कि एक हमलावर बिना क्रेडेंशियल के शून्य से लॉग इन कर सकता है। दावा यह है कि एक बार हमलावर के पास एक मान्य प्रमाणित सत्र आ जाने पर, पीड़ित उन सटीक सुरक्षा क्रियाओं को करके उस पहुंच को पूरी तरह से समाप्त नहीं कर सकता जो खाते को पुनर्प्राप्त करने वाली मानी जाती हैं, अर्थात् पासवर्ड रीसेट और पासवर्ड परिवर्तन।
यह एक वास्तविक और रक्षणीय सत्र-प्रबंधन भेद्यता है।
कुछ लोग सत्र दृढ़ता बग को कम आंकते हैं क्योंकि वे मानते हैं कि सत्र चोरी पहले से ही “गेम ओवर” है।
यह बहुत सरल है।
असली प्रश्न यह है कि पीड़ित के कुछ गलत होने का पता चलने और कार्रवाई करने के बाद क्या होता है।
यदि:
तो खाता पुनर्प्राप्ति अधूरी है।
यह केवल अजीब व्यवहार नहीं है। यह पुनर्प्राप्ति मॉडल में एक सुरक्षा विफलता है।
विशेष रूप से एक व्यवस्थापक-उन्मुख प्लेटफ़ॉर्म में, यह मजबूत गोपनीयता प्रभाव वाला एक सार्थक मुद्दा है।
मेंटेनर ने इस समस्या को कमिट में ठीक किया:
db82035
मुख्य फिक्स दिशा बिल्कुल वही है जिसकी इस बग को आवश्यकता थी:
यह सही उपचार है क्योंकि यह वास्तविक सुरक्षा गुण को लक्षित करता है जो विफल हुआ:
क्रेडेंशियल बदलने पर पुराना भरोसा समाप्त हो जाना चाहिए
इस प्रकार के बग के लिए एक अच्छा फिक्स पासवर्ड सत्यापन बदलने के बारे में नहीं है। यह खाते से जुड़ी पहले से सक्रिय सत्र स्थिति को रद्द करने के बारे में है।
यही वह हिस्सा है जो वास्तविक पुनर्प्राप्ति को बहाल करता है।
इस समस्या को GitHub के सुरक्षा रिपोर्टिंग प्रवाह के माध्यम से निजी तौर पर रिपोर्ट किया गया था।
मेंटेनर ने:
CVE-2026-34828
सलाहकार प्रबंधन के दौरान एक चीज़ सामने आई वह थी दायरा।
मूल रिपोर्ट में दोनों शामिल थे:
GitHub ने शुरू में CVE असाइनमेंट उद्देश्यों के लिए इन्हें स्वतंत्र रूप से ठीक करने योग्य मुद्दों के रूप में माना। यह एक उपयोगी अनुस्मारक है कि सलाहकार दायरा मायने रखता है भले ही अंतर्निहित कमजोरी अवधारणात्मक रूप से समान हो।
अंतिम परिणाम CVE-2026-34828 था।
यहाँ मुख्य सबक सरल है:
क्रेडेंशियल बदलना पर्याप्त नहीं है यदि पुराना प्रमाणित भरोसा अभी भी जीवित है।
कई डेवलपर्स इस संदर्भ में सोचते हैं:
वे चीजें मायने रखती हैं।
लेकिन वास्तविक सुरक्षा सीमा व्यापक है:
जब कोई उच्च-जोखिम खाता घटना होती है, तो कौन सी पहले से भरोसा की गई स्थिति का भरोसा समाप्त हो जाना चाहिए?
इस मामले में, उत्तर होना चाहिए था:
और listmonk ऐसा नहीं कर रहा था।
यही असली निष्कर्ष है।
यह भेद्यता फ़ैंसी पेलोड या चतुर पार्सर चालों के बारे में नहीं थी।
यह सही भरोसा-सीमा प्रश्न पूछने के बारे में थी।
listmonk में, पासवर्ड बदल गया।
पुनर्प्राप्ति क्रिया पूरी हुई।
लेकिन हमलावर का पुराना सत्र अभी भी जीवित था।
इसीलिए यह CVE-2026-34828 बन गया।
