Axios npm CVE, असली जोखिम आपकी आउटबाउंड ट्रस्ट सीमा है।

जब टीमें "axios npm cve" खोजती हैं, तो वे आमतौर पर एक साफ-सुथरा जवाब की उम्मीद करती हैं: एक बग, एक पैच, एक अपग्रेड, काम पूरा। वास्तविक दुनिया में Axios ऐसा व्यवहार नहीं करता। यह पैकेज उस सीमा पर स्थित है जहाँ अविश्वसनीय इनपुट आउटबाउंड व्यवहार में बदल जाता है। उस सीमा में URL समाधान, हेडर प्रसारण, कुकी-आधारित टोकन हैंडलिंग, कॉन्फ़िगरेशन मर्जिंग, और Node.js में गैर-HTTP स्कीमों के लिए विशेष हैंडलिंग शामिल हैं। अब इसमें कुछ ऐसा भी शामिल है जिसे कोई साधारण भेद्यता पैच अकेले हल नहीं कर सकता: मार्च 2026 का npm समझौता जिसमें दो Axios रिलीज़ को मैलवेयर इंस्टॉलर में बदल दिया गया था। (गिटहब)

यह अंतर महत्वपूर्ण है क्योंकि हर Axios अलर्ट एक ही प्रकार की विफलता का वर्णन नहीं करता। कुछ रिकॉर्ड सर्वर-साइड रिक्वेस्ट फोरजरी के बारे में होते हैं। कुछ सुरक्षा-संवेदनशील हेडर गलत होस्ट पर भेजने के बारे में होते हैं। कुछ Node-विशिष्ट कोड पथों में डिनायल ऑफ सर्विस के बारे में होते हैं जो कभी भी नेटवर्क पैकेट नहीं भेजते। कुछ कॉन्फ़िगरेशन ऑब्जेक्ट्स के किसी भी अनुरोध के किए जाने से पहले प्रक्रिया को क्रैश करने के बारे में होते हैं। एक हालिया अलर्ट इसलिए वापस ले लिया गया क्योंकि वह संवेदनशील घटक एक पारगमन निर्भरता था जिसे स्वतंत्र रूप से पैच किया जा सकता था। एक और NVD प्रविष्टि को स्पष्ट रूप से विवादास्पद के रूप में चिह्नित किया गया है। यदि आप इसे सब कुछ "Axios में एक CVE है" में समेट देते हैं, तो आप वह इंजीनियरिंग विवरण खो देते हैं जो आपको बताता है कि क्या ठीक करना है, क्या जांच करनी है, और क्या अनदेखा करना है। (गिटहब)

Axios सुरक्षा रिकॉर्ड को पढ़ने का सही तरीका है कि पहले पैकेज की लोकप्रियता के बारे में सोचना बंद करें और पहले विश्वास की सीमाओं के बारे में सोचना शुरू करें। Axios वह परत है जहाँ डेवलपर्स अक्सर मान लेते हैं कि एक पाथ सिर्फ एक पाथ है, एक कॉलबैक URL सिर्फ एक स्ट्रिंग है, कुकी-आधारित टोकन केवल वहीं भेजा जाता है जहाँ इसकी जरूरत है, कंटेंट-लेंथ सीमा हर प्रकार के इनपुट पर लागू होती है, या पार्स किया गया JSON ऑब्जेक्ट रिक्वेस्ट कॉन्फ़िग के रूप में पास करने के लिए सुरक्षित है। अधिकांश दिलचस्प Axios सुरक्षा समस्याएँ उन धारणाओं के टूटने से उत्पन्न होती हैं जब हमलावर-नियंत्रित इनपुट होता है। (योग्य)

Axios npm CVE एक रिकॉर्ड नहीं है, यह विभिन्न विफलता मोड का एक मानचित्र है।

पैटर्न देखने का सबसे आसान तरीका रिकॉर्ड्स को एक साथ रखना है। एक बार जब आप ऐसा करते हैं, तो दोहराया जाने वाला विषय अमूर्त रूप से "Axios बग्गी है" नहीं होता। विषय यह है कि Axios अक्सर गंतव्य, हेडर, टोकन प्रसारण, पार्सिंग और ऑब्जेक्ट मर्जिंग से संबंधित सुरक्षा-संबंधी विकल्पों का मध्यस्थता करता है। विभिन्न CVEs उस सतह के विभिन्न हिस्सों को प्रभावित करते हैं।गिटहब)

रिकॉर्ड	श्रेणी	प्रभावित संस्करण	मूल समस्या	स्थिर संस्करण या स्थिति
CVE-2023-45857	टोकन रिसाव	`>=1.0.0 <1.6.0`, `>=0.8.1 <0.28.0`	एक्सियोस उजागर कर सकता है `एक्सएसआरएफ-टोकन` भेजकर `एक्स-एक्सएसआरएफ-टोकन` अनपेक्षित मेज़बानों को	`1.6.0`, `0.28.0`
CVE-2024-39338	एसएसआरएफ	`>=1.3.2 <=1.7.3`	पथ-सापेक्ष इनपुट को प्रोटोकॉल-सापेक्ष URL के रूप में संसाधित किया जा सकता है।	`1.7.4`
CVE-2024-57965	विवादास्पद उत्पत्ति जाँच रिकॉर्ड	पहले `1.7.8`	NVD एक समान-मूल पार्सिंग संबंधी चिंता को नोट करता है, लेकिन रिकॉर्ड को विवादित भी चिह्नित करता है।	विवादित, पैच निशान की ओर इशारा करता है `1.7.8`
सीवीई-2025-27152	एसएसआरएफ और प्रमाण-पत्र लीक	`<=1.7.9`, `<=0.29.0`	अब्सोल्यूट यूआरएल ओवरराइड कर सकता है `आधार URL`, लीक होने वाले हेडर या अनपेक्षित होस्ट तक पहुँचना	`1.8.2`, `0.30.0`
जीएचएसए-आरएम8पी-सीएक्स58-एचसीवीएक्स	संक्रमणशील निर्भरता चेतावनी	`axios@1.10.0`	संक्षेप में एक्सियोस को जोड़ा `form-data@4.0.0`, फिर वापस ले लिया गया	वापस ले लिया गया
CVE-2025-58754	नोड-विशिष्ट डिनायल ऑफ सर्विस	पहले `0.30.2`, पहले `1.12.0`	`डेटा:` URI डिकोड किए गए हमलावर-नियंत्रित पेलोड्स को मेमोरी में हैंडल कर रहा है।	`0.30.2`, `1.12.0`
CVE-2026-25639	कॉन्फ़िग मर्ज DoS	पहले `0.30.3`, पहले `1.13.5`	`कॉन्फ़िगरेशन मर्ज करें` अपने स्वयं वाले ऑब्जेक्ट्स पर क्रैश हुआ `प्रोटो`	`0.30.3`, `1.13.5`
मार्च २०२६ दुर्भावनापूर्ण रिलीज़	रजिस्ट्री समझौता	`1.14.1`, `0.30.4`	छिपी हुई निर्भरता के माध्यम से मैलवेयर पहुँचाने के लिए आधिकारिक npm पैकेज का उपयोग किया गया था।	दुर्भावनापूर्ण संस्करण हटा दिए गए

उपरोक्त तालिका का स्रोत GitHub एडवाइजरी, NVD प्रविष्टियाँ, वापस ली गई एडवाइजरी सूचना, और आधिकारिक Axios मुद्दा तथा दुर्भावनापूर्ण npm रिलीज़ों पर Microsoft की घटना रिपोर्ट से लिया गया है।गिटहब)

एक तत्काल निष्कर्ष यह है कि "Axios को अपग्रेड करें" पर्याप्त सुरक्षा उत्तर नहीं है। कुछ रिकॉर्ड्स के लिए अपग्रेड करना ही पर्याप्त है। दूसरों के लिए, अपग्रेड केवल एक खराब डिफ़ॉल्ट को हटाता है जबकि एक खतरनाक कॉलिंग पैटर्न जस का तस बना रहता है। रजिस्ट्री समझौते के मामले में, केवल पैचिंग पूरी तरह से गलत मानसिक मॉडल है, क्योंकि प्रभावित सिस्टम पहले ही दुर्भावनापूर्ण इंस्टॉल-टाइम कोड चला चुके हो सकते हैं और उन्हें सामान्य निर्भरता स्वच्छता के बजाय घटना प्रतिक्रिया की आवश्यकता हो सकती है।गिटहब)

AI हैकर टूल मुफ्त में आज़माएँ >>

एक्सियोस वहीं रहता है जहाँ अनुप्रयोग विश्वास नेटवर्क विश्वास बन जाता है।

