Magento और Adobe Commerce में 10 में से 10 अंकों वाली खामी: असल में क्या हुआ

पहले सीधा जवाब: 4 सितंबर 2026 को हमलावरों ने Magento Open Source और Adobe Commerce में एक बिना पैच वाली खामी का फ़ायदा उठाना शुरू किया, जिसे CVE-2026-75650 के रूप में दर्ज किया गया है और जिसका गंभीरता स्कोर 10.0 है — जो संभव सबसे ऊँचा स्कोर है। यह खामी स्टोर के सर्वर पर बिना लॉगिन और बिना किसी अधिकार के कमांड चलाने देती है, और Adobe ने इसका सुधार 7 सितंबर की शाम को जारी किया। यानी पूरे तीन दिन तक स्टोर बिना किसी सुरक्षा के खुले रहे। ठीक इसी वजह से सिर्फ़ पैच लगाना काफ़ी नहीं है: अगर आपका स्टोर इस प्लेटफ़ॉर्म पर चलता है, तो सुरक्षित मान्यता यही है कि सुधार आने से पहले ही आपके सिस्टम में सेंध लग चुकी हो सकती है, और सही प्रतिक्रिया है घुसपैठ के संकेत खोजना और अपनी एन्क्रिप्शन कुंजियाँ व हर क्रेडेंशियल बदलना — न कि अपडेट लगाकर अपने दिन के काम में लग जाना।

ठीक-ठीक कौन प्रभावित है

सूची असामान्य रूप से लंबी है, क्योंकि इसमें खोज के समय उपलब्ध सबसे नया रिलीज़ भी शामिल है:

  • Magento Open Source और Adobe Commerce: वर्ज़न 2.4.4 से 2.4.9 तक, अगस्त 2026 तक के सभी पैच अपडेट सहित।
  • Adobe Commerce B2B: वर्ज़न 1.3.3 से 1.5.3 तक, अगस्त 2026 के अपडेट तक।
  • 2.4.4 से पुराना कुछ भी: पहले से सपोर्ट से बाहर, और सबसे ख़तरनाक श्रेणी, क्योंकि आधिकारिक हॉटफ़िक्स इसे कवर नहीं करता।

साफ़ शब्दों में: अगर 1 सितंबर को आप पूरी तरह अपडेटेड Magento चला रहे थे, तो आप ख़तरे में थे। यह लापरवाही का वह जाना-पहचाना मामला नहीं है जिसके बारे में हम आमतौर पर चेतावनी देते हैं — यह एक असली zero-day है, जिससे आगे निकलने का किसी के पास कोई रास्ता नहीं था।

बिना पासवर्ड के हमला कैसे काम करता है

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

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

अंदर पहुँचकर हमलावरों ने क्या लगाया

यहीं एक उपद्रवी और एक संगठित ऑपरेशन का फ़र्क़ दिखता है। जो पेलोड देखे गए, वे शोर मचाने वाले रैनसमवेयर नोट नहीं, बल्कि चुपचाप टिके रहने वाले टूल थे:

  • Rust में लिखा एक बैकडोर, जो ऑपरेटिंग सिस्टम के कर्नेल प्रोसेस में से एक का भेस धरता है, ताकि प्रोसेस सूची पर सरसरी नज़र डालने वाले किसी व्यक्ति को वह अलग न दिखे।
  • छिपाया हुआ कमांड-एंड-कंट्रोल ट्रैफ़िक, समय-सिंक्रोनाइज़ेशन पोर्ट के ज़रिए, ताकि नेटवर्क लॉग में यह गतिविधि घड़ी मिलाने की सामान्य प्रक्रिया जैसी लगे।
  • PHP वेब शेल, जो प्रोडक्ट-इमेज कैश फ़ोल्डरों के अंदर लिखे गए — ऐसी जगहें जिन्हें आमतौर पर कोई नहीं जाँचता, क्योंकि वे अस्थायी फ़ाइलों से भरी होती हैं।
  • अतिरिक्त रिमोट-एक्सेस टूल, एक दूसरे हमलावर के, जिसके टूल बिल्कुल अलग थे — यानी इस खामी का फ़ायदा एक ही समय पर एक से ज़्यादा समूह उठा रहे थे।

