FlawOpen

flawopen.com/AI Security/langgraph-js-custom-auth-cross-user-store-access

● CWE-639 / CWE-863 · CVSS v4 8.6[1] · उच्च
सुरक्षा अनुसंधान · FlawOpen

LangGraph JS Auth: Store में दूसरे यूज़र का डेटा

JS/TS custom-auth से Store namespace बदलने पर langgraph-api <0.15.0 यह बदलाव खो सकता था। इससे दूसरे यूज़र का डेटा खुल सकता था; 0.15.0 पर अपडेट करें।[1], [2]

CVSS वेक्टरCVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N[1]
💡 आसान भाषा में (ELI5)

मान लें पुस्तकालयाध्यक्ष आपका कार्ड जाँचकर दूसरी मेज़ से किताब मँगाता है। दूसरी मेज़ आपके शेल्फ़ का नंबर लिखती है, लेकिन हस्तांतरण में बदलाव खो जाता है और आगंतुक द्वारा शुरू में बताया गया शेल्फ़ इस्तेमाल होता है। प्रभावित JavaScript/TypeScript प्रमाणीकरण पथ में authorization runtime और Store operation के बीच namespace rewrite खो सकता था। सुधार अधिकृत namespace को आगे पहुँचाकर Store उपयोग से पहले जाँचता है।[1]

इस पेज के मुख्य शब्द

GHSA-4hm6-w6qq-w73v
LangGraph की उच्च-गंभीरता वाली सलाह, 28 सितंबर 2026 को प्रकाशित। कोई CVE नहीं दिया गया। प्रभावित पैकेज langgraph-api है; सुधार 0.15.0 में है।[1]
Store namespace
LangGraph Store रिकॉर्ड को समूहित करने वाला पदानुक्रमित नाम। डेटा अलग रखने के लिए इसमें अक्सर उपयोगकर्ता या tenant की पहचान रखी जाती है।[1]
Custom authorization handler
ऐप्लिकेशन कोड जो तय करता है कि प्रमाणित अनुरोध संसाधन तक पहुँच सकता है या नहीं; Store operation से पहले यह namespace बदल भी सकता है।[1]
CWE-639 / CWE-863
उपयोगकर्ता-नियंत्रित key से authorization bypass और गलत authorization। handler की namespace सीमा लागू न होना इसका कारण है।[1], [3], [4]

फ्रेमवर्क मैपिंग

  • इस गाइड में बताई गई कमजोरी के लिए CWE संदर्भ: CWE-639 CWE-863

हमले का चरण-दर-चरण प्रवाह

चरण 1

जाँचें कि deployment दायरे में है

देखें कि langgraph-api >=0.1.2 और <0.15.0 है और सर्वर JavaScript या TypeScript custom-auth handler का उपयोग करता है।[1]

चरण 2

Namespace rewrite खोजें

Handler अनुरोधित namespace को प्रमाणित उपयोगकर्ता की पहचान जोड़ने या लागू करने के लिए बदलता है, जबकि उसे अपनी सीमा से बाहर अनुरोध अस्वीकार करना चाहिए।[1]

चरण 3

Authorization परिणाम runtime सीमा पार करता है

प्रभावित संस्करणों में namespace बदलाव Store operation तक नहीं पहुँच सकता। अनुरोधकर्ता द्वारा दिया मूल namespace इस्तेमाल हो सकता है।[1]

चरण 4

प्रमाणित उपयोगकर्ता दूसरे namespace को लक्षित करता है

सामान्य खाता अपने namespace के बाहर Store रिकॉर्ड पर operation माँग सकता है। सलाह में read, overwrite, search और delete संभावित प्रभाव बताए गए हैं।[1]

चरण 5

अपग्रेड करें या unauthorized namespace रोकें

langgraph-api>=0.15.0 पर जाएँ। तत्काल अपग्रेड संभव न हो तो हर Store action में unauthorized namespace अस्वीकार करें और जाँचें कि Store को केवल अधिकृत namespace मिले।[1], [2]

