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 अपेक्षाओं को कमजोर या बायपास कर देगा।
मैंने जो पुष्टि की वह थी: