comerc/cve-2025-68664إفصاح مفصل عن CVE-2025-68664، وهي ثغرة حرجة في إلغاء التسلسل في جوهر LangChain تسمح بتسريب الأسرار واحتمال تنفيذ تعليمات برمجية عن بُعد عبر مطالبات مصممة وتدفقات تسلسلية.
المؤلف: ياردن بورات
بحث Cyata: ثغرة LangGrinch في LangChain
نُشر على: 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 هو أحد أكثر مكونات إطار عمل الذكاء الاصطناعي انتشارًا في العالم اليوم. حتى نهاية ديسمبر 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 تدفقًا مختلفًا معرضًا للخطر وهي شائعة جدًا في حالات الاستخدام الواقعية مثل تدفق الأحداث القياسي، والتسجيل، وسجل الرسائل/الذاكرة، أو التخزين المؤقت:
تشمل العواقب الأكثر تدميراً:
يُصنف هذا تحت CWE-502: إلغاء تسلسل البيانات غير الموثوقة، بتقييم CVSS CNA 9.3 (حرج).
عشية عيد الميلاد، كنت أقوم بأقل الأعمال احتفالية: أنظر إلى كود التسلسل وأتساءل "انتظر… لماذا يعتبر هذا موثوقًا؟"
غالبًا ما تبدو أبحاث الأمن درامية من الخارج. في الواقع، هي عادة قراءة متأنية، وافتراضات صغيرة، وتراكم بطيء للحظات "هذا غريب".
بدأ هذا كما تفعل أشياء كثيرة في Cyata: بسؤال بسيط نطرحه باستمرار عند تقييم مجموعات الذكاء الاصطناعي للمخاطر الحقيقية: أين توجد حدود الثقة في تطبيقات الذكاء الاصطناعي، وهل يعرف المطورون حقًا أين توجد هذه الحدود؟
LangChain هو إطار عمل قوي، ومثل معظم الأطر الحديثة، يجب عليه نقل بيانات منظمة معقدة: الرسائل، واستدعاءات الأدوات، وأحداث التدفق، والتتبعات، والمخازن المؤقتة، و 'المجرى' (runnables).
بالنظر إلى الأبحاث السابقة، كان هناك بالفعل بحث واسع حول أدوات وتكاملات LangChain، ولكن نادرًا ما كانت هناك اكتشافات في المكتبة الأساسية.
بدأت البحث بالعمل بالاتجاه المعاكس. إيجاد الأماكن المثيرة للاهتمام (المستقبلات)، ثم معرفة كيف يمكن للمهاجم الوصول إليها. كان إلغاء التسلسل هدفًا واضحًا.
استغرق الأمر مني وقتًا طويلاً لأجد شيئًا ذا قيمة. لكن بعد فترة، وجدت أنه بافتراض وجود بدائية إلغاء تسلسل يتحكم بها المهاجم، يمكنني تشغيل SSRF أعمى يمكن استخدامه لتسريب متغيرات البيئة (سيتم شرحه بالتفصيل قريبًا). نظرًا لأن النتيجة كانت محدودة بتسريب الأسرار وليس هدفي الرئيسي RCE، واصلت تدقيق إلغاء التسلسل وأخذت وقتي.
لم يكن الخلل قطعة من كود سيئ، بل كان غياب كود. dumps() ببساطة لم تقم بإفلات القواميس التي يتحكم بها المستخدم والتي تحتوي على مفاتيح 'lc'. الإفلات المفقود كان في مسار التسلسل، وليس إلغاء التسلسل.
من الأسهل بكثير ملاحظة شيء خاطئ بدلاً من ملاحظة غياب شيء ما، خاصة عندما تقوم بتدقيق load() وليس dumps(). في أحد أكثر أطر الذكاء الاصطناعي تدقيقًا. عامين ونصف.
من هناك، أصبح البحث تمرينًا منظمًا:
في تلك المرحلة، كان الاكتشاف الرئيسي واضحًا وقابلًا للتنفيذ للإبلاغ المسؤول: كان هناك فجوة في الإفلات في dumps() / dumpd() حول القواميس ذات المفتاح 'lc'.
التقط التحذير لاحقًا ما نراه غالبًا في الممارسة: حقول مثل additional_kwargs و response_metadata يمكن أن تتأثر بمخرج LLM وحقن المطالبات، ويمكن أن تخضع هذه الحقول للتسلسل وإلغاء التسلسل في العديد من التدفقات.
ولفريق LangChain الفضل: كان الرد والإجراءات اللاحقة حاسمة، ليس فقط لتصحيح الخلل ولكن أيضًا لتشديد الإعدادات الافتراضية التي كانت متساهلة للغاية بالنسبة للعالم الذي نعيش فيه الآن.
قرر مشروع LangChain منح مكافأة قدرها 4,000 دولار أمريكي لهذا الاكتشاف. وفقًا لـ huntr، المنصة التي أدارت من خلالها LangChain برنامج المكافآت، سيكون هذا أكبر مبلغ يُمنح على الإطلاق في المشروع، حيث كانت المكافآت السابقة تصل إلى 125 دولارًا.
يقوم LangChain بتسلسل كائنات معينة باستخدام تنسيق قاموس منظم. يستخدم المفتاح 'lc' داخليًا للإشارة إلى 'هذا هيكل LangChain مسلسل'، وليس مجرد بيانات مستخدم عشوائية.
هذا نمط شائع، لكنه يخلق ثابت أمان: يجب معالجة أي بيانات مستخدم قد تحتوي على 'lc' بحذر. وإلا، يمكن للمهاجم إنشاء قاموس 'يبدو وكأنه' كائن داخلي ويخدع مفكك التسلسل ليعطيه قيمة.
يجعل التصحيح النية واضحة في الوثائق المحدثة: أثناء التسلسل، يتم إفلات القواميس البسيطة التي تحتوي على المفتاح 'lc' عن طريق تغليفها. يمنع هذا الخلط بين هذه القواميس وكائنات LangChain المسلسلة الفعلية أثناء إلغاء التسلسل.
لا تقوم وظائف load()/loads() في LangChain بإنشاء فئات عشوائية – فهي تتحقق من قائمة بيضاء تتحكم في الفئات التي يمكن إلغاء تسلسلها. افتراضيًا، تتضمن هذه القائمة البيضاء فئات من langchain_core و langchain_openai و langchain_aws وحزم أخرى في النظام البيئي.
وإليك المهم: معظم الفئات في القائمة البيضاء لها منشئات غير ضارة. يتطلب إيجاد مسارات قابلة للاستغلال البحث في النظام البيئي عن الفئات التي تفعل شيئًا ذا معنى عند إنشائها. تلك التي وجدتها موصوفة بالتفصيل أدناه، ولكن قد يكون هناك أخرى تنتظر الاكتشاف.
تدعم وظيفة loads() في LangChain النوع 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 environment variable
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، والتي يمكن التحكم فيها من خلال حقن المطالبات ثم تسلسلها/إلغاء تسلسلها في عمليات التدفق.
هذا هو بالضبط نوع التقاطع حيث 'يلتقي الذكاء الاصطناعي بالأمن الكلاسيكي'، حيث تتفاجأ المؤسسات. مخرج LLM هو إدخال غير موثوق. إذا كان إطار عملك يعالج أجزاء من هذا المخرج ككائنات منظمة لاحقًا، يجب أن تفترض أن المهاجمين سيحاولون تشكيلها.
قم بتحديث langchain-core إلى الإصدار المصحح. إذا كنت تستخدم langchain، أو langchain-community، أو حزم أخرى في النظام البيئي، تحقق من إصدار langchain-core المثبت فعليًا في بيئات الإنتاج.
تعامل مع additional_kwargs و response_metadata ومخرجات الأدوات والمستندات المستخلصة وسجل الرسائل على أنها غير موثوقة ما لم يثبت عكس ذلك. هذا مهم بشكل خاص إذا كنت تبث السجلات/الأحداث ثم تعيد ترطيبها باستخدام محمل (loader).
حتى بعد التحديث، التزم بالمبدأ: لا تفعل حل الأسرار من متغيرات البيئة إذا كنت لا تثق في الإدخال المسلسل. قام المشروع بتغيير الإعدادات الافتراضية لسبب.
بناءً على تقريري، هناك تحذير وثيق الصلة في LangChainJS (GHSA-r399-636x-v7f6 / CVE-2025-68665) بآليات مماثلة: ارتباك العلامة 'lc' أثناء التسلسل، مما يسمح باستخراج الأسرار والإنشاء غير الآمن في تكوينات معينة.
إذا كانت مؤسستك تشغل مكدسات LangChain لكل من Python و JavaScript، فاعتبر هذا تذكيرًا بأن النمط يمتد عبر الأنظمة البيئية: التسلسل بالعلامات، ومخرج النموذج غير الموثوق، وإلغاء التسلسل اللاحق – هذا شكل متكرر من المخاطر.
نحن ندخل مرحلة حيث تصبح أطر عمل وكلاء الذكاء الاصطناعي بنية تحتية حاسمة داخل أنظمة الإنتاج. تنسيقات التسلسل، وخطوط التنسيق، وتنفيذ الأدوات، والمخازن المؤقتة، والتتبع لم تعد 'سباكة' – إنها جزء من حدود الأمان الخاصة بك.
هذه الثغرة ليست مجرد 'خطأ في مكتبة'. إنها دراسة حالة لنمط أكبر:
في Cyata، عملنا هو مساعدة المؤسسات في بناء الرؤية، تقييم المخاطر، التحكم، والحوكمة حول أنظمة الذكاء الاصطناعي – لأنه إذا لم تستطع الإجابة بسرعة أين يتم تشغيل الوكلاء، وما هي الإصدارات المنشورة، وما البيانات التي تتدفق من خلال ذلك، فأنت تطير بشكل أعمى عندما تصل تحذيرات مثل هذه.
إذا كنت قائد أمن تقرأ هذا، إليك الحقيقة غير المريحة:
معظم المؤسسات لا تستطيع الإجابة بسرعة وثقة:
هذه ليست 'مشكلة مطور'. إنها مشكلة رؤية وحوكمة.
وهنا يأتي دور Cyata.
في Cyata، نركز على النتائج العملية: تقليل مخاطر الذكاء الاصطناعي والوكلاء دون إبطاء المطورين. ثغرات مثل هذه نادرًا ما تكون 'مجرد تصحيح'. إنها تكشف فجوات في كيفية اكتشاف الفرق لأين يتم تشغيل الوكلاء، وفهم حدود الثقة الحقيقية، وفرض إعدادات افتراضية أكثر أمانًا في الأطر سريعة الحركة.
اعرف ما يتم تشغيله، وأين، وكيف يتم توصيله.
أجب بسرعة على السؤال الأول لـ CVE: هل نحن معرضون للخطر، وفي أي تدفقات؟
اكتشف بيئات تشغيل الوكلاء والتكاملات عبر البيئات (IDEs، CI، الخدمات، الوظائف العاملة، وكلاء الاستضافة).
تتبع الأطر والحزم والإصدارات المستخدمة.
حدد أولويات ما هو مهم بناءً على نطاق التأثير الحقيقي، وليس فقط 'المكتبة موجودة'.
حافظ على فرز أسرع: ما هو مواجه للإنترنت، وما يتعلق بالأسرار، وما يتم تشغيله بامتيازات مرتفعة.
حدد مسارات المخاطر الأعلى: محتوى غير موثوق يتدفق إلى سياقات مميزة (خدمات بها أسرار، أذونات أدوات واسعة، وصول شبكة الإنتاج).
قم بتسليط الضوء على أين قد تعبر 'الحقول المنظمة' حدود الثقة (البيانات الوصفية، مخرجات الأدوات، أحداث التدفق، القطع الأثرية المخزنة مؤقتًا).
قلل التعرض حتى قبل أن يتم تصحيح كل تبعية في كل مكان.
شجع الإعدادات الافتراضية التشغيلية الأكثر أمانًا: أقل الامتيازات، حدود العزل، وفحوصات السياسات القابلة للتوسع عبر الفرق.
فرض بوابات حول الأنماط الخطرة (على سبيل المثال: إلغاء تسلسل البيانات غير الموثوقة، إعادة إنشاء الكائنات المتساهلة، تدفقات البث-إلى-التخزين-المؤقت-إلى-إعادة-الترطيب غير الآمنة).
قم ببوابة أو تقييد القدرات الحساسة في السياقات غير الموثوقة (على سبيل المثال: الوصول إلى الأسرار من البيئة، تنفيذ أدوات عالي الامتياز، أو تشغيل مسارات كود خطرة في عمال مميزين).
اجعل 'الاستخدام الآمن للوكلاء' قابلاً للتكرار، وقابلاً للتدقيق، وصعب الانحراف.
حدد سياسات لـ الأطر والإصدارات والتكوينات المعتمدة.
تتبع وقيد الاستثناءات زمنيًا مع المالكين والمبررات.
راقب الانحراف والاستخدام الخطير للميزات بمرور الوقت، مع سجل تدقيق يدعم مراجعات الأمان والامتثال.
عندما يسقط تحذير عيد الميلاد، الهدف ليس البطولة – بل استجابة هادئة ومنضبطة مدعومة بمخزون حقيقي وبوابات مفروضة.
تم إرسال التقرير عبر Huntr – 4 ديسمبر 2025
تم الاعتراف به من قبل مشرفي LangChain – 5 ديسمبر 2025
تم نشر التحذير و CVE – 24 ديسمبر 2025