मूल कारण विश्लेषण (Root Cause)

LangGraph maintainers की 28 सितंबर 2026 की GHSA सलाह langgraph-api >=0.1.2 और <0.15.0 में दोष बताती है, जब ये सभी शर्तें पूरी हों: deployment JavaScript या TypeScript custom authentication उपयोग करे; Store authorization handler मौजूदा उपयोगकर्ता तक डेटा सीमित करने के लिए अनुरोधित namespace rewrite करे; सामान्य प्रमाणित उपयोगकर्ता Store operations भेज सके; और कई उपयोगकर्ताओं का डेटा उस authorization path से गुज़रे। सलाह के अनुसार Python custom-auth handlers प्रभावित नहीं हैं। ऐसे JavaScript/TypeScript handlers भी प्रभावित नहीं हैं जो unauthorized namespace को rewrite करने के बजाय अस्वीकार करते हैं। handler का namespace बदलाव runtime सीमा पार करते समय खो सकता था, जिससे Store operation मूल अनुरोधित namespace इस्तेमाल करता। प्रमाणित उपयोगकर्ता अपने अधिकृत namespace के बाहर रिकॉर्ड पढ़, बदल, खोज या मिटा सकता था। इससे login bypass नहीं होता और यह unauthenticated remote attack नहीं है। सलाह इसे High, CVSS 4.0 8.6 बताती है तथा CWE-639 और CWE-863 देती है। संस्करण 0.15.0 handler के बदलाव सीमा पार ले जाता है, परिणामी namespace की जाँच करता है, और malformed या सुरक्षित रूप से लागू न होने वाले बदलावों को अस्वीकार करता है। अपग्रेड तक maintainer की workaround हर Store action में unauthorized namespace को अस्वीकार करना है। कोड डेटा प्रवाह का छोटा TypeScript उदाहरण है, SDK स्रोत कोड नहीं।[1]

सोर्स कोड: कमज़ोर बनाम सुरक्षित कार्यान्वयन

यह छोटा TypeScript उदाहरण सीमा-अनुबंध दिखाता है; फ़ंक्शन नाम और परिणाम का रूप केवल उदाहरण हैं, LangGraph SDK का स्रोत कोड नहीं। सलाह पुष्टि करती है कि JS/TS authorization बदलाव Store operation से पहले खो सकते थे, लेकिन यही सटीक आंतरिक implementation प्रकाशित नहीं करती। इसलिए कमजोर पक्ष केवल दस्तावेज़ित invariant दिखाता है: Store अधिकृत namespace के बजाय अनुरोध वाला namespace इस्तेमाल करता है। ठीक किया गया पक्ष अधिकृत परिणाम लेता और सत्यापित करता है। Maintainer की दस्तावेज़ित workaround हर Store action में unauthorized namespace को rewrite करने के बजाय अस्वीकार करना है।[1]

सोर्स अंश: LangGraph API authorization से Store तक की सीमा — संक्षिप्त उदाहरण-अनुबंध

कमज़ोर कार्यान्वयन
type StoreRequest = { namespace: string[]; key: string };
type AuthorizationResult = { allowed: boolean; namespace: string[] };

async function readStore(userId: string, request: StoreRequest) {
  const authorization = await authorizeStore(userId, request); // Illustrative bridge contract.
  return store.get(request.namespace, request.key); // The bridge drops the authorized result.
}
सुरक्षित और सुदृढ़ फ़िक्स
type StoreRequest = { namespace: string[]; key: string };
type AuthorizationResult = { allowed: boolean; namespace: string[] };

async function readStore(userId: string, request: StoreRequest) {
  const authorization = await authorizeStore(userId, request); // Illustrative bridge contract.
  if (!authorization.allowed) throw new Error("forbidden");
  const namespace = validateAuthorizedNamespace(userId, authorization.namespace);
  return store.get(namespace, request.key); // Apply the authorized result.
}

इंजीनियरिंग और सिस्टम सुरक्षा चेकलिस्ट

स्रोत

← AI Security Directory →