Axios की अपनी दस्तावेज़ीकरण पैकेज की भूमिका स्पष्ट करती है। अनुरोध कॉन्फ़िग सतह में शामिल हैं आधार URL, absolute-url की अनुमति दें, क्रेडेंशियल्स के साथ, एक्सएसआरएफ_कुकी_नाम, एक्सएसआरएफ-हेडर-नाम, XSRF टोकन के साथ, अधिकतम सामग्री लंबाई, अधिकतम बॉडी लंबाई, रीडायरेक्ट हैंडलिंग, प्रॉक्सी सेटिंग्स, और ट्रांसपोर्ट व्यवहार। यह सिर्फ HTTP के चारों ओर एक सुविधा रैपर नहीं है; यह एक नियंत्रण तल है कि इनपुट कैसे अनुरोध बनता है। जब कोई पैकेज इतनी अधिक नीति-संबंधी व्यवहार प्रकट करता है, तो सुरक्षा समस्याएँ उन जगहों पर इकट्ठा हो जाती हैं जहाँ डेवलपर्स सुविधा सुविधाओं का उपयोग इस तरह करते हैं जैसे वे सुरक्षा सीमाएँ हों। (योग्य)

OWASP की SSRF मार्गदर्शिका उन व्यावसायिक सुविधाओं का वर्णन करती है जो URL प्रबंधन में लापरवाही होने पर खतरनाक हो जाती हैं: उपयोगकर्ता द्वारा प्रदान की गई इमेज URL, वेबहुक कॉलबैक, आंतरिक सेवा अनुरोध, आयात या फ़ेच सुविधाएँ, और कोई भी फ्लो जहाँ एप्लिकेशन उपयोगकर्ता की ओर से कुछ प्राप्त करता है। ये ठीक वही स्थान हैं जहाँ Axios अक्सर प्रोडक्शन कोड में दिखाई देता है। इन उपयोग-मामलों के लिए यह पैकेज असामान्य नहीं है। असामान्य यह है कि टीमें कितनी बार भूल जाती हैं कि वे सिर्फ एक स्ट्रिंग पर ही नहीं, बल्कि किसी गंतव्य पर उपयोगकर्ता के प्रभाव को संभाल रही हैं। (OWASP चीट शीट श्रृंखला)

व्यापक सबक सरल है। एक क्लाइंट लाइब्रेरी आपके आउटबाउंड ट्रस्ट बाउंड्री का हिस्सा है जब भी वह यह चुनती है कि कहाँ कनेक्ट करना है, कौन से हेडर संलग्न करने हैं, कुकीज़ से कौन से टोकन प्राप्त करने हैं, रीडायरेक्ट्स का अनुसरण कैसे करना है, या गैर-HTTP इनपुट्स की व्याख्या कैसे करनी है। यही वह दृष्टिकोण है जो Axios की सुरक्षा रिकॉर्ड को सुसंगत बनाता है। इस दृष्टिकोण के बिना, CVEs असंबंधित लगते हैं। इसके साथ, पैटर्न स्पष्ट है।योग्य)

Axios SSRF की कहानी वास्तव में एक इंजीनियरिंग समस्या है जिसमें कई CVEs शामिल हैं।

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

CVE-2024-39338 और प्रोटोकॉल-रिलेटिव ट्रैप

CVE-2024-39338 के लिए GitHub की एडवाइजरी में कहा गया है कि प्रभावित Axios संस्करणों से 1.3.2 के माध्यम से 1.7.3 SSRF के प्रति संवेदनशील थे क्योंकि पथ-सापेक्ष URL को प्रोटोकॉल-सापेक्ष URL के रूप में संसाधित किया जा सकता था, के साथ 1.7.4 ठीक करने का काम करते हुए। मूल रिपोर्ट एक सामान्य पैटर्न का वर्णन करती है: एक डेवलपर एक विश्वसनीय के साथ एक Axios इंस्टेंस बनाता है आधार URL, एक उपयोगकर्ता-विशिष्ट पथ जोड़ने की उम्मीद करता है, और इसके बजाय हमलावर को अनुरोध को कहीं और मोड़ने का एक तरीका दे देता है। (गिटहब)

महत्वपूर्ण हिस्सा खराब इनपुट की सटीक सिंटैक्स नहीं है। महत्वपूर्ण हिस्सा यह धारणा है कि "मैं एक पथ खंड भेज रहा हूँ" मूल रूप से "मैंने पहले ही एक गंतव्य को मानकीकृत कर लिया है और साबित कर दिया है कि यह अनुमत है" से कमजोर है। एक बार जब उपयोगकर्ता का प्रभाव उस स्तर तक पहुँच जाता है जहाँ Axios अभी भी यह तय कर रहा होता है कि वास्तविक गंतव्य क्या है, तब आप SSRF के करीब पहले से ही पहुँच चुके होते हैं, जितना कि अधिकांश कोड समीक्षक समझते हैं।गिटहब)

CVE-2025-27152 और पूर्ण URL ओवरराइड समस्या

CVE-2025-27152 ने समस्या को समझना और भी आसान बना दिया। GitHub की एडवाइजरी कहती है कि जब भी आधार URL यदि सेट है, तो एक पूर्ण URL पास करने पर Axios उस पूर्ण लक्ष्य पर अनुरोध भेज देता है, जिससे SSRF और क्रेडेंशियल लीकेज का मार्ग बनता है। एडवाइजरी का उदाहरण अत्यंत व्यावहारिक है: एक आंतरिक Axios क्लाइंट को एक के साथ कॉन्फ़िगर किया गया है एक्स-एपीआई-की, एक कॉलर पास होता है http://attacker.test/ रिलेटिव पाथ के बजाय, और रहस्य-वाहक अनुरोध हमलावर-नियंत्रित होस्ट के लिए प्रस्थान करता है। पैच किए गए संस्करण हैं 1.8.2 और 0.30.0. (गिटहब)

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

बेसयूआरएल कभी पॉलिसी इंजन क्यों नहीं था

एक्सियोस के अपने दस्तावेज़ कहते हैं कि आधार URL जोड़ा जाता है जब तक कि URL पूर्ण न हो, और वह absolute-url की अनुमति दें डिफ़ॉल्ट रूप से सच्चा. इसका मतलब है कि दस्तावेज़ीकृत डिफ़ॉल्ट व्यवहार ने हमेशा एक पूर्ण URL को प्रामाणिक माना है। absolute-url की अनुमति दें विशेषता में आया 1.8.0 लाइन, और बाद की चेंजलाग प्रविष्टियाँ में अधिक लक्षित सुधार दिखाते हैं 1.8.2, 1.8.3, और 1.8.4 पथ निर्माण और एडाप्टर व्यवहार को सही ढंग से संभालना। यह वास्तविक प्रगति है। यह कहने के समान नहीं है आधार URL अब एक पूर्ण सुरक्षा सीमा है। (योग्य)

यदि आपका सुरक्षा मॉडल इस बात पर निर्भर करता है कि "यह स्ट्रिंग उस बेस URL के अंतर्गत ही रहे," तो Axios द्वारा मान देखने से पहले आपके सुरक्षा मॉडल में एक स्पष्ट गंतव्य सत्यापन चरण होना चाहिए। नए संस्करणों के साथ भी, आपको क्लाइंट लाइब्रेरी को केवल एक ट्रांसपोर्ट लेयर के रूप में ही देखना चाहिए, न कि एकमात्र ऐसी जगह जहाँ नीति लागू होती है। OWASP की SSRF मार्गदर्शिका भी इसी दिशा में आगे बढ़ती है: URL का मानकीकरण करें, स्कीम का सत्यापन करें, होस्ट का सत्यापन करें, और जहाँ संभव हो, अल्लोलिस्ट का उपयोग करें।OWASP चीट शीट श्रृंखला)

यहाँ वह पैटर्न है जिसे कई अनुप्रयोग अभी भी गलत करते हैं:

import axios from "axios";

const internalAPIClient = axios.create({
  baseURL: "https://api.internal.example/v1/users/",
  headers: {
    "X-API-KEY": process.env.INTERNAL_API_KEY
  }
});

export async function fetchUserProfile(userInput) {
  // खतरनाक: कॉल करने वाला नियंत्रित करता है कि यह एक पथ बना रहे या नहीं
  const res = await internalAPIClient.get(userInput);
  return res.data;
}

और यहाँ एक सुरक्षित संस्करण है। मुद्दा किसी एक सहायक फ़ंक्शन की पूजा करना नहीं है। मुद्दा यह है कि गंतव्य स्पष्ट, मानक और अनुमत सूची में शामिल हो, इससे पहले कि वह परिवहन परत तक पहुंचे:

