10/10 एक्सियोस सीवीई पैनिक: हमने हाइप का ऑडिट क्यों किया और फिर भी पैच किया

यदि आपने जावास्क्रिप्ट की दुनिया में कभी भी समय बिताया है, तो आपने axios को छुआ है। यह Node.js में HTTP अनुरोधों के लिए डिफ़ॉल्ट सेटिंग है। यह इतना सामान्य है कि हम आम तौर पर इसे भाषा के हिस्से की तरह मानते हैं। लेकिन कुछ हफ़्ते पहले, उद्योग सामूहिक रूप से मंदी में चला गया। AXIOS में 10/10 की एक गंभीर भेद्यता के बारे में सुर्खियां बटोरने लगीं- CVE-2026-40175—जिसने कथित तौर पर हमलावरों को AWS सुरक्षा को दरकिनार करने और क्लाउड क्रेडेंशियल्स चुराने की अनुमति दी थी।

स्वींट में, “10/10" ड्रॉप होने पर हमारा पहला कदम पोर्टफोलियो-व्यापी ऑडिट शुरू करना है। चाहे हम एंटरप्राइज़ डैशबोर्ड प्रबंधित कर रहे हों या पुराने एप्लिकेशन स्टैक का आधुनिकीकरण कर रहे हों, हम स्वचालित अलर्ट की प्रतीक्षा नहीं करते हैं, जिससे हमें पता चलता है कि आग लग गई है। हम ख़ुद ही धुएं की तलाश शुरू कर देते हैं। लेकिन जब हमने इस विशिष्ट भेद्यता की खोज की, तो हमें कुछ ऐसा मिला, जिसे सनसनीखेज सुर्खियां मिस कर गईं: अधिकांश आधुनिक अनुप्रयोगों के लिए, यह कारनामा आगमन पर ही खत्म हो गया था।

द एनाटॉमी ऑफ़ द स्केयर

भेद्यता को “गैजेट चेन” के रूप में वर्णित किया गया था। यदि आप इस शब्द से परिचित नहीं हैं, तो इसे हैकर्स के लिए रुबे गोल्डबर्ग मशीन की तरह समझें। अंतिम विस्फोट होने के लिए आपको एक विशिष्ट क्रम में गलत होने के लिए कई अलग-अलग चीजों की आवश्यकता होती है।

सिद्धांत रूप में, श्रृंखला इस तरह दिखती थी:

• एक हमलावर आपके आवेदन में प्रोटोटाइप प्रदूषण पैदा करने का एक तरीका ढूंढता है।

• Axios अपने आंतरिक कॉन्फ़िगरेशन को मर्ज करते समय उन प्रदूषित मूल्यों को उठाता है।

• उन मानों में CRLF (कैरिज रिटर्न लाइन फीड) अक्षर शामिल हैं जिन्हें हेडर में इंजेक्ट किया गया है।

• ये हेडर सर्वर को “रिक्वेस्ट स्मगलिंग” या सर्वर-साइड रिक्वेस्ट फोर्जरी (SSRF) में फंसाते हैं।

• हमलावर उस SSRF का उपयोग AWS इंस्टेंस मेटाडेटा सर्विस (IMDSv2) को हिट करने और आपके क्लाउड क्रेडेंशियल्स के साथ चलने के लिए करता है।

• कागज पर, यह एक दुःस्वप्न परिदृश्य है। यदि कोई हमलावर आपके नेटवर्क के अंदर से 169.254.169.254 तक पहुंच सकता है, तो वे आपके बुनियादी ढांचे के मालिक हैं। लेकिन यह मुद्दा है: सिद्धांत और उत्पादन दो बहुत अलग जगहें हैं।

• आपके रनटाइम ने शायद आपको क्यों बचाया जब हमने अपना ऑडिट किया, तो हमने महसूस किया कि यह कारनामा जिस मूल आदिम पर निर्भर करता है—CRLF हेडर इंजेक्शन—कुछ ऐसा है जिसे Node.js रनटाइम स्तर पर सालों से ब्लॉक कर रहा है। Axios तार पर ही बाइट्स नहीं भेजता है; यह Node.js में अंतर्निहित http मॉड्यूल का उपयोग करता है। जब हमने मानक वातावरण में शोषण को पुन: पेश करने की कोशिश की, तो हम एक दीवार से टकराते रहे। विशेष रूप से, एक TypeError [ERR_INVALID_CHAR] । यदि आप http.request () को एक न्यूलाइन कैरेक्टर के साथ हेडर वैल्यू पास करने का प्रयास करते हैं, तो Node.js अनुरोध के आपके सर्वर को छोड़ने से पहले ही एक त्रुटि देता है। इससे कोई फ़र्क नहीं पड़ता कि अंतर्निहित इंजन ड्राइव करने से इंकार करने पर आपका Axios कॉन्फिगरेशन कितना “प्रदूषित” है। हमने जाँच की, और वही सुरक्षा बुन और डेनो में मौजूद हैं। यह लाइब्रेरी के तकनीकी रूप से कमज़ोर होने का, लेकिन पर्यावरण के सुरक्षित होने का एक उत्कृष्ट मामला है। हमने राउल वेगा डेल वैले जैसे शोधकर्ताओं के निष्कर्षों को भी देखा। उनके काम ने पुष्टि की कि हम अपनी प्रयोगशालाओं में क्या देख रहे थे: वास्तविक दुनिया के उत्पादन अनुप्रयोगों में, इस श्रृंखला तक पहुंचना लगभग असंभव है क्योंकि दुभाषिया इसे बंद कर देता है। तो 10/10 रेटिंग क्यों? क्योंकि CVE स्कोर सबसे खराब संभव वातावरण मानते हैं, न कि आपके अच्छे से पैच किए गए Node 20.x क्लस्टर को।

