ज़ैपोकैलिप्स एक्सप्लॉइट चेन: कैसे पाँच अलग-अलग टीमों की मामूली चूकों ने मिलकर बनाया एक बड़ा सुरक्षा संकट

रिसर्चर्स ने /proc/self/mem को पढ़कर और पढ़ने योग्य मेमोरी क्षेत्रों के खिलाफ चार regex पैटर्न चलाकर इसका फ़ायदा उठाया। वे Lambda की IAM भूमिका के लिए लाइव AWS STS सेशन टोकन को सफलतापूर्वक पुनर्प्राप्त करने में सफल रहे, और इस तरह पूरी तरह से सैंडबॉक्स को बायपास कर दिया ।

चरण 2: सीमित अनुमतियों के साथ ECR की जाँच

पुनर्प्राप्त की गई AWS भूमिका का नाम allow_nothing_role (अनुवाद: कुछ न करने की अनुमति वाली भूमिका) था, लेकिन इसका नाम भ्रामक था। इस भूमिका ने चार Elastic Container Registry (ECR) अनुमतियाँ दी थीं: ecr:DescribeRepositories, ecr:ListImages, ecr:BatchGetImage, और ecr:GetDownloadUrlForLayer ।

ये चार अनुमतियाँ, बिना किसी Docker रजिस्ट्री प्रमाणीकरण टोकन की ज़रूरत के, AWS API के ज़रिए सीधे कंटेनर इमेज खींचने के लिए पर्याप्त साबित हुईं। इन अनुमतियों का उपयोग करके, रिसर्चर्स ने 1,111 उत्पादन रिपॉज़िटरीज़ की गणना की और लेयर-फ़ेच API का उपयोग करके कंटेनर इमेज खींच लीं ।

चरण 3: कंटेनर इमेज हिस्ट्री से NPM टोकन की रिकवरी

खींची गई कंटेनर इमेजों में से एक के अंदर, रिसर्चर्स को एक NPM पब्लिश टोकन मिला जो कंटेनर के कॉन्फ़िगरेशन इतिहास में लीक हो गया था। इस टोकन को डॉकरफ़ाइल में बिल्ड प्रक्रिया के दौरान एक ARG निर्देश के ज़रिए पास किया गया था, जो स्थायी रूप से इमेज के अपरिवर्तनीय history[] फ़ील्ड में दर्ज हो जाता है। इसका मतलब था कि जो कोई भी इमेज खींच सकता था, वह इस टोकन को पुनर्प्राप्त कर सकता था ।

चरण 4: बायपास्ड टू-फ़ैक्टर ऑथेंटिकेशन (2FA) के साथ NPM पब्लिश एक्सेस

पुनर्प्राप्त NPM टोकन में तीन महत्वपूर्ण गुण थे:

action: write

name: null

bypass_2fa: true

चरण 5: संभावित सप्लाई चेन पकड़ और ब्राउज़र कोड निष्पादन

इस श्रृंखला का सबसे महत्वपूर्ण पैकेज zapier-design-system था, जो zapier.com पर हर प्रमाणीकृत सत्र में लोड होता है। रिसर्चर्स ने ब्राउज़र डेवलपर टूल्स के ज़रिए इस लोड पथ की पुष्टि की, और यहीं रुक गए—उन्होंने कोई दुर्भावनापूर्ण पैकेज प्रकाशित नहीं किया ।

अगर किसी हमलावर ने इसका ज़हरीला संस्करण प्रकाशित कर दिया होता, तो वह अगले रिलीज़ पर प्रमाणीकृत zapier.com ऑरिजिन के अंदर हमलावर-नियंत्रित JavaScript को निष्पादित कर सकता था। उस स्थिति से, एक हमलावर Zaps, Tables, और MCP सर्वर बना सकता था, और प्रमाणीकृत उपयोगकर्ताओं की ओर से प्लेटफ़ॉर्म के ज़रिए मौजूदा इंटीग्रेशन चला सकता था। जुड़ी हुई सेवाओं के OAuth टोकन और API कुंजियाँ सर्वर-साइड रहती हैं और सीधे ब्राउज़र के संपर्क में नहीं आतीं, लेकिन फिर भी इसका परिचालन प्रभाव गंभीर होता ।