import axios from "axios";

const ALLOWED_ORIGINS = new Set([
  "https://api.internal.example"
]);

function buildSafePathFromUserInput(userInput) {
  if (typeof userInput !== "string") {
    throw new TypeError("userInput must be a string");
  }

  // Accept only an application identifier, not a full URL
  if (!/^[A-Za-z0-9_-]+$/.test(userInput)) {
    throw new Error("invalid user identifier");
  }

  return `/v1/users/${userInput}`;
}

function parseAndValidateWebhookURL(candidate) {
  const url = new URL(candidate);

  if (!["https:"].includes(url.protocol)) {
    throw new Error("unsupported protocol");
  }

  if (url.username || url.password) {
    throw new Error("embedded credentials are not allowed");
  }

  if (!ALLOWED_ORIGINS.has(url.origin)) {
    throw new Error("destination not allowed");
  }

  return url;
}

const client = axios.create({
  baseURL: "https://api.internal.example",
  allowAbsoluteUrls: false,
  headers: {
    "X-API-KEY": process.env.INTERNAL_API_KEY
  }
});

export async function fetchUserProfileById(userId) {
  const safePath = buildSafePathFromUserInput(userId);
  const res = await client.get(safePath);
  return res.data;
}

export async function callTrustedWebhook(candidateURL, payload) {
  const safeURL = parseAndValidateWebhookURL(candidateURL);
  const res = await axios.post(safeURL.href, payload, {
    headers: { "Content-Type": "application/json" }
  });
  return res.status;
}

यह कोड Node के WHATWG लॉजिक का अनुसरण करता है। यूआरएल API को इस उद्देश्य से डिज़ाइन किया गया था: स्ट्रिंग को संरचित घटकों में पार्स करना और उन घटकों को मान्य करना, बजाय इसके कि स्ट्रिंग प्रीफ़िक्स से विश्वास का अनुमान लगाया जाए। Node की दस्तावेज़ीकरण में स्पष्ट रूप से WHATWG URL ऑब्जेक्ट के संरचित विघटन और इस तथ्य का उल्लेख है कि मूल प्रोटोकॉल और होस्ट शामिल करता है लेकिन एम्बेडेड क्रेडेंशियल्स नहीं, जो इसे अलाउलिस्ट जांच के लिए एक उपयोगी इकाई बनाता है। (नोड.जेएस)

गहरा सबक यह है कि सुरक्षित URL हैंडलिंग कोई Axios ट्रिक नहीं है। यह एक एप्लिकेशन डिज़ाइन विकल्प है। आपको बेहतर सुरक्षा तब मिलती है जब आप उपयोगकर्ता इनपुट को जहाँ भी संभव हो पहचानकर्ता या पथ खंड के रूप में मॉडल करते हैं, और केवल उन्हीं प्रवाहों में पूर्ण URL स्वीकार करते हैं जहाँ वास्तव में उनकी आवश्यकता होती है। जब आप पूर्ण URL स्वीकार करते हैं, तो आपको उन्हें मानक-आधारित URL पार्सर से पार्स करना चाहिए, उन्हें एक अनुमत-सूची के खिलाफ मान्य करना चाहिए, खतरनाक स्कीमों को अस्वीकार करना चाहिए, एम्बेडेड क्रेडेंशियल्स को अस्वीकार करना चाहिए, और पहले से यह तय करना चाहिए कि रीडायरेक्ट्स और प्रॉक्सीज़ विश्वास मॉडल का हिस्सा हैं या नहीं। (OWASP चीट शीट श्रृंखला)

कार्यप्रवाह के इस चरण में, कई टीमें पाती हैं कि अब मुश्किल हिस्सा CVE का पता लगाना नहीं है। यह हर उस कोड पथ को खोजना है जहाँ उपयोगकर्ता का प्रभाव एक गंतव्य सिंक तक पहुँचता है, परिभाषित लक्ष्यों के विरुद्ध नियंत्रित इनपुट को फिर से चलाना, सबूतों को संरक्षित करना, और फिर एक फिक्स के बाद पुनः परीक्षण करना है। यह ठीक वह चरण है जहाँ सबूत-प्रथम आक्रामक सत्यापन उपकरण एक और स्कैनर अलर्ट से अधिक मूल्यवान हो जाते हैं। पेनलिजेंट की सार्वजनिक सामग्री इस प्लेटफ़ॉर्म का वर्णन ऐसे शब्दों में करती है जो इस काम के चरण के साथ स्वाभाविक रूप से मेल खाते हैं: हालिया CVE सत्यापन, एक-क्लिक PoC जनरेशन, अटैक-सर्फेस परीक्षण, और सिर्फ़ पैकेज मेटाडेटा के बजाय पुन: उत्पन्न करने योग्य सबूतों से जुड़ी रिपोर्टिंग। (पेनलिजेंट)

एक्सियोस एनपीएम सीवीई

AI हैकर टूल मुफ्त में आज़माएँ >>

CVE-2023-45857 वास्तव में हेडर प्रसारण अनुशासन के बारे में था।

पुराना Axios XSRF मुद्दा आसानी से "सिर्फ फ्रंट-एंड बग" समझ लिया जा सकता था। यह उससे कहीं अधिक महत्वपूर्ण था। GitHub की CVE-2023-45857 के लिए समीक्षित एडवाइजरी कहती है कि प्रभावित संस्करणों से 0.8.1 के माध्यम से <0.28.0 और से 1.0.0 के माध्यम से 1.6.0 प्रकट कर सकता है एक्सएसआरएफ-टोकन भेजकर कुकी एक्स-एक्सएसआरएफ-टोकन अनपेक्षित होस्ट्स को भेजे गए अनुरोधों में। NVD की शब्दावली स्पष्ट है: Axios 1.5.1 गोपनीय प्रकट कर सकता है। एक्सएसआरएफ-टोकन इसे में शामिल करके एक्स-एक्सएसआरएफ-टोकन किसी भी होस्ट को किए गए प्रत्येक अनुरोध के लिए हेडर। सुधार इसमें शामिल किए गए। 1.6.0 और 0.28.0. (गिटहब)

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

Axios की वर्तमान रिपॉजिटरी दस्तावेज़ीकरण दिखाती है कि मॉडल कैसे बदला। आज, XSRF टोकन के साथ स्पष्ट रूप से नियंत्रित करता है कि Axios XSRF कुकी पढ़े और XSRF हेडर सेट करे। डिफ़ॉल्ट व्यवहार केवल समान-मूल (same-origin) तक सीमित है। दस्तावेज़ों में यह भी उल्लेख है कि पुराने Axios संस्करणों में, सेटिंग credentials के साथ: true अप्रत्यक्ष रूप से Axios को क्रॉस-ओरिजिन अनुरोधों के लिए XSRF हेडर सेट करने के लिए प्रेरित करता है, जबकि नया Axios उन चिंताओं को अलग करता है और की आवश्यकता होती है। withXSRFToken: true अगर आप वाकई वह व्यवहार चाहते हैं। (गिटहब)

उस परिवर्तन ने कुछ अनुप्रयोगों के लिए, विशेष रूप से उन फ्रेमवर्क और बैकएंड के लिए, जिन्होंने चुपचाप पुराने व्यवहार पर निर्भरता जताई थी, समस्याएँ पैदा कर दीं। आप उन टीमों की इश्यू चर्चाओं में परिचालन संबंधी परिणाम देख सकते हैं, जिन्होंने भेद्यता को ठीक करने के लिए अपग्रेड किया और फिर अपने पुराने CSRF फ्लो को टूटा हुआ पाया। यह इस बात का संकेत नहीं है कि फिक्स गलत था। यह इस बात का संकेत है कि पुराना व्यवहार कई ऐप्स के अंदाजे से कहीं अधिक निहित विश्वास प्रसारण कर रहा था।गिटहब)

एक सुरक्षित माइग्रेशन पैटर्न यह है कि नीति को स्पष्ट रूप से परिभाषित किया जाए। क्योंकि अनुरोध क्रॉस-ओरिजिन है और उसमें क्रेडेंशियल शामिल हैं, इसलिए टोकन-उत्पन्न हेडर संलग्न न करें। हेडर केवल तभी संलग्न करें जब गंतव्य वह हो जिसे आपने उस टोकन के लिए जानबूझकर अनुमोदित किया हो।

import axios from "axios";

const TRUSTED_XSRF_ORIGINS = new Set([
  "https://app.example.com",
  "https://api.example.com"
]);

function shouldAttachXSRFHeader(config) {
  const base = config.baseURL ? new URL(config.baseURL) : new URL(window.location.origin);
  const target = new URL(config.url, base);

  return TRUSTED_XSRF_ORIGINS.has(target.origin);
}