द स्वीट ऑडिट

ऑटोमेटेड स्कैन से परे आप पूछ सकते हैं कि अगर रनटाइम कारनामे को रोकता है तो हम पैचिंग की जहमत क्यों उठाते हैं। इसका उत्तर सरल है: हम रक्षा की एक परत पर सुरक्षा का दांव नहीं लगाते हैं। लाइब्रेरी की गलती को पकड़ने के लिए Node.js पर भरोसा करना एक बुरी आदत है। हमारी टीम ने प्रत्येक सक्रिय प्रोजेक्ट में package-lock.json और yarn.lock फ़ाइलों की मैन्युअल रूप से समीक्षा की। हमने सिर्फ़ axios के वर्जन नंबर की तलाश नहीं की। हमने देखा कि कोड वास्तव में नेटवर्क के साथ कैसे इंटरैक्ट करता है। Dependabot जैसे ऑटोमेटेड टूल बहुत अच्छे हैं, लेकिन वे संदर्भ को नहीं समझते हैं। वे नहीं जानते कि क्या आपने एक कस्टम एडाप्टर लिखा है जो उन अंतर्निहित नोड सुरक्षा को बायपास कर सकता है।

• हमने कस्टम एडाप्टर के लिए जाँच की। यदि कोई एप्लिकेशन कस्टम Axios एडाप्टर का उपयोग करता है, जो Node.js http क्लाइंट को बायपास करता है—शायद सीधे सॉकेट पर कच्चे अनुरोध लिखने के लिए—तो रनटाइम सुरक्षा गायब हो जाती है।

• हमने प्रोटोटाइप प्रदूषण जोखिमों की तलाश की। यदि आपका ऐप प्रोटोटाइप प्रदूषण की चपेट में है, तो आपको सिर्फ Axios बग की तुलना में बहुत बड़ी समस्याएं हैं। हमने ऑडिट किया कि हम पूरे बोर्ड में JSON.parse और ऑब्जेक्ट मर्जिंग को कैसे हैंडल करते हैं।

• हमने अपने AWS कॉन्फ़िगरेशन को सत्यापित किया है। भले ही कोई SSRF हुआ हो, हम सुनिश्चित करते हैं कि हमारी परियोजनाएं सख्त हॉप सीमाओं के साथ IMDSv2 का उपयोग करें। यह एक सफल इंजेक्शन के साथ भी क्रेडेंशियल चोरी को काफी कठिन बना देता है।

• हमने देखा कि हेडर कैसे बनाए जाते हैं। हमने ऐसी किसी भी जगह की तलाश की, जहां यूज़र इनपुट बिना सैनिटाइज़ेशन के हेडर कुंजी या वैल्यू को छू सके।

24 घंटे की इस विंडो के दौरान, हमने हर प्रोजेक्ट को Axios 1.15.0 या उसके बाद के वर्शन पर ले जाया। हमने “अलर्ट थकान” को डेवलपमेंट टीमों को नष्ट करते हुए देखा है। उन्हें सप्ताह में सौ सूचनाएं मिलती हैं, जिनमें से अधिकांश कम जोखिम वाली देव-निर्भरता के लिए होती हैं, और वे उन्हें अनदेखा करना शुरू कर देते हैं। हम सुरक्षा को मैन्युअल, उच्च प्राथमिकता वाले इंजीनियरिंग कार्य के रूप में देखते हैं, ताकि शोर सिग्नल को खत्म न करे।

सप्लाई चेन की गन्दी हकीकत

यह CVE एक और बहुत डरावनी एक्सियोस घटना के बाद आया: एक मेंटेनर अकाउंट हाईजैक जिसने वास्तव में रिमोट एक्सेस ट्रोजन (RAT) को तैनात किया था। यह एक वास्तविक सप्लाई चेन हमला था। यह एक “गैजेट चेन” नहीं था जिसके लिए काम करने के लिए चार संयोगों की आवश्यकता थी; यह आपके बिल्ड पाइपलाइन में चल रहा दुर्भावनापूर्ण कोड था।

