comerc/cve-2025-68664विस्तृत खुलासा CVE-2025-68664 का, LangChain core में एक गंभीर डिसीरियलाइज़ेशन भेद्यता जो निर्मित प्रॉम्प्ट और सीरियलाइज़ेशन प्रवाहों के माध्यम से गुप्त जानकारी के बहिर्वाह और संभावित RCE की अनुमति देती है।
लेखक: यार्डेन पोरात
Cyata अनुसंधान: LangChain में LangGrinch भेद्यता
प्रकाशित: https://cyata.ai/blog/langgrinch-langchain-core-cve-2025-68664/
कल LangChain ने एक गंभीर चेतावनी जारी की जिसमें मैंने langchain-core में पाई गई भेद्यता के बारे में बताया: CVE-2025-68664 / GHSA-c67j-w6g6-q2cm।
इस वर्ष की शुरुआत में, मेरा शोध "Vault Fault" कार्य में सीक्रेट मैनेजरों को हैक करने पर केंद्रित था – ऐसी प्रणालियाँ जो विशेष रूप से आपके सबसे संवेदनशील क्रेडेंशियल्स के चारों ओर सुरक्षा सीमा के रूप में डिज़ाइन की गई हैं। एक निष्कर्ष बार-बार दोहराया गया: जब कोई प्लेटफ़ॉर्म हमलावर द्वारा निर्मित डेटा को भरोसेमंद संरचना के रूप में संसाधित करता है, तो वह सीमा जल्दी टूट जाती है। इस बार, "टूटने" वाली प्रणाली आपका सीक्रेट मैनेजर नहीं है। यह एजेंट फ्रेमवर्क है जो उनका उपयोग कर सकता है।
यह भेद्यता विशेष ध्यान देने योग्य क्यों है:
यह कोर में है। यह कोई विशिष्ट टूल बग नहीं है, कोई एकीकरण का चरम मामला नहीं है, और "किसी सामुदायिक पैकेज ने कुछ अजीब किया" नहीं है। असुरक्षित API (dumps() / dumpd()) langchain-core में ही हैं।
प्रभाव का दायरा बहुत बड़ा है। डाउनलोड की मात्रा के अनुसार, langchain आज दुनिया में सबसे व्यापक रूप से तैनात AI फ्रेमवर्क घटकों में से एक है। दिसंबर 2025 के अंत तक, सार्वजनिक पैकेज टेलीमेट्री सैकड़ों मिलियन इंस्टॉलेशन दिखाती है, pepy.tech लगभग 847 मिलियन कुल डाउनलोड और pypistats पिछले महीने में लगभग 98 मिलियन डाउनलोड दिखाता है।
एक प्रॉम्प्ट कई तंत्र चला सकता है। यहाँ सबसे सामान्य वास्तविक दुनिया का रास्ता यह नहीं है कि "हमलावर आपको एक सीरियलाइज़्ड ब्लॉब भेजता है और आप load() कॉल करते हैं।" यह अधिक सूक्ष्म है: LLM आउटपुट additional_kwargs या response_metadata जैसे फ़ील्ड को प्रभावित कर सकते हैं, और ये फ़ील्ड सीरियलाइज़ हो सकते हैं और बाद में सामान्य फ्रेमवर्क फ़ंक्शंस जैसे स्ट्रीमिंग लॉग/इवेंट के माध्यम से डीसीरियलाइज़ हो सकते हैं। सरल शब्दों में, इसका मतलब है कि एक एकल टेक्स्ट प्रॉम्प्ट एक एक्सप्लॉइट शुरू कर सकता है जो अप्रत्याशित रूप से जटिल आंतरिक पाइपलाइन में कैस्केड होता है।
इसे पढ़ने से पहले, पैच पहले ही संस्करण 1.2.5 और 0.3.81 में जारी किए जा चुके हैं। यदि आप प्रोडक्शन में LangChain का उपयोग कर रहे हैं, तो यह जितना लगता है उससे अधिक जटिल है; कृपया जितनी जल्दी हो सके अपडेट करें।
LangChain एक विशेष आंतरिक सीरियलाइज़ेशन प्रारूप का उपयोग करता है जहाँ 'lc' मार्कर वाले शब्दकोश LangChain ऑब्जेक्ट का प्रतिनिधित्व करते हैं। भेद्यता यह थी कि dumps() और dumpd() उपयोगकर्ता-नियंत्रित शब्दकोशों को सही ढंग से एस्केप नहीं करते थे जिनमें आरक्षित कुंजी 'lc' शामिल थी।
इस प्रकार, जैसे ही हमलावर LangChain ऑर्केस्ट्रेशन लूप को 'lc' कुंजी सहित सामग्री को सीरियलाइज़ और बाद में डीसीरियलाइज़ करने के लिए मजबूर कर सकता है, वह एक असुरक्षित मनमाना ऑब्जेक्ट इंस्टैंशिएट कर सकता है, संभावित रूप से हमलावरों के अनुकूल कई रास्ते शुरू कर सकता है।
चेतावनी में 12 अलग-अलग असुरक्षित प्रवाह सूचीबद्ध हैं जो वास्तविक दुनिया के उपयोग के मामलों जैसे मानक इवेंट स्ट्रीमिंग, लॉगिंग, संदेश इतिहास/मेमोरी, या कैशिंग में अत्यंत सामान्य हैं:
सबसे विनाशकारी परिणामों में शामिल हैं:
पर्यावरण चर से सीक्रेट निकालना। चेतावनी नोट करती है कि यह secrets_from_env=True के साथ डीसीरियलाइज़ करने पर होता है। उल्लेखनीय रूप से, कल तक यह डिफ़ॉल्ट था। 🙂
पूर्व-अनुमोदित नामस्थानों (langchain_core, langchain_openai, langchain_aws, langchain_anthropic…) में ऑब्जेक्ट इंस्टैंशिएट करना, संभावित रूप से कंस्ट्रक्टरों में साइड इफ़ेक्ट (नेटवर्क कॉल, फ़ाइल ऑपरेशन आदि) उत्पन्न करना।
कुछ शर्तों के तहत, LangChain ऑब्जेक्ट का इंस्टैंशिएशन मनमाना कोड निष्पादन की ओर ले जा सकता है।
इसे CWE-502: अविश्वसनीय डेटा का डीसीरियलाइज़ेशन के तहत वर्गीकृत किया गया है, जिसमें CVSS CNA स्कोर 9.3 (गंभीर) है।
क्रिसमस की पूर्व संध्या पर, मैं सबसे कम उत्सवपूर्ण काम कर रहा था: सीरियलाइज़ेशन कोड को देख रहा था और पूछ रहा था "रुको… इसे भरोसेमंद क्यों माना जाता है?"
सुरक्षा अनुसंधान अक्सर बाहर से नाटकीय लगता है। वास्तव में यह आमतौर पर सावधानीपूर्वक पढ़ना, छोटी परिकल्पनाएँ और "यह अजीब है" क्षणों का धीमा संचय होता है।
यह वैसे ही शुरू हुआ जैसे Cyata में कई चीज़ें: एक सरल प्रश्न के साथ जो हम AI स्टैक का वास्तविक जोखिम मूल्यांकन करते समय लगातार पूछते हैं:
AI अनुप्रयोगों में विश्वास की सीमाएँ कहाँ हैं, और क्या डेवलपर्स वास्तव में जानते हैं कि ये सीमाएँ कहाँ हैं?
LangChain एक शक्तिशाली फ्रेमवर्क है, और अधिकांश आधुनिक फ्रेमवर्क की तरह, इसे जटिल संरचित डेटा स्थानांतरित करना होता है: संदेश, टूल कॉल, स्ट्रीमिंग इवेंट, ट्रेसेस, कैश और "रनेबल्स"।
पिछले शोध को देखते हुए, वहाँ पहले से ही LangChain टूल और एकीकरण का व्यापक शोध था, लेकिन मुख्य लाइब्रेरी में बहुत कम खोजें थीं।
मैंने शोध को उल्टा काम करके शुरू किया। दिलचस्प स्थानों (सिंक) को ढूँढना, फिर यह पता लगाना कि हमलावर उन तक कैसे पहुँच सकता है। डीसीरियलाइज़ेशन एक स्पष्ट लक्ष्य था।
मुझे कुछ महत्वपूर्ण खोजने में काफी समय लगा। लेकिन कुछ समय बाद मैंने पाया कि, हमलावर द्वारा नियंत्रित डीसीरियलाइज़ेशन प्रिमिटिव मानते हुए, मैं एक ब्लाइंड SSRF चला सकता था जिसका उपयोग पर्यावरण चर को बाहर निकालने के लिए किया जा सकता था (जल्द ही विस्तार से बताया जाएगा)। चूँकि परिणाम सीक्रेट्स के बहिर्गमन तक सीमित था, न कि मेरे मुख्य लक्ष्य RCE तक, मैंने डीसीरियलाइज़ेशन का ऑडिट जारी रखा और अपना समय लिया।
बग खराब कोड का एक टुकड़ा नहीं था, यह कोड की कमी था। dumps() बस उपयोगकर्ता-नियंत्रित शब्दकोशों को एस्केप नहीं करता था जिनमें 'lc' कुंजियाँ थीं। सीरियलाइज़ेशन पथ में लापता एस्केप, डीसीरियलाइज़ेशन में नहीं।
कुछ गलत देखना बहुत आसान है, कुछ की कमी देखना बहुत कठिन, खासकर जब आप load() का ऑडिट कर रहे हों, dumps() का नहीं। सबसे अधिक सावधानीपूर्वक समीक्षित AI फ्रेमवर्क में से एक में। ढाई साल।
वहाँ से, शोध एक संरचित अभ्यास बन गया:
यह पहचानना कि अविश्वसनीय सामग्री (मुख्य रूप से मनमाना शब्दकोश) सीरियलाइज़ेशन में कहाँ प्रवेश करती है (LLM आउटपुट, प्रॉम्प्ट इंजेक्शन, उपयोगकर्ता इनपुट, बाहरी उपकरण, निकाले गए दस्तावेज़)।
यह पहचानना कि ये सीरियलाइज़ किए गए डेटा कब डीसीरियलाइज़ होते हैं।
यह पहचानना कि मनमाना ऑब्जेक्ट इंस्टैंशिएशन से हमलावर क्या हासिल कर सकता है।
उस समय, मुख्य खोज जिम्मेदार रिपोर्ट के लिए पर्याप्त स्पष्ट और कार्रवाई योग्य थी: 'lc' कुंजी वाले शब्दकोशों के आसपास dumps() / dumpd() में एस्केपिंग में अंतर था।
चेतावनी ने बाद में वही कब्जा कर लिया जो हम अक्सर व्यवहार में देखते हैं: additional_kwargs और response_metadata जैसे फ़ील्ड LLM आउटपुट और प्रॉम्प्ट इंजेक्शन से प्रभावित हो सकते हैं, और ये फ़ील्ड कई प्रवाहों में सीरियलाइज़-डीसीरियलाइज़ हो सकते हैं।
LangChain टीम की प्रशंसा में: प्रतिक्रिया और उसके बाद की कार्रवाई निर्णायक थी, न केवल बग को पैच करना बल्कि उन डिफ़ॉल्ट को कसना भी जो उस दुनिया के लिए बहुत अधिक अनुमत थे जिसमें हम अब रह रहे हैं।
LangChain प्रोजेक्ट ने इस खोज के लिए $4,000 USD का इनाम देने का निर्णय लिया। huntr के अनुसार, वह प्लेटफ़ॉर्म जहाँ LangChain अपना बग बाउंटी प्रोग्राम चला रहा था, यह प्रोजेक्ट में अब तक दी गई सबसे बड़ी राशि होगी, अब तक का इनाम $125 तक था।
LangChain कुछ ऑब्जेक्ट को संरचित शब्दकोश प्रारूप का उपयोग करके सीरियलाइज़ करता है। 'lc' कुंजी का उपयोग आंतरिक रूप से यह इंगित करने के लिए किया जाता है "यह एक सीरियलाइज़्ड LangChain संरचना है," न कि केवल मनमाना उपयोगकर्ता डेटा।
यह एक सामान्य पैटर्न है, लेकिन यह एक सुरक्षा इनवेरिएंट बनाता है: कोई भी उपयोगकर्ता डेटा जिसमें 'lc' हो सकता है, उसे सावधानी से संभाला जाना चाहिए। अन्यथा, हमलावर एक शब्दकोश बना सकता है जो आंतरिक ऑब्जेक्ट "जैसा दिखता है" और डीसीरियलाइज़र को धोखा देकर उसे मान दे सकता है।
पैच अद्यतन दस्तावेज़ में इरादे को स्पष्ट करता है: सीरियलाइज़ेशन के दौरान, 'lc' कुंजी वाले सरल शब्दकोशों को लपेटकर एस्केप किया जाता है।
यह इन शब्दकोशों को डीसीरियलाइज़ेशन के दौरान वास्तविक सीरियलाइज़्ड LangChain ऑब्जेक्ट के साथ भ्रमित होने से रोकता है।
LangChain के load()/loads() फ़ंक्शन मनमाना वर्ग इंस्टैंशिएट नहीं करते – वे एक श्वेतसूची के विरुद्ध जाँच करते हैं जो नियंत्रित करती है कि किन वर्गों को डीसीरियलाइज़ किया जा सकता है। डिफ़ॉल्ट रूप से, यह श्वेतसूची langchain_core, langchain_openai, langchain_aws और अन्य इकोसिस्टम पैकेजों के वर्गों को शामिल करती है।
यहाँ पेच है: श्वेतसूची में अधिकांश वर्गों में हानिरहित कंस्ट्रक्टर होते हैं। शोषण योग्य रास्ते खोजने के लिए इकोसिस्टम में उन वर्गों की खोज करनी पड़ी जो इंस्टैंशिएशन पर कुछ महत्वपूर्ण करते हैं। जो मैंने पाए, वे नीचे विस्तार से वर्णित हैं, लेकिन और भी हो सकते हैं जो खोजे जाने की प्रतीक्षा कर रहे हैं।
LangChain का loads() फ़ंक्शन एक secret प्रकार का समर्थन करता है जो डीसीरियलाइज़ेशन के दौरान पर्यावरण चर से मानों को हल करता है। पैच से पहले, यह secrets_from_env सुविधा डिफ़ॉल्ट रूप से सक्षम थी:
if (
value.get("lc") == 1
and value.get("type") == "secret"
and value.get("id") is not None
):
[key] = value["id"]
if key in self.secrets_map:
return self.secrets_map[key]
if self.secrets_from_env and key in os.environ and os.environ[key]:
return os.environ[key] # <-- पर्यावरण चर लौटाना
return None
यदि डीसीरियलाइज़ किया गया ऑब्जेक्ट हमलावर को वापस कर दिया जाता है, जैसे LLM संदर्भ के अंदर संदेश इतिहास, तो यह पर्यावरण चर लीक कर सकता है।
लेकिन अधिक दिलचस्प रास्ता अप्रत्यक्ष प्रॉम्प्ट इंजेक्शन है। यहाँ तक कि एक हमलावर जो कोई LLM प्रतिक्रिया नहीं देख सकता, सही वर्ग इंस्टैंशिएट करके सीक्रेट बाहर निकाल सकता है। ChatBedrockConverse langchain_aws से loads की डिफ़ॉल्ट श्वेतसूची में है और निर्माण के समय GET अनुरोध करता है। GET एंडपॉइंट हमलावर द्वारा नियंत्रित होता है, और एक विशिष्ट HTTP हेडर secrets_from_env फ़ंक्शन के माध्यम से पर्यावरण चर से भरा जा सकता है।
यह वैलिडेटर तब चलता है जब ChatBedrockConverse इंस्टैंशिएट होता है। हमलावर endpoint_url को नियंत्रित करता है, जो बाहरी अनुरोध को ट्रिगर करता है। secrets_from_env के संयोजन में, aws_access_key_id हेडर किसी भी पर्यावरण चर से भरा जा सकता है – न केवल AWS कुंजियाँ।
हम जानबूझकर यहाँ तैयार एक्सप्लॉइट प्रकाशित नहीं कर रहे हैं ताकि सुरक्षा टीमों को समय मिल सके। कुछ महीनों में, Huntr साइट उन्हें स्वचालित रूप से प्रकाशित करेगी।
loads() की डिफ़ॉल्ट श्वेतसूची में PromptTemplate वर्ग है। यह वर्ग टेम्पलेट से एक प्रॉम्प्ट बनाता है, और उपलब्ध टेम्पलेट प्रारूपों में से एक Jinja2 है।
जब टेम्पलेट Jinja2 के साथ रेंडर होता है, तो मनमाना Python कोड निष्पादित किया जा सकता है। हमें इसे केवल loads() फ़ंक्शन से सीधे चलाने का कोई तरीका नहीं मिला, लेकिन यदि डीसीरियलाइज़ किए गए ऑब्जेक्ट पर बाद में कॉल रेंडरिंग शुरू करता है, तो कोड निष्पादन होता है।
हमें संदेह है कि loads() से सीधे कोड निष्पादन के रास्ते हो सकते हैं, लेकिन हमने अभी तक किसी की पुष्टि नहीं की है। यदि आपके पास कोई ठोस विचार या परीक्षण के लायक सुराग है, तो हमें सुनकर खुशी होगी – यह वही स्थान है जहाँ सुरक्षा समुदाय परिकल्पनाओं को सबूत में बदलने में मदद करता है। 🤝
यह भी ध्यान देने योग्य है: पिछले संस्करणों में, Chain वर्ग भी श्वेतसूची में था। इस वर्ग में विशेष क्षमताएँ थीं जो टेम्पलेट रेंडरिंग की ओर प्रवाह की अनुमति दे सकती थीं।
यदि आपका एप्लिकेशन langchain-core के असुरक्षित संस्करणों का उपयोग करता है, तो यह संभावित रूप से प्रभावित है। यहाँ कुछ सबसे सामान्य असुरक्षित पैटर्न हैं (कुल 12 प्रवाह पहचाने गए):
फिर भी, सिस्टम का व्यवहार काफी जटिल है, इसलिए यह जोखिम भरा है कि एक त्वरित कोड समीक्षा प्रत्येक साध्य संस्करण को प्रकट करेगी। पैच किए गए संस्करण में अपडेट करना सबसे सुरक्षित है और जब तक ऐसा न करें तब तक सुरक्षित न मानें।
साथ ही, चेतावनी उस बात पर ध्यान देती है जिसे मैं सबसे महत्वपूर्ण वास्तविक दुनिया का बिंदु मानता हूँ:
सबसे सामान्य हमला वेक्टर LLM प्रतिक्रिया फ़ील्ड जैसे additional_kwargs या response_metadata के माध्यम से होता है, जिन्हें प्रॉम्प्ट इंजेक्शन के माध्यम से नियंत्रित किया जा सकता है और फिर स्ट्रीमिंग ऑपरेशन में सीरियलाइज़/डीसीरियलाइज़ किया जा सकता है।
यह ठीक उसी प्रकार का "AI क्लासिक सुरक्षा से मिलता है" अंतर्संबंध है जहाँ संगठन अचंभित हो जाते हैं। LLM आउटपुट अविश्वसनीय इनपुट है। यदि आपका फ्रेमवर्क उस आउटपुट के कुछ हिस्सों को बाद में संरचित ऑब्जेक्ट के रूप में संसाधित करता है, तो आपको मान लेना चाहिए कि हमलावर उन्हें आकार देने का प्रयास करेंगे।
langchain-core को पैच किए गए संस्करण में अपडेट करें। यदि आप langchain, langchain-community या अन्य इकोसिस्टम पैकेज का उपयोग करते हैं, तो जाँचें कि प्रोडक्शन वातावरण में langchain-core का कौन सा संस्करण वास्तव में स्थापित है।
additional_kwargs, response_metadata, टूल आउटपुट, निकाले गए दस्तावेज़ और संदेश इतिहास को अविश्वसनीय मानें जब तक कि अन्यथा सिद्ध न हो। यह विशेष रूप से महत्वपूर्ण है यदि आप लॉग/इवेंट स्ट्रीम करते हैं और बाद में उन्हें लोडर के साथ पुनर्जलीकृत करते हैं।
अपडेट के बाद भी, सिद्धांत का पालन करें: सीरियलाइज़्ड इनपुट पर भरोसा किए बिना पर्यावरण चर से सीक्रेट रिज़ॉल्यूशन सक्षम न करें। प्रोजेक्ट ने डिफ़ॉल्ट को एक कारण से बदल दिया है।
मेरी रिपोर्ट के आधार पर, LangChainJS (GHSA-r399-636x-v7f6 / CVE-2025-68665) में एक निकट से संबंधित चेतावनी है जिसमें समान तंत्र हैं: सीरियलाइज़ेशन के दौरान 'lc' मार्कर भ्रम, जो कुछ कॉन्फ़िगरेशन में सीक्रेट निष्कर्षण और असुरक्षित इंस्टैंशिएशन की अनुमति देता है।
यदि आपका संगठन Python और JavaScript दोनों LangChain स्टैक चलाता है, तो इसे एक अनुस्मारक के रूप में लें कि पैटर्न इकोसिस्टम के बीच फैलता है: मार्कर सीरियलाइज़ेशन, अविश्वसनीय मॉडल आउटपुट, और बाद में डीसीरियलाइज़ेशन – यह जोखिम का एक आवर्ती रूप है।
हम उस चरण में प्रवेश कर रहे हैं जहाँ AI एजेंट फ्रेमवर्क प्रोडक्शन सिस्टम के अंदर महत्वपूर्ण बुनियादी ढाँचा बन रहे हैं। सीरियलाइज़ेशन प्रारूप, ऑर्केस्ट्रेशन पाइपलाइन, टूल निष्पादन, कैश और ट्रेसिंग अब "प्लंबिंग" नहीं हैं – वे आपकी सुरक्षा सीमा का हिस्सा हैं।
यह भेद्यता केवल "लाइब्रेरी में बग" नहीं है। यह एक बड़े पैटर्न का केस स्टडी है:
आपका एप्लिकेशन डेटा डीसीरियलाइज़ कर सकता है जिसे वह सुरक्षित रूप से उत्पादित मानता है।
लेकिन उस सीरियलाइज़्ड आउटपुट में ऐसे फ़ील्ड हो सकते हैं जो अविश्वसनीय स्रोतों (प्रॉम्प्ट इंजेक्शन द्वारा आकारित LLM आउटपुट सहित) द्वारा प्रभावित होते हैं।
आंतरिक मार्कर के रूप में उपयोग की जाने वाली एक एकल आरक्षित कुंजी सीक्रेट और निष्पादन से सटे व्यवहारों में टर्निंग पॉइंट बन सकती है।
Cyata में, हमारा काम संगठनों को AI सिस्टम के आसपास दृश्यता, जोखिम मूल्यांकन, नियंत्रण और शासन बनाने में मदद करना है – क्योंकि यदि आप जल्दी से उत्तर नहीं दे सकते कि एजेंट कहाँ चल रहे हैं, कौन से संस्करण तैनात हैं और इसके माध्यम से क्या डेटा बह रहा है, तो आप प्रभावी रूप से अंधे उड़ रहे हैं जब ऐसी चेतावनियाँ आती हैं।
यदि आप एक सुरक्षा नेता हैं जो यह पढ़ रहे हैं, तो यहाँ एक असुविधाजनक सच्चाई है:
अधिकांश संगठन अब जल्दी और आत्मविश्वास से उत्तर नहीं दे सकते:
हम एजेंटों का उपयोग कहाँ करते हैं?
प्रोडक्शन में कौन से संस्करण तैनात हैं?
किन सेवाओं की संवेदनशील सीक्रेट तक पहुँच है?
LLM आउटपुट इन सीमाओं को कहाँ पार करते हैं?
यह "डेवलपर की समस्या" नहीं है। यह दृश्यता और शासन की समस्या है।
और यहीं पर Cyata आता है।
Cyata में, हम व्यावहारिक परिणाम पर ध्यान केंद्रित करते हैं: निर्माताओं को धीमा किए बिना AI और एजेंट जोखिम को कम करना। इस तरह की भेद्यताएँ शायद ही कभी "सिर्फ पैच" होती हैं। वे उन अंतरालों को उजागर करती हैं कि कैसे टीमें पता लगाती हैं कि एजेंट कहाँ चल रहे हैं, वास्तविक विश्वास सीमाओं को समझती हैं, और तेज़ गति वाले फ्रेमवर्क में सुरक्षित डिफ़ॉल्ट सुनिश्चित करती हैं।
जानें कि क्या चल रहा है, कहाँ और यह कैसे जुड़ा है।
CVE के पहले प्रश्न का तुरंत उत्तर दें: क्या हम प्रभावित हैं, और किन प्रवाहों में?
एजेंट रनटाइम और वातावरण (IDE, CI, सेवाएँ, कार्य कार्य, होस्टिंग एजेंट) के बीच एकीकरण का पता लगाएँ।
उपयोग में आने वाले फ्रेमवर्क, पैकेज और संस्करणों को ट्रैक करें।
वास्तविक प्रभाव दायरे के आधार पर प्राथमिकता दें, न कि केवल "लाइब्रेरी मौजूद है।"
तेज़ ट्रायज बनाए रखें: क्या इंटरनेट-फेसिंग है, क्या सीक्रेट को छूता है, क्या बढ़े हुए विशेषाधिकारों के साथ चलता है।
सबसे अधिक जोखिम वाले रास्तों की पहचान करें: अविश्वसनीय सामग्री विशेषाधिकार प्राप्त संदर्भों (सीक्रेट वाली सेवाएँ, व्यापक टूल अनुमतियाँ, प्रोडक्शन नेटवर्क एक्सेस) में प्रवाहित होती है।
हाइलाइट करें कि "संरचित फ़ील्ड" विश्वास सीमाओं (मेटाडेटा, टूल आउटपुट, स्ट्रीमिंग इवेंट, कैश किए गए आर्टिफैक्ट) को कहाँ पार कर सकती हैं।
हर जगह प्रत्येक निर्भरता को पैच करने से पहले भी जोखिम कम करें।
सुरक्षित परिचालन डिफ़ॉल्ट को प्रोत्साहित करें: न्यूनतम विशेषाधिकार, अलगाव सीमाएँ और नीति जाँच जो टीमों के बीच स्केल करती हैं।
जोखिम भरे पैटर्न के आसपास गेटवे लागू करें (जैसे: अविश्वसनीय डेटा का डीसीरियलाइज़ेशन, अनुमत ऑब्जेक्ट पुनर्जीवन, असुरक्षित स्ट्रीमिंग-से-कैश-से-रीहाइड्रेट प्रवाह)।
अविश्वसनीय संदर्भों में संवेदनशील क्षमताओं को गेट या सीमित करें (जैसे: पर्यावरण से सीक्रेट एक्सेस, उच्च-विशेषाधिकार वाला टूल निष्पादन, या विशेषाधिकार प्राप्त वर्कर्स में जोखिम भरे कोड पथ चलाना)।
"एजेंटों का सुरक्षित उपयोग" को दोहराने योग्य, ऑडिटेबल और बहाव से कठिन बनाएँ।
अनुमोदित फ्रेमवर्क, संस्करण और कॉन्फ़िगरेशन के लिए नीतियाँ परिभाषित करें।
मालिकों और औचित्य के साथ समय-सीमित अपवादों को ट्रैक और सीमित करें।
समय के साथ बहाव और जोखिम भरे फ़ीचर उपयोग की निगरानी करें, सुरक्षा समीक्षाओं और अनुपालन का समर्थन करने वाले ऑडिट ट्रेल के साथ।
जब क्रिसमस की चेतावनी आती है, तो लक्ष्य वीरता नहीं है – यह वास्तविक इन्वेंट्री और लागू गेटवे द्वारा समर्थित एक शांत, नियंत्रित प्रतिक्रिया है।
रिपोर्ट Huntr के माध्यम से भेजी गई – 4 दिसंबर 2025
LangChain अनुरक्षकों द्वारा स्वीकार किया गया – 5 दिसंबर 2025
चेतावनी और CVE प्रकाशित – 24 दिसंबर 2025