const api = axios.create({
  withCredentials: true,
  withXSRFToken: false
});

api.interceptors.request.use((config) => {
  if (shouldAttachXSRFHeader(config)) {
    config.withXSRFToken = true;
  }
  return config;
});

सटीक तंत्र भिन्न हो सकता है। महत्वपूर्ण डिज़ाइन बिंदु यह है कि नियम आपके कोड में गंतव्य नीति के रूप में मौजूद हो, न कि किसी पुरानी लाइब्रेरी डिफ़ॉल्ट में जिसे आप मुश्किल से याद करते हैं। यह मानसिकता न केवल XSRF हेडर के लिए, बल्कि Authorization हेडर, आंतरिक API कुंजियाँ, टेनेंट राउटिंग मेटाडेटा, और केवल एक लक्ष्य मूल के लिए ही समझ में आने वाले कस्टम हेडर के लिए भी बेहतर पैमाने पर काम करती है।गिटहब)

Axios में खतरनाक गैर-नेटवर्क पथ भी हैं जो समीक्षा में हानिरहित दिखते हैं।

Axios सुरक्षा समस्याओं से अच्छे इंजीनियरों का आश्चर्यचकित होना एक कारण यह है कि वे अक्सर मान लेते हैं कि सभी जोखिम "एक HTTP अनुरोध करने" से ही आते हैं। यह धारणा Node.js में टूट जाती है, जहाँ Axios के पास ट्रांसपोर्ट लॉजिक है जो साधारण HTTP URL से अधिक को समझ सकता है और किसी भी नेटवर्क कॉल से पहले सार्थक काम कर सकता है। दो हालिया रिकॉर्ड इस बात की विशेष रूप से अच्छी याद दिलाते हैं। (गिटहब)

CVE-2025-58754 और डेटा URI सेवा अस्वीकृति

CVE-2025-58754 के लिए जारी सलाह में बताया गया है कि जब Axios Node.js पर चलता है और एक प्राप्त करता है डेटा: URL, यह HTTP बिल्कुल भी नहीं करता। Node एडाप्टर पेलोड को मेमोरी में डिकोड करता है और एक सिंथेटिक प्रतिक्रिया लौटाता है। बग यह था कि इस पथ को अनदेखा किया गया था। अधिकतम सामग्री लंबाई और अधिकतम बॉडी लंबाई, जो केवल साधारण HTTP प्रतिक्रियाओं की रक्षा करता था, इसलिए एक हमलावर एप्लिकेशन को एक बहुत बड़ा दे सकता था डेटा: URI और एक्सहॉस्ट मेमोरी, भले ही कॉल करने वाले ने स्ट्रीमिंग सिंटैक्स की उम्मीद की हो। ठीक किए गए संस्करण हैं 0.30.2 और 1.12.0. (गिटहब)

यह समस्या केवल एक कार्यान्वयन त्रुटि से कहीं अधिक है। यह एक श्रेणी का पाठ है। यदि आपका एप्लिकेशन "एक URL प्राप्त करने के लिए" स्वीकार करता है, तो असली सवाल सिर्फ यह नहीं है कि वह किस होस्ट तक पहुँच सकता है। सवाल यह भी है कि लाइब्रेरी कौन-सी स्कीमों को समझती है और वे स्कीमें कौन-से अर्थ उत्पन्न करती हैं। केवल HTTP के इर्द-गिर्द बना एक मानसिक मॉडल इस संभावना को अनदेखा कर देता है कि कोई हमलावर क्लाइंट के भीतर ही डीकोडिंग, बफ़रिंग या पार्सिंग व्यवहार को जबरदस्ती करवा सकता है।गिटहब)

यहाँ एक सरलीकृत उदाहरण है कि कैसे एक सामान्य दिखने वाली सुविधा डिनायल-ऑफ़-सर्विस सिंक में बदल सकती है:

import axios from "axios";
import express from "express";

const app = express();

app.get("/preview", async (req, res) => {
  const target = req.query.url;

  // खतरनाक धारणा:
  // "responseType: 'stream'" आपको यहाँ डेटा: URI पथ से नहीं बचाता है
  const upstream = await axios.get(target, {
    responseType: "stream",
    timeout: 5000,
    maxContentLength: 2 * 1024 * 1024
  });

  upstream.data.pipe(res);
});

app.listen(3000);

अगर लक्ष्य एक विशालकाय है डेटा: URI, आपको वह स्ट्रीमिंग व्यवहार नहीं मिल सकता जिसकी आपने उम्मीद की थी। सही समाधान Axios से पहले शुरू होता है: उन स्कीमों को अस्वीकार करें जिनकी आपको आवश्यकता नहीं है, इनपुट को पार्स करें नया यूआरएल(), और केवल अनुमति दें http: और https: उन रास्तों में जो नेटवर्क फ़ेच करने के लिए बनाए गए हैं।

function validateFetchTarget(candidate) {
  const url = new URL(candidate);

  if (!["http:", "https:"].includes(url.protocol)) {
    throw new Error("unsupported scheme");
  }

  return url.href;
}

OWASP की SSRF मार्गदर्शन भी इसी सामान्य दृष्टिकोण का समर्थन करती है। स्कीमों को नियंत्रित करें, गंतव्यों को नियंत्रित करें, और यह मानकर न चलें कि "यह URL फ़ील्ड जैसा दिखता है" का मतलब है कि हर वैध URL सिंटैक्स को इस सुविधा द्वारा स्वीकार किया जाना चाहिए।OWASP चीट शीट श्रृंखला)

एक्सियोस एनपीएम सीवीई

वन-क्लिक PoC प्राप्त करें >>

CVE-2026-25639 और mergeConfig क्रैश

CVE-2026-25639 एक और अच्छा उदाहरण है एक बग का जो गलत धारणा को उजागर करता है। GitHub और NVD दोनों एक ही स्थिति का वर्णन करते हैं: पहले 0.30.3 और 1.13.5, एक्सियोस का कॉन्फ़िगरेशन मर्ज करें फ़ंक्शन एक थ्रो कर सकता है टाइपएरर जब उसने एक विन्यास ऑब्जेक्ट को संसाधित किया जिसमें प्रोटो अपनी स्वयं की संपत्ति के रूप में। सलाह स्पष्ट करती है कि एक हमलावर इसे एक वस्तु के माध्यम से बनाए गए ऑब्जेक्ट का उपयोग करके ट्रिगर कर सकता है। जेएसओएन पार्स(), और यह भी उतना ही स्पष्ट है कि यह प्रोटोटाइप प्रदूषण नहीं है क्योंकि कोई असाइनमेंट होने से पहले ही एप्लिकेशन क्रैश हो जाता है। (गिटहब)

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

यहाँ भंगुर पैटर्न है:

import axios from "axios";
import express from "express";

const app = express();
app.use(express.json());

app.post("/proxy", async (req, res) => {
  const userConfig = JSON.parse(JSON.stringify(req.body));

  // खतरनाक: हमलावर कॉन्फ़िग के आकार को नियंत्रित करता है
  const response = await axios.request({
    method: "GET",
    url: "https://api.example.com/data",
    ...userConfig
  });

  res.json(response.data);
});

app.listen(3000);

और यहाँ है सुरक्षित वाला:

import axios from "axios";
import express from "express";

const app = express();
app.use(express.json());

function mapAllowedAxiosOptions(body) {
  const out = {};

  if (body.timeout !== undefined) {
    if (!Number.isInteger(body.timeout) || body.timeout < 0 || body.timeout > 10000) {
      throw new Error("invalid timeout");
    }
    out.timeout = body.timeout;
  }

  if (body.params && typeof body.params === "object" && !Array.isArray(body.params)) {
    out.params = body.params;
  }

  if (body.headers && typeof body.headers === "object" && !Array.isArray(body.headers)) {
    out.headers = {
      "X-Request-Source": "proxy-service"
    };
  }

  return out;
}

app.post("/proxy", async (req, res) => {
  const safeConfig = mapAllowedAxiosOptions(req.body);

  const response = await axios.request({
    method: "GET",
    url: "https://api.example.com/data",
    ...safeConfig
  });

  res.json(response.data);
});

app.listen(3000);

यहाँ सुरक्षित डिज़ाइन पैटर्न पहले के सुरक्षित URL पैटर्न के समान ही है: उपयोगकर्ता-नियंत्रित डेटा को उसके कच्चे रूप में किसी शक्तिशाली इंटरफ़ेस तक पहुँचने न दें। इसे उन फ़ील्ड्स की एक सीमित अनुमोदन-सूची में मैप करें जिन्हें आप स्वीकार करना चाहते हैं, और बाकी सभी को अस्वीकार कर दें। पैच महत्वपूर्ण है, लेकिन कोडिंग पैटर्न और भी अधिक महत्वपूर्ण है।गिटहब)