Zapier की प्रतिक्रिया की समय-सीमा

टोकन सिक्योरिटी ने 12 फरवरी, 2026 को रिपोर्ट सबमिट की। चार दिनों के भीतर, Zapier ने रिपोर्ट की जाँच की, लीक हुए NPM टोकन को रद्द किया, और संबंधित AWS भूमिका को सख़्त किया। 5 मार्च, 2026 तक सुधार पूरा होने की पुष्टि कर दी गई। Zapier ने बताया कि कहीं भी इस कमज़ोरी के दुरुपयोग का कोई सबूत नहीं मिला है ।

शोधकर्ताओं को प्रोग्राम का अधिकतम इनाम $3,000 मिला, और Zapier ने अपनी अगली प्रोग्राम समीक्षा में इनाम की सीमा की समीक्षा करने का वादा किया ।

यह ध्यान देने योग्य है कि यह रिसर्च डिस्क्लोज़र, 24 नवंबर, 2025 को हुए Zapier के NPM खाते पर एक वास्तविक सप्लाई चेन हमले से अलग है, जब Shai Hulud 2.0 वर्म ने खाते से समझौता किया और 425 पैकेजों को संक्रमित कर दिया था ।

बड़ी सीख: रचित कमज़ोरियाँ टीमों के बीच गिरती हैं

टोकन सिक्योरिटी में सुरक्षा अनुसंधान टीम लीड, याइर बालिल्टी ने मुख्य निष्कर्ष को स्पष्ट रूप से बताया:

"इस श्रृंखला की हर कड़ी एक जाना-पहचाना पैटर्न था। असली कमज़ोरी उनका संयोजन थी, और संयोजन ही वह चीज़ है जो टीमों के बीच गिरती है। Lambda सैंडबॉक्स, ECR और IAM, GitLab CI टोकन, NPM पब्लिशिंग, ब्राउज़र—हर एक का मालिक एक अलग समूह है, और हर कोई अपने हिस्से को देखकर आसानी से यह निष्कर्ष निकाल सकता है कि यह ठीक है। जोखिम तभी दिखाई देता है जब आप उन सभी के पार एक रास्ते का पता लगाते हैं।"

इसका निचोड़ यह है कि किसी एक टीम के पास कोई एकल कमज़ोरी नहीं थी। Lambda सैंडबॉक्स टीम ने मेमोरी स्कैवेंजिंग में कोई समस्या नहीं देखी क्योंकि टोकन वैसे भी दायरे से बाहर होना चाहिए था। IAM टीम ने एक भूमिका देखी जो केवल-पढ़ने योग्य ECR कार्रवाइयों तक सीमित थी। CI/बिल्ड टीम ने NPM टोकन को एक बिल्ड ARG के रूप में पास किया। NPM टीम ने लिखने की अनुमति वाले एक टोकन का प्रबंधन किया। ब्राउज़र टीम ने एक डिज़ाइन-सिस्टम पैकेज लोड किया। हर निर्णय व्यक्तिगत रूप से उचित था, लेकिन पाँचों प्रणालियों के पार यह श्रृंखला विनाशकारी साबित हुई ।

यह दर्शाता है कि पहचान और पहुँच समीक्षाओं को प्रत्येक घटक की अनुमतियों का अलग-अलग ऑडिट करने के बजाय, सिस्टम सीमाओं के पार हमले के रास्तों का पता लगाना चाहिए। संगठनों को क्रॉस-टीम सुरक्षा समीक्षाओं की ज़रूरत है जो यह जाँचें कि जब सिस्टम आपस में बातचीत करते हैं तो कैसे मामूली लगने वाली कॉन्फ़िगरेशन एक खतरनाक हमले की श्रृंखला में बदल जाती हैं ।