किसी जाने-माने ऑनलाइन स्टोर पर ऐसे पेलोड का मक़सद साइट को बंद करना नहीं, बल्कि लंबे समय तक टिके रहना और ऑर्डर व भुगतान का डेटा गुज़रते समय पढ़ना है। संक्रमित स्टोर पूरी तरह सामान्य ढंग से चलता रहता है, और यही बात परेशान करने वाली है।

सिर्फ़ अपडेट लगाना काफ़ी क्यों नहीं है

क्योंकि अगर कोई हमलावर 7 सितंबर से पहले अंदर आ गया था, तो अब उसके पास आपकी एन्क्रिप्शन कुंजियों और सहेजे गए क्रेडेंशियल्स की एक कॉपी है। पैच वह दरवाज़ा बंद करता है जिससे वह आया था; उसे अंदर से बाहर नहीं निकालता। Adobe का अपना मार्गदर्शन इस बात पर बिल्कुल स्पष्ट था: सुधार लागू करें और उसके बाद एन्क्रिप्शन कुंजियाँ, एडमिन पैनल पासवर्ड, API टोकन, पेमेंट गेटवे क्रेडेंशियल्स, डेटाबेस पासवर्ड और सर्वर एक्सेस कुंजियाँ बदलें।

पैच ख़ून बहना रोकता है। बिन बुलाए मेहमान को घर से बाहर निकालने का काम कुंजियाँ बदलना करता है।

स्टोर मालिक के लिए एक व्यावहारिक कार्ययोजना

  • पहला — पुष्टि करें कि सुधार सचमुच इंस्टॉल हुआ है, न कि किसी ने कह दिया कि हो गया। अपनी टीम से भरोसा दिलाने वाला संदेश नहीं, बल्कि ख़ुद सर्वर के पैच लॉग से सबूत माँगें।
  • दूसरा — घुसपैठ के निशान जाँचें: सिस्टम प्रोसेस की नक़ल करने वाले नामों वाले संदिग्ध चलते प्रोसेस, मीडिया और इमेज फ़ोल्डरों के अंदर PHP फ़ाइलें, और असामान्य एरर-रिपोर्ट फ़ाइलें।
  • तीसरा — भेजे गए ईमेल का लॉग देखें। भुगतान-विफलता रिमाइंडर ईमेल में अचानक उछाल दुरुपयोग की कोशिशों का सीधा संकेत है, और कोई भी ऑपरेशंस प्रमुख गहरी सुरक्षा विशेषज्ञता के बिना इसे पढ़ सकता है।
  • चौथा — हर कुंजी बदलें, बिना किसी अपवाद के, सबसे पहले पेमेंट गेटवे क्रेडेंशियल्स। इसके लिए एक योजनाबद्ध मेंटेनेंस विंडो चाहिए, व्यस्त समय में जल्दबाज़ी में लिया गया फ़ैसला नहीं।
  • पाँचवाँ — अगर आपका वर्ज़न 2.4.4 से पुराना है, तो उस आधिकारिक पैच का इंतज़ार बंद करें जो आने वाला नहीं है। एक असली तारीख़ के साथ अपग्रेड योजना बनाएँ, और तब तक स्टोर को वेब एप्लिकेशन फ़ायरवॉल के पीछे रखें।
  • छठा — आपने जो किया, उसे दर्ज करें। अगर पता चलता है कि ग्राहकों का डेटा लीक हुआ है, तो आपको इस बात की समय-रेखा चाहिए होगी कि आपने क्या किया और कब किया।