हर Axios अलर्ट का मतलब यह नहीं होता कि Axios स्वयं ही दोषपूर्ण घटक है।

डिपेन्डेंसी रिस्पॉन्स कार्य में समय बर्बाद करने का एक सबसे आसान तरीका है कि पैकेज नाम वाले हर अलर्ट को सीधे पैकेज दोष मान लिया जाए। Axios का हाल ही में एक उदाहरण रहा है, जो इस गलती को बहुत स्पष्ट रूप से दिखाता है।

GitHub ने एक समीक्षित एडवाइजरी प्रकाशित की जो जोड़ती है axios@1.10.0 में एक महत्वपूर्ण मुद्दा form-data@4.0.0, फिर अगले दिन इसे वापस ले लिया। निकासी सूचना में कहा गया है कि Axios के उपयोगकर्ता 1.10.0 का एक पैच किया हुआ संस्करण उपयोग करने का लचीलापन था फ़ॉर्म-डेटा Axios को अपग्रेड किए बिना, क्योंकि यह भेद्यता Axios में नहीं बल्कि ट्रांज़िटिव डिपेंडेंसी में उत्पन्न हुई थी। एडवाइजरी ने प्रारंभ में संकेत दिया था फ़ॉर्म-डेटा उपयोग करके सीमा निर्माण गणित.रैंडम() और इलाज किया गया axios@1.10.0 क्योंकि उसने उस ट्रांज़िटिव पैकेज संस्करण को हल किया था। (गिटहब)

यह घटना उपयोगी है क्योंकि यह एक साथ तीन परिचालन सबक सिखाती है। पहला, एक Axios अलर्ट वास्तव में एक डिपेंडेंसी-ट्री अलर्ट हो सकता है। दूसरा, सही सुधार पैकेज अपग्रेड के बजाय ट्रांज़िटिव ओवरराइड हो सकता है। तीसरा, स्कैनर आउटपुट की एक स्थिति होती है, और वह स्थिति मायने रखती है। एक वापस ली गई एडवाइजरी को स्वचालित बड़े पैमाने पर अपग्रेड टिकट के बजाय गहन जांच शुरू करनी चाहिए।गिटहब)

Axios का अपना इकोसिस्टम आपको उस प्रकार के मामले को संभालने के लिए एक व्यावहारिक तंत्र प्रदान करता है। npm का ओवरराइड करता है field का अस्तित्व ठीक इसलिए है कि ट्री में निर्भरताओं के संस्करणों को बदला या पिन किया जा सके। npm दस्तावेज़ इसे निर्भरताओं की निर्भरताओं को बदलने का एक तरीका बताते हैं, जिसमें किसी पैकेज को उस संस्करण से बदलना शामिल है जो सुरक्षा संबंधी समस्या का समाधान करता है या हर जगह एक समान संस्करण लागू करना।एनपीएम दस्तावेज़)

एक सामान्य शमन इस प्रकार दिखता है:

{
  "dependencies": {
    "axios": "1.10.0"
  },
  "overrides": {
    "form-data": "4.0.4"
  }
}

इसका मतलब यह नहीं है कि ओवरराइड हमेशा सबसे अच्छा समाधान होता है। इसका मतलब है कि आपको "Axios कोड टूटा हुआ है," "Axios की डिफ़ॉल्ट सेटिंग्स जोखिम भरी हैं," और "Axios कोई खराब ट्रांज़िटिव संस्करण खींचता है" में अंतर करना चाहिए। ये अलग-अलग समस्याएँ हैं, और परिपक्व टीमें इनका अलग-अलग तरीके से समाधान करती हैं।गिटहब)

विवादित रिकॉर्डों पर भी वही सावधानी लागू होती है। NVD की CVE-2024-57965 के लिए प्रविष्टि में स्पष्ट रूप से टैग शामिल है। विवादित और कहते हैं कि कुछ पक्षों का मानना है कि इस बदलाव ने एक वास्तविक भेद्यता के बजाय केवल एक SAST चेतावनी संदेश को संबोधित किया। रिकॉर्ड अभी भी मौजूद है। स्कैनर इसे अभी भी उजागर कर सकते हैं। लेकिन सही इंजीनियरिंग प्रतिक्रिया रिकॉर्ड की स्थिति को पढ़ना है, न कि केवल शीर्षक को। सभी निर्भरता चेतावनियों को समान तात्कालिकता नहीं लेनी चाहिए या समान स्तर की शोषण क्षमता का संकेत नहीं देना चाहिए।एनवीडी)

मार्च 2026 की दुर्भावनापूर्ण रिलीज़ों ने Axios पैकेज जोखिम के अर्थ को बदल दिया।

मार्च 2026 Axios npm घटना इस बात का कारण है कि अब इस विषय को केवल CVEs तक सीमित नहीं किया जा सकता। आधिकारिक Axios मुद्दे के अनुसार, संस्करण 1.14.1 और 0.30.4 संक्रमित हो गए थे और रजिस्ट्री से हटा दिए गए थे। माइक्रोसॉफ्ट की रिपोर्ट में कहा गया है कि इन संस्करणों ने एक दुर्भावनापूर्ण निर्भरता इंजेक्ट की, plain-crypto-js@4.2.1, जिसने एक को निष्पादित किया स्थापना के बाद path और ज्ञात हमलावर के इन्फ्रास्ट्रक्चर से प्लेटफ़ॉर्म-विशिष्ट दूसरे चरण के पेलोड प्राप्त किए। Microsoft यह भी कहता है कि प्रकाशन का मेटाडेटा परियोजना के सामान्य CI-समर्थित प्रकाशन पैटर्न से भिन्न था, जिसमें विश्वसनीय प्रकाशक बाइंडिंग का अभाव और दुर्भावनापूर्ण संस्करणों के लिए संबंधित रिपॉजिटरी टैग या कमिट ट्रेल का अभाव शामिल था। (गिटहब)

Snyk का घटना विश्लेषण एक अन्य दृष्टिकोण से उसी मुख्य निष्कर्ष पर पहुंचता है: Axios के स्रोत कोड में दुर्भावनापूर्ण रनटाइम लॉजिक जोड़ने के लिए कोई बदलाव नहीं किया गया था। इसके बजाय, हमलावर ने एक विशेष उद्देश्य के लिए बनाई गई निर्भरता जोड़ी, जिसका काम इंस्टॉलेशन के समय निष्पादन को ट्रिगर करना था। दुर्भावनापूर्ण रिलीज़ विंडो संक्षिप्त थी, लेकिन उस विंडो के दौरान कोई भी डेवलपर वर्कस्टेशन, CI सिस्टम, या बिल्ड वातावरण जो ताज़ा इंस्टॉलेशन करता था, वह Axios को एप्लिकेशन कोड में कभी भी इम्पोर्ट किए बिना ही समझौता हो सकता था। (स्निक)

इसीलिए रजिस्ट्री समझौता भी CVEs की तरह ही उसी चर्चा में आता है, भले ही यह उसी प्रकार की खामी न हो। उपयोगकर्ता की दृष्टि से, दोनों स्थितियाँ "Axios सुरक्षा समस्या" के रूप में ही दिखती हैं। रक्षक की दृष्टि से, इनके लिए अलग-अलग कार्यप्रणालियाँ आवश्यक होती हैं।

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

उपरोक्त तुलना का स्रोत GitHub के आधिकारिक Axios मुद्दे, Snyk के घटना विश्लेषण, और Microsoft के शमन मार्गदर्शन से लिया गया है।गिटहब)

माइक्रोसॉफ्ट का मार्गदर्शन उचित रूप से स्पष्ट है: जिन्होंने संगठनों ने स्थापित किया 1.14.1 या 0.30.4 गोपनीय जानकारी और प्रमाण-पत्रों को तुरंत बदलें और किसी ज्ञात-सुरक्षित संस्करण जैसे पर डाउनग्रेड करें। 1.14.0 या 0.30.3. यह सामान्य पैकेज CVE के लिए प्रतिक्रिया देने का तरीका नहीं है। यह उस स्थिति में प्रतिक्रिया देने का तरीका है जब इंस्टॉलेशन के समय मैलवेयर पहले से ही डेवलपर या CI इंफ्रास्ट्रक्चर पर चल चुका हो। (माइक्रोसॉफ्ट)