दोनों की तुलना करना आधुनिक इंजीनियरिंग की एक बड़ी समस्या को उजागर करता है। उद्योग सैद्धांतिक लाइब्रेरी-स्तर की गड़बड़ियों पर अधिक प्रतिक्रिया करता है, जबकि खाते से होने वाले समझौतों पर कम प्रतिक्रिया करता है। हमने सैद्धांतिक SSRF के बारे में बात करने में अधिक समय बिताया, जितना हमने इस तथ्य के बारे में किया कि एक प्राथमिक अनुरक्षक ने अपने npm खाते पर 2FA सक्षम नहीं किया है।

अपने इंस्टॉल किए गए संस्करण और नवीनतम पैच किए गए संस्करण के बीच डेल्टा को जितना संभव हो उतना छोटा रखना ही सचेत रहने का एकमात्र तरीका है। लेकिन आप आँख बंद करके npm update नहीं चला सकते। हमने देखा है कि “मामूली” अपडेट प्रोडक्शन हेडर को तोड़ते हैं या टाइमआउट को हैंडल करने के तरीके में बदलाव करते हैं। यही कारण है कि हमारी CI/CD पाइपलाइनों में रिग्रेशन टेस्टिंग और सुरक्षा गेट शामिल हैं। यदि कोई अपडेट एकल यूनिट परीक्षण को तोड़ता है, तो वह आगे नहीं बढ़ता है।

“क्रिटिकल” बग कब क्रिटिकल नहीं होता है?

इस CVE के लिए “10/10" रेटिंग सबसे खराब स्थिति पर आधारित थी। अगर आपको लगता है कि किसी हमलावर ने पहले ही आपके ऐप के प्रोटोटाइप से छेड़छाड़ कर दी है, और आप एक अजीब कस्टम नेटवर्क स्टैक का उपयोग कर रहे हैं, और आपका क्लाउड मेटाडेटा पूरी तरह से खुला है—तो हाँ, यह 10 है। लेकिन औसत देव के लिए? यह आपकी निर्भरता को साफ रखने के लिए एक अनुस्मारक है।

हमने ऐसी पुरानी परियोजनाओं को अपने हाथ में ले लिया है, जहां 2022 से package.json को छुआ नहीं गया है। यह एक बहुत बड़ी देनदारी है। हर पुराना पैकेज एक दरवाजा होता है जिसे खुला छोड़ दिया जाता है। हम अपने भागीदारों को इस बारे में शिक्षित करना चाहते हैं कि ये ऑडिट क्यों मायने रखते हैं। यह हर हेडलाइन का पीछा करने के बारे में नहीं है; यह जानने के बारे में है कि वास्तव में आपके उत्पादन वातावरण में कौन सा कोड चल रहा है और क्यों।

और आइए ईमानदार रहें: Axios फूला हुआ हो रहा है। यह एक बेहतरीन टूल है, लेकिन इसमें प्राचीन ब्राउज़रों और नोड संस्करणों का समर्थन करने के लिए बहुत अधिक विरासत है। कभी-कभी सबसे अच्छा सुरक्षा सुधार पैच नहीं होता है; यदि आप आधुनिक नोड रनटाइम पर हैं, तो यह मूल fetch API पर स्विच हो रहा है। इसमें कम सुविधाएं हैं, लेकिन इसमें हमले की सतह भी बहुत छोटी है।

हमारा टेकअवे

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

हमने सिर्फ़ इसलिए पैच नहीं लगाया क्योंकि समाचार ने हमें ऐसा करने के लिए कहा था। हमने पैच किया क्योंकि लाइब्रेरी को स्वयं असुरक्षित मानों की अनुमति नहीं देनी चाहिए, भले ही रनटाइम उन्हें पकड़ ले। यह गहराई से रक्षा करने के बारे में है। यदि रक्षा की पहली पंक्ति (Axios) विफल हो जाती है, तो दूसरी पंक्ति (Node.js) इसे पकड़ लेती है। यदि दूसरा विफल हो जाता है, तो तीसरा (AWS IMDSv2) पुरस्कार को ब्लॉक कर देता है। इसी तरह आप ऐसे सिस्टम बनाते हैं, जो एक लाइब्रेरी के खराब सप्ताह होने पर खत्म नहीं होते हैं।

यदि आप अपने स्वयं के डिपेंडेंसी ट्री के बारे में चिंतित हैं या यदि आपको यकीन नहीं है कि आपकी वर्तमान टीम इन बारीकियों को पकड़ रही है या नहीं, तो आपको शायद अभी अपने package-lock.json की जांच करनी चाहिए। क्या आप यह बताने के लिए किसी बॉट पर भरोसा कर रहे हैं कि आपको कब खतरा है, या क्या आपके पास ऐसी टीम है जो वास्तव में रनटाइम को समझती है?