सऊदी अरब में नियामक पहलू: ग्राहक डेटा सिर्फ़ तकनीकी मामला नहीं है

ग्राहकों के नाम, पते, मोबाइल नंबर और ऑर्डर इतिहास रखने वाला ऑनलाइन स्टोर ऐसे व्यक्तिगत डेटा को प्रोसेस कर रहा है जो व्यक्तिगत डेटा संरक्षण कानून के दायरे में आता है। डेटा उल्लंघन स्टोर और उसके होस्टिंग प्रदाता के बीच का अंदरूनी मामला बनकर नहीं रहता; इससे सक्षम प्राधिकरण और ख़ुद डेटा से जुड़े व्यक्तियों के प्रति दायित्व पैदा होते हैं। इसलिए आज स्टोर मालिक को सिर्फ़ यह नहीं पूछना चाहिए कि "क्या सर्वर पर पैच लग गया", बल्कि यह भी कि "क्या मैं साबित कर सकता हूँ कि मेरे ग्राहकों के डेटा को छुआ नहीं गया"।

अगर आपका स्टोर Salla या Zid जैसे मैनेज्ड क्लाउड प्लेटफ़ॉर्म पर चलता है, तो आप इस ख़ास खामी के दायरे से बाहर हैं, क्योंकि प्लेटफ़ॉर्म पर पैच लगाना आपकी ज़िम्मेदारी नहीं है। लेकिन यही सबक हर उस एक्सटेंशन या थर्ड-पार्टी इंटीग्रेशन पर लागू होता है जिसे आपने अपने स्टोर से जोड़ा है: पैच लगाने की ज़िम्मेदारी उसी की होती है जिसका सर्वर है।

Origami में हम ऐसी घटनाओं से कैसे निपटते हैं

जिस सिद्धांत पर हम क्लाइंट सिस्टम बनाते हैं, वह यह है कि सुरक्षा घटना कोई दूर की संभावना नहीं, बल्कि टली हुई घटना है। व्यवहार में इसका मतलब तीन बातें हैं: क्रेडेंशियल्स को कोडबेस से बाहर एक अलग वॉल्ट में रखना, ताकि उन्हें बदलना हफ़्ते भर का प्रोजेक्ट नहीं, बल्कि कुछ मिनटों का काम हो; ऑपरेशनल लॉग को सर्वर से बाहर संग्रहीत करना, ताकि हमलावर अपने निशान न मिटा सके; और ऐसे बैकअप जिन्हें सिर्फ़ शेड्यूल नहीं किया गया, बल्कि रिस्टोर करके सचमुच परखा गया है।

और अगर आप बिना समर्पित तकनीकी टीम के Magento स्टोर चलाते हैं, तो आज का सही कदम सीधा है: अपने होस्टिंग प्रदाता या तकनीकी साझेदार से एक लिखित रिपोर्ट माँगें जो सिर्फ़ तीन सवालों का जवाब दे — सुधार ठीक कब इंस्टॉल हुआ, सेंधमारी की जाँच में क्या मिला, और क्या कुंजियाँ बदली गईं। ये तीन सवाल किसी तकनीकी साझेदार की तैयारी के बारे में किसी भी प्रेज़ेंटेशन से ज़्यादा बताते हैं।

स्रोत

  • सुरक्षा अपडेट APSB26-146 और आपातकालीन हॉटफ़िक्स पर Adobe Commerce की आधिकारिक घोषणा: experienceleague.adobe.com
  • CVE-2026-75650 और सेंधमारी के संकेतकों पर Sansec का तकनीकी विश्लेषण: sansec.io/research/stylesmuggler-0day
  • CISA की ज्ञात दुरुपयोग की गई कमज़ोरियों की सूची: cisa.gov
  • व्यक्तिगत डेटा संरक्षण कानून (PDPL) — सऊदी डेटा और कृत्रिम बुद्धिमत्ता प्राधिकरण (SDAIA): sdaia.gov.sa