व्यावहारिक बात यह है: यदि कोई स्कैनर आपको अलर्ट भेजने के कारण आप "axios npm cve" खोज रहे हैं, तो केवल पैच नोट्स तक ही सीमित न रहें। पुष्टि करें कि यह अलर्ट किसी लाइब्रेरी बग, ट्रांज़िटिव भेद्यता, विवादित रिकॉर्ड या समझौता किए गए रिलीज़ से संबंधित है। सुधार का मार्ग एक-लाइन पैकेज बम्प से लेकर पूर्ण क्रेडेंशियल रोटेशन और एंडपॉइंट समीक्षा तक हो सकता है।गिटहब)

यह कैसे सत्यापित करें कि आपका कोड वास्तव में एक्सपोज़्ड है

एक डिपेंडेंसी डैशबोर्ड आपको बता सकता है कि Axios मौजूद है। यह नहीं बता सकता कि आपके एप्लिकेशन ने खतरनाक जगहों पर Axios को सुरक्षा सीमा में बदल दिया है या नहीं। इसके लिए कोड समीक्षा और लक्षित सत्यापन की आवश्यकता होती है।

सबसे पहले देखने वाली बात यह है कि Axios कहीं भी हमलावर-प्रभावित गंतव्य सामग्री प्राप्त कर रहा है या नहीं। इसमें स्पष्ट विशेषताएँ शामिल हैं जैसे वेबहुक URL, इमेज डाउनलोड URL, अवतार आयात URL, कॉलबैक URL, और सामान्य "इस URL को प्राप्त करें" एंडपॉइंट्स। इसमें वे कम स्पष्ट फ्लो भी शामिल हैं जहाँ एक पाथ सेगमेंट, टेनेंट पहचानकर्ता, या संसाधन आईडी को हानिरहित माना जाता है, जबकि यह URL निर्माण को प्रभावित करता है। OWASP की SSRF मार्गदर्शन एक अच्छी मानसिक चेकलिस्ट है क्योंकि प्रभावित व्यावसायिक पैटर्न बहुत समान दिखते हैं। (OWASP चीट शीट श्रृंखला)

दूसरी बात जिस पर ध्यान देना चाहिए, वह है कोई भी ऐसा स्थान जहाँ आप स्वचालित रूप से सुरक्षा-संवेदनशील संदर्भ प्राप्त करते हैं। यदि कोई ब्राउज़र फ्लो अभी भी पुराने क्रॉस-ऑरिजिन XSRF व्यवहार को मानता है, या यदि कोई Node आंतरिक क्लाइंट किसी Axios इंस्टेंस में विशेषाधिकार प्राप्त हेडर जोड़ता है जिसे कहीं और निर्देशित किया जा सकता है, तो आपके पास एक प्रसारण समस्या है, भले ही आपने अंतर्निहित CVE को पैच कर दिया हो। बग ठीक हो सकता है, लेकिन वास्तुशिल्पीय आदत बनी रहती है।गिटहब)

तीसरी चीज़ जिसे देखना चाहिए वह है कॉन्फ़िग इनजेक्शन। ऐसे कोड की तलाश करें जो अनुरोध-जैसे JSON को Axios कॉन्फ़िग ऑब्जेक्ट्स में फैलाता, मर्ज करता या फॉरवर्ड करता हो। यदि आप पाते हैं ...आवश्यकतानुसार बॉडी, Object.assign(डिफ़ॉल्ट्स, यूज़रइनपुट), या कोई भी रैपर जो ट्रस्ट बाउंड्री के बाहर से मनमाने कॉन्फ़िग कीज़ स्वीकार करता है, उसे CVE-2026-25639 को ध्यान में रखकर समीक्षा करें। वह रिकॉर्ड इस बात की एक मजबूत याद दिलाता है कि कॉन्फ़िगरेशन एपीआई सिर्फ इसलिए हानिरहित नहीं होते क्योंकि वे आपके बिजनेस पेलोड नहीं हैं। (गिटहब)

जिन टीमों के पास पहले से ही एक परिपक्व सत्यापन वर्कफ़्लो होता है, उनके लिए यह वह बिंदु है जहाँ स्वचालन एक बहुत ही विशिष्ट तरीके से उपयोगी हो जाता है। मुश्किल हिस्सा एडवाइजरी पढ़ना नहीं है। मुश्किल हिस्सा संभावित सिंक की सूची बनाना, परिभाषित लक्ष्यों पर सुरक्षित प्रोब्स को फिर से चलाना, सबूत इकट्ठा करना, और फिक्स के बाद पुनः परीक्षण को दोहराने योग्य बनाना है। यहीं पर एआई-सहायक आक्रामक वर्कफ़्लो वास्तव में उपयोगी हो सकता है, न कि केवल दिखावटी रूप में। पेनलिजेंट का सार्वजनिक उत्पाद, जो सबूत-प्रथम परीक्षण, CVE सत्यापन, एक-क्लिक PoC निर्माण और रिपोर्टिंग पर केंद्रित है, पुराने "स्कैनर प्लस चैटबॉट" मॉडल की तुलना में इस तरह के सत्यापन लूप के लिए कहीं अधिक स्वाभाविक रूप से उपयुक्त है। (पेनलिजेंट)

बिल्ड ईविडेंस अकेले package.json से अधिक महत्वपूर्ण है।

मार्च 2026 के समझौते ने रक्षकों को यह भी याद दिलाया कि पैकेज प्रतिक्रिया केवल स्रोत रिपॉजिटरी तक सीमित नहीं है। npm की लॉकफाइलों पर दस्तावेज़ीकरण यहाँ विशेष रूप से प्रासंगिक है। npm v7 से, लॉकफाइल में एक संपूर्ण पैकेज ट्री का वर्णन करने के लिए पर्याप्त जानकारी होती है, और npm एक छिपी हुई लॉकफाइल का भी उपयोग करता है। नोड_मॉड्यूल्स/.पैकेज-लॉक.जेएसओएन स्थापना की स्थिति को अनुकूलित करने के लिए। यदि आप केवल रूट की जाँच करते हैं पैकेज-लॉक.जेएसओएन, आप स्थानीय वर्कस्पेस या अस्थायी CI ट्री में बनाए गए सबूत चूक सकते हैं। (एनपीएम दस्तावेज़)

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

यहाँ कुछ व्यावहारिक कमांड्स हैं जिन्हें पास रखना उपयोगी रहेगा:

# इन्वेंटरी डायरेक्ट और ट्रांज़िटिव axios संस्करण
npm ls axios

# दुर्भावनापूर्ण मार्च 2026 रिलीज़ और निर्भरता के लिए खोजें
grep -RInE 'axios@1\.14\.1|axios@0\.30\.4|plain-crypto-js' \
  package-lock.json npm-shrinkwrap.json yarn.lock pnpm-lock.yaml . 2>/dev/null

# यदि node_modules अभी भी मौजूद है तो छिपी हुई npm v7+ लॉकफाइलों का निरीक्षण करें
find . -type f -path '*/node_modules/.package-lock.json' -print

# जाँचें कि क्या संदिग्ध डिपेंडेंसी स्थानीय रूप से मौजूद है
find . -type d -name plain-crypto-js 2>/dev/null

ये कमांड जादू नहीं हैं, और ये होस्ट समीक्षा का विकल्प नहीं हैं। ये केवल अच्छे साक्ष्य संग्रह हैं। इनका महत्व इसलिए है क्योंकि npm की इंस्टॉल स्थिति सटीक हल किए गए ट्री को संरक्षित कर सकती है, जबकि दुर्भावनापूर्ण Axios घटना ने एप्लिकेशन रनटाइम कोड के बजाय इंस्टॉलेशन व्यवहार का विशेष रूप से दुरुपयोग किया। (एनपीएम दस्तावेज़)

संस्करण अपग्रेड आवश्यक हैं, लेकिन वे पूरी मरम्मत नहीं हैं।

सबसे आम डिपेंडेंसी प्रतिक्रिया त्रुटि यह मान लेना है कि संस्करण वृद्धि (version bumps) स्वचालित रूप से उस असुरक्षित कॉलिंग पैटर्न को मिटा देती है जिसने संदर्भ में पैकेज को खतरनाक बनाया था। Axios इसका एक अच्छा उदाहरण है क्योंकि इसके कई CVEs को लाइब्रेरी द्वारा गंतव्यों को हल करने या सुरक्षा-संवेदनशील मानों को प्रसारित करने के तरीके को बदलकर ठीक किया गया था। इससे जोखिम निश्चित रूप से कम होता है। इसका यह मतलब नहीं है कि अब आपके एप्लिकेशन में एक सुस्पष्ट आउटबाउंड नीति है।गिटहब)

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

एक छोटी मेज़ पैटर्न को याद रखने में आसान बनाती है:

इनपुट आकार	सामान्य गलती	बेहतर नियंत्रण
उपयोगकर्ता आईडी या स्लग	ऐसे व्यवहार किया जाता है जैसे यह URL सीमा नहीं बन सकता।	आईडेंटिफ़ायर के रूप में मान्य करें और पथ स्वयं बनाएँ।
वेबहुक यूआरएल	केवल स्ट्रिंग उपसर्ग जाँचें	के साथ पार्स करें `यूआरएल`, योजना, मूल, प्रमाण-पत्र और पोर्ट को मान्य करें
सामान्य फ़ेच यूआरएल	सभी वैध URL योजनाओं को स्वीकार करें	केवल अनुमति दें `http:` और `https:`
ब्राउज़र XSRF टोकन प्रवाह	पुराने डिफ़ॉल्ट्स को हेडर प्रसारण चुनने दें।	बनाएँ `XSRF टोकन के साथ` प्रत्येक विश्वसनीय स्रोत के लिए स्पष्ट नीति
उपयोगकर्ता JSON कॉन्फ़िगरेशन	Axios विकल्पों में थोक रूप में फैलाएं	मैप ने केवल कुंजियों को एक साफ़ कॉन्फ़िग ऑब्जेक्ट में अनुमति दी।
ट्रांज़िटिव पैकेज चेतावनी	हर बार शीर्ष-स्तरीय अपग्रेड जबरदस्ती करें	जाँचें कि ओवरराइड या डायरेक्ट ट्रांज़िटिव पैचिंग अधिक उपयुक्त है।

इन नियंत्रणों के लिए समर्थन Axios के वर्तमान कॉन्फ़िग मॉडल, प्रासंगिक एडवाइजरीज़, Node की URL API, और npm के ओवरराइड समर्थन से आता है।योग्य)

सप्लाई चेन नियंत्रण अब एक्सियोस सुरक्षा वार्ता का हिस्सा हैं।

मार्च 2026 के समझौते ने एक कठोर सच्चाई भी उजागर की: आप हर ज्ञात Axios CVE को पैच कर सकते हैं और फिर भी हार सकते हैं यदि आपके पैकेज लेने और प्रकाशित करने के नियंत्रण कमजोर हैं। यह अब Axios-विशिष्ट अवलोकन नहीं है। यह Node इकोसिस्टम का अवलोकन है। OWASP की npm सुरक्षा चीट शीट लॉकफाइलों को लागू करने, जहाँ व्यावहारिक हो वहाँ रन-स्क्रिप्ट्स को अनदेखा करके हमले की सतह को कम करने, निर्भरताओं का ऑडिट करने, और सुरक्षित पैकेज प्रकाशन के लिए विश्वसनीय प्रकाशकों का उपयोग करने की सलाह देती है। npm का अपना दस्तावेज़ कहता है एनपीएम सीआई यह मौजूदा लॉकफ़ाइल से इंस्टॉल करता है और यदि लॉकफ़ाइल और मैनिफ़ेस्ट मेल नहीं खाते हैं तो विफल हो जाता है, जो इसे CI के लिए सही डिफ़ॉल्ट बनाता है जब आप साइलेंट डिपेंडेंसी ड्रिफ्ट के बजाय निर्धारणीय इंस्टॉल्स चाहते हैं।OWASP चीट शीट श्रृंखला)

यह इसलिए मायने रखता है क्योंकि इंस्टॉल-टाइम हमले ठीक उसी अंतराल का फायदा उठाते हैं जो "मेरी अपेक्षित संस्करण" और "जो पैकेज मैंने अभी-अभी रिज़ॉल्व किया" के बीच होता है। एनपीएम सीआई यह हर सप्लाई चेन समस्या का समाधान नहीं करता, लेकिन यह सबसे आम दरवाजों में से एक को बंद कर देता है: CI के दौरान आश्चर्यजनक निर्भरता ग्राफ़ परिवर्तनों को। OWASP की मार्गदर्शन और npm का दस्तावेज़ीकरण इस बिंदु पर एकमत हैं।OWASP चीट शीट श्रृंखला)

जीवनचक्र स्क्रिप्ट्स के लिए भी यही सच है। OWASP की npm चीट शीट विशेष रूप से उल्लेख करती है। --स्क्रिप्ट्स को अनदेखा करें पैकेज इंस्टॉलेशन के दौरान दुर्भावनापूर्ण मॉड्यूल हमले की सतह को कम करने के एक तरीके के रूप में, क्योंकि इंस्टॉल हुक्स जैसे स्थापना के बाद एक ज्ञात दुरुपयोग मार्ग हैं। यह सलाह दुर्भावनापूर्ण Axios रिलीज़ों से सीधे तौर पर संबंधित है, जिन्होंने इंस्टॉल-समय के कोड को निष्पादित करने के लिए एक इंजेक्टेड डिपेंडेंसी का उपयोग किया था। हर वातावरण वैध पैकेजों को बाधित किए बिना स्क्रिप्ट्स को वैश्विक रूप से अक्षम नहीं कर सकता, लेकिन संवेदनशील समीक्षा पाइपलाइनों और क्वारंटाइन इंस्टॉल्स को अक्सर ऐसा करना चाहिए।OWASP चीट शीट श्रृंखला)

प्रकाशकों के लिए, npm का विश्वसनीय प्रकाशन दस्तावेज़ीकरण अब केंद्रीय पठन सामग्री है। npm विश्वसनीय प्रकाशन को CI/CD वर्कफ़्लो से OIDC-आधारित प्रकाशन के रूप में वर्णित करता है, जिससे लंबे समय तक चलने वाले npm टोकन की आवश्यकता समाप्त हो जाती है। दस्तावेज़ों में स्वचालित उत्पत्ति निर्माण का भी उल्लेख है और पारंपरिक टोकन की तुलना में विश्वसनीय प्रकाशन को पसंदीदा सुरक्षा मॉडल के रूप में प्रस्तुत किया गया है। यह बात और भी महत्वपूर्ण हो जाती है जब माइक्रोसॉफ्ट ने रिपोर्ट किया कि दुर्भावनापूर्ण Axios रिलीज़ परियोजना के सामान्य विश्वसनीय-प्रकाशक-समर्थित प्रवाह के बाहर प्रकाशित की गई थीं। (एनपीएम दस्तावेज़)

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

एक व्यावहारिक Node.js निर्भरता नीति अब "मासिक ऑडिट चलाएँ और अपडेट करें" जैसी कम और इस तरह की अधिक दिखती है:

{
  "scripts": {
    "deps:ci": "npm ci",
    "deps:review": "npm ci --ignore-scripts"
  },
  "overrides": {
    "axios": "1.13.5"
  }
}

और CI में, नीति अक्सर कोड जितनी ही महत्वपूर्ण होती है:

नाम: ci
ऑन:
  पुश:
  पुल_रिक्वेस्ट:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
 - uses: actions/checkout@v4
 - uses: actions/setup-node@v4
 with:
 node-version: 22
 - run: npm ci
 - run: npm test

यह एक पूर्ण सप्लाई चेन प्रोग्राम नहीं है, लेकिन यह मुख्य विचार को समेटता है: जो आप कर सकते हैं उसे फ्रीज करें, जो आपने इंस्टॉल किया है उसकी समीक्षा करें, और प्रकाशन तथा आर्टिफैक्ट वंशावली को तोड़ना कठिन बनाएं। Axios की घटना ने इसे 'चाहने योग्य' से मुख्यधारा की अपेक्षा में बदल दिया।एनपीएम दस्तावेज़)

Axios npm CVE, असली जोखिम आपकी आउटबाउंड ट्रस्ट सीमा है।

AI हैकर टूल मुफ्त में आज़माएँ >>

टीमों को अब क्या करना चाहिए

यदि आपको एक परिचालन निर्णय वृक्ष की आवश्यकता है, तो इसकी शुरुआत वर्गीकरण से होनी चाहिए। यदि समस्या CVE-2024-39338 या CVE-2025-27152 है, तो आपको पैच करना चाहिए और फिर हर उस जगह की समीक्षा करनी चाहिए जहाँ हमलावर-नियंत्रित इनपुट अनुरोध गंतव्य को प्रभावित कर सकता है। यदि समस्या CVE-2023-45857 है, तो पैच करें और फिर समीक्षा करें कि सुरक्षा-संवेदनशील हेडर कहाँ से व्युत्पन्न होते हैं और उन्हें कहाँ तक जाने की अनुमति है। यदि समस्या CVE-2025-58754 है, तो पैच करें और फिर रिक्वेस्ट लेयर से पहले गैर-HTTP स्कीम को अस्वीकार कर दें। यदि समस्या CVE-2026-25639 है, तो पैच करें और फिर अपनी ट्रस्ट बाउंड्री के बाहर से मनमाने कॉन्फ़िग-आकार के ऑब्जेक्ट स्वीकार करना बंद कर दें। (गिटहब)

यदि समस्या है axios@1.14.1 या 0.30.4इसे सामान्य डिपेंडेंसी रखरखाव की तरह न समझें। उन संस्करणों को इंस्टॉल करने वाले किसी भी वातावरण को संभावित रूप से समझौता-ग्रस्त मानें, सीक्रेट्स बदलें, बिल्ड और इंस्टॉलेशन के सबूतों की जांच करें, और किसी ज्ञात सुरक्षित संस्करण पर स्विच करें। यह माइक्रोसॉफ्ट की गाइडलाइन और सुरक्षा समुदाय की व्यापक घटना रिपोर्टिंग में स्पष्ट रूप से बताई गई है।माइक्रोसॉफ्ट)

यदि अलर्ट पर विवाद हो या उसे वापस ले लिया गया हो, तो उसे अंधाधुंध अनदेखा न करें और अंधाधुंध आगे न बढ़ाएं। रिकॉर्ड की स्थिति पढ़ें। निर्धारित करें कि समस्या प्रत्यक्ष है, अप्रत्यक्ष है, सैद्धांतिक है, विवादित है या वापस ली गई है। अच्छी निर्भरता प्रतिक्रिया हमेशा तेज़ी से आगे बढ़ने के बारे में नहीं होती। यह सही ढंग से वर्गीकृत करने के बारे में है ताकि आप गलत चीज़ को ठीक करने में समय बर्बाद न करें और वास्तविक सीमा विफलता को न चूकें।गिटहब)

अतिरिक्त पठन और संदर्भ लिंक

आधिकारिक पैकेज-साइड दृश्य के लिए, Axios GitHub सुरक्षा सलाह पृष्ठ सबसे अच्छा प्रारंभिक बिंदु है, विशेष रूप से वर्तमान में प्रकाशित सलाहों और उनकी प्रभावित तथा पैच की गई संस्करण श्रेणियों के लिए।गिटहब)

SSRF रिकॉर्ड्स के लिए, CVE-2024-39338 के लिए GitHub एडवाइजरी और NVD एंट्री पढ़ें, फिर CVE-2025-27152 के लिए GitHub एडवाइजरी और NVD एंट्री पढ़ें। ये दोनों मिलकर प्रोटोकॉल-रिलेटिव कन्फ्यूजन से एब्सोल्यूट-URL ओवरराइड तक के विकास को दिखाते हैं, जो Axios डेस्टिनेशन-कंट्रोल समस्या को समझने का सबसे स्पष्ट तरीका है। (गिटहब)

ब्राउज़र-साइड टोकन समस्या के लिए, CVE-2023-45857 के लिए GitHub एडवाइजरी और NVD प्रविष्टि आधिकारिक संदर्भ बने हुए हैं, और Axios का वर्तमान रिपॉजिटरी दस्तावेज़ीकरण XSRF टोकन के साथ यह समझने के लिए उपयोगी है कि सुधार के बाद मॉडल कैसे बदला। (गिटहब)

नोड-विशिष्ट डिनायल-ऑफ़-सर्विस पथों के लिए, CVE-2025-58754 के लिए एडवाइजरी और NVD प्रविष्टि पढ़ें, और CVE-2026-25639 के लिए एडवाइजरी के साथ-साथ रिलीज़ जानकारी पढ़ें। ये दोनों रिकॉर्ड सबसे ठोस प्रमाण हैं कि Axios सुरक्षा समीक्षा में केवल SSRF सिंक्स ही नहीं, बल्कि गैर-नेटवर्क पथ और कॉन्फ़िगरेशन इनजेक्शन पथ भी शामिल होने चाहिए।गिटहब)

रक्षात्मक इंजीनियरिंग के लिए, OWASP की SSRF रोकथाम चीट शीट, npm सुरक्षा चीट शीट, npm के दस्तावेज़ों के लिए पैकेज-लॉक.जेएसओएन, एनपीएम सीआई, ओवरराइड करता है, और विश्वसनीय प्रकाशन अधिकांश द्वितीयक ब्लॉग पोस्टों की तुलना में अधिक उपयोगी हैं क्योंकि वे निर्भरता घटनाओं को टिकाऊ नियंत्रणों में अनुवादित करते हैं। (OWASP चीट शीट श्रृंखला)

मार्च 2026 की दुर्भावनापूर्ण रिलीज़ घटना के लिए, माइक्रोसॉफ्ट का शमन दस्तावेज़ सबसे उपयोगी परिचालन संदर्भ है, विशेष रूप से होस्ट-समझौता मानसिकता, सुरक्षित डाउनग्रेड मार्गदर्शन, और इस बात के लिए कि दुर्भावनापूर्ण प्रकाशन परियोजना के सामान्य विश्वसनीय-प्रकाशक पैटर्न से भिन्न था। Snyk का घटना विश्लेषण इंस्टॉल-समय निर्भरता इंजेक्शन पथ को समझने के लिए भी मूल्यवान है।माइक्रोसॉफ्ट)

संबंधित Penligent पठन के लिए, सबसे सीधे प्रासंगिक आंतरिक लेख है एक्सियोस npm पर समझौता हुआ, दुर्भावनापूर्ण रिलीज़ों ने वास्तव में क्या किया, जो दीर्घकालिक Axios सीमा मॉडल के बजाय दुर्भावनापूर्ण रिलीज़ मैकेनिक्स पर ध्यान केंद्रित करके इस लेख को पूरक बनाता है। यदि आपका अगला कदम इन समीक्षा पैटर्न को चेकलिस्ट आइटम के रूप में छोड़ने के बजाय उन्हें सीमित, दोहराए जाने योग्य सत्यापन और साक्ष्य संग्रह में बदलना है, तो Penligent के सार्वजनिक उत्पाद पृष्ठ भी प्रासंगिक हैं। (पेनलिजेंट)

पोस्ट साझा करें:

ssh-keysign-pwn, The Linux fd theft bug behind CVE-2026-46333

ssh-keysign-pwn is the public name attached to CVE-2026-46333, a Linux kernel bug in the ptrace access-check path that can let

Fragnesia CVE-2026-46300 Turns Page Cache Into Root

Fragnesia CVE-2026-46300 is a Linux kernel local privilege escalation issue in the XFRM ESP-in-TCP attack surface. The practical risk is

Axios npm CVE, असली जोखिम आपकी आउटबाउंड ट्रस्ट सीमा है।

Axios npm CVE एक रिकॉर्ड नहीं है, यह विभिन्न विफलता मोड का एक मानचित्र है।

एक्सियोस वहीं रहता है जहाँ अनुप्रयोग विश्वास नेटवर्क विश्वास बन जाता है।

Axios SSRF की कहानी वास्तव में एक इंजीनियरिंग समस्या है जिसमें कई CVEs शामिल हैं।

CVE-2024-39338 और प्रोटोकॉल-रिलेटिव ट्रैप

CVE-2025-27152 और पूर्ण URL ओवरराइड समस्या

बेसयूआरएल कभी पॉलिसी इंजन क्यों नहीं था

CVE-2023-45857 वास्तव में हेडर प्रसारण अनुशासन के बारे में था।

Axios में खतरनाक गैर-नेटवर्क पथ भी हैं जो समीक्षा में हानिरहित दिखते हैं।

CVE-2025-58754 और डेटा URI सेवा अस्वीकृति

CVE-2026-25639 और mergeConfig क्रैश

हर Axios अलर्ट का मतलब यह नहीं होता कि Axios स्वयं ही दोषपूर्ण घटक है।

मार्च 2026 की दुर्भावनापूर्ण रिलीज़ों ने Axios पैकेज जोखिम के अर्थ को बदल दिया।

यह कैसे सत्यापित करें कि आपका कोड वास्तव में एक्सपोज़्ड है

बिल्ड ईविडेंस अकेले package.json से अधिक महत्वपूर्ण है।

संस्करण अपग्रेड आवश्यक हैं, लेकिन वे पूरी मरम्मत नहीं हैं।

सप्लाई चेन नियंत्रण अब एक्सियोस सुरक्षा वार्ता का हिस्सा हैं।

टीमों को अब क्या करना चाहिए

अतिरिक्त पठन और संदर्भ लिंक

संबंधित पोस्ट

ssh-keysign-pwn, The Linux fd theft bug behind CVE-2026-46333

Fragnesia CVE-2026-46300 Turns Page Cache Into Root