Langflow CVE-2026-0768: الثغرة الثانية عشرة في Langflow التي استُغِلَّت في البرية هذا العام

CVE-2026-0768 هو ثغرة تنفيذ تعليمات برمجية عن بُعد دون مصادقة في Langflow، الإطار البصري مفتوح المصدر لتجميع خطوط أنابيب نماذج اللغة الكبيرة والوكلاء، وكان المهاجمون يستغلونها فعليًا بحلول نهاية أغسطس 2026. تكمن الثغرة في مدقّق الشيفرة الكامن خلف محرر المكوّنات المخصصة في Langflow: إذ تقبل نقطة النهاية validate معامل code وتنفّذ شيفرة Python التي يحتويها، دون أي مصادقة، و«في سياق الجذر (root)» وفق صياغة Zero Day Initiative. سجّلت شبكة المصائد Canary التابعة لـ VulnCheck أكثر من 50 محاولة استغلال خلال ساعات من أولى عمليات الرصد في 30 أغسطس 2026، وأكثر من 360 بحلول الاثنين 1 سبتمبر، وجميعها استهدفت مستشعرات في المملكة المتحدة؛ وقالت كيتلين كوندون من VulnCheck إن حركة المرور المصدرية جاءت أساسًا من روسيا. ولم تكن الطلبات من نوع الفدية. بل قرأت متغيرات البيئة التي تحمل بيانات اعتماد المستخدم الخارق في Langflow، ومفاتيح OpenAI API، ومفاتيح الوصول والسرية في AWS، ثم اتجهت إلى البحث في /root/.cache/langflow/secret_key و.ssh و.bash_history. ويوجد المدخل الكامل لهذا الحادث في الأرشيف، بما في ذلك تصنيفاته للخطورة والثقة والضرر، في the Orca AI Incident Archive، إلى جانب سجلات سرقة بيانات الاعتماد والبنية التحتية للذكاء الاصطناعي الأخرى المحيطة به.

نشرت Security Affairs روايتها في 2 سبتمبر 2026؛ وأورد Ionut Arghire من SecurityWeek استغلال الثغرة في اليوم السابق، وتناولها Bill Toulas من BleepingComputer في ذلك الأسبوع، ثم تبعتها AI Safety Initiative التابعة لـ Cloud Security Alliance في 4 سبتمبر بمذكرة بحثية تعيد صياغة الآلية وتضيف توصيات. ولم تسمِّ أيٌّ من الروايات التي روجعت لهذا المقال مؤسسة مخترقة. ويعود كل شيء إلى مستشعرات VulnCheck الخاصة وإلى التنبيه الأمني الذي نشرته Zero Day Initiative في يناير.

محرر ينفّذ ما يُطلب منه التحقق منه

تتمثل نقطة تميّز Langflow في أنك تُجمّع تطبيق ذكاء اصطناعي عبر سحب المكوّنات إلى لوحة رسم. المكوّنات المخصّصة هي Python: يتيح المحرّر للمستخدم لصق الشيفرة والضغط على «تحقّق»، ويتولّى الخادم فحصها. وفقًا للنشرة الاستشارية ZDI-26-034 الصادرة عن ZDI، فإن ذلك الفحص يشغّل الشيفرة. جملة السبب الجذري في النشرة مكوّنة من سطر واحد — «غياب التحقّق الصحيح من سلسلة نصية يوفّرها المستخدم قبل استخدامها لتنفيذ شيفرة Python» — والنتيجة أن طلب HTTP واحدًا غير مُصادَق عليه ينفّذ Python تعسفيًا على المضيف.

ثلاث خصائص تحوّل ذلك إلى حادث أمني بدلًا من مجرد تقرير خطأ. متجه CVSS هو AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H، بدرجة 9.8: يمكن الوصول إليه عبر الشبكة، وتعقيد منخفض، ودون امتيازات، ودون تفاعل المستخدم، وفقدان تام للسرية والسلامة والتوافر. سياق التنفيذ هو root، ولهذا فإن أوامر المهاجم التي يصفها كل من Condon وCloud Security Alliance تتجه نحو /root/.cache/langflow/secret_key — الملف الذي يستخدمه Langflow لتشفير بيانات الاعتماد المخزنة وبيانات الجلسة. ونقطة النهاية لا تطلب أي بيانات اعتماد على الإطلاق، لذا فإن التعرض دالة على إمكانية الوصول وحدها.

تاريخ الإفصاح يهم في فهم كيفية حدوث ما جرى. يسجّل الجدول الزمني لـ ZDI وصول التقرير إلى حساب Langflow على GitHub في 18 يوليو 2025، وطلبًا للتحديثات في 11 سبتمبر 2025، وطلبًا للإصلاح في 10 أكتوبر 2025، وإشعارًا بالنية للنشر كـ zero-day في 10 ديسمبر 2025. وأصدرت ZDI التنبيه الأمني في 9 يناير 2026. الباحثون المنسوب إليهم الفضل هم بيتر جيرنوس وويليام غامازو سانشيز وألفريدو أوليفيرا من Trend Research. وتحتوي قاعدة بيانات التنبيهات الأمنية في GitHub على النص نفسه بوصفه GHSA-x5pr-rvjj-j6qm، المنشور في 23 يناير 2026، والمصنَّف CWE-94، ولا تُدرج أي نطاق إصدارات متأثرة على الإطلاق. أما التخفيف المعلن من ZDI فليس تصحيحًا برمجيًا: بل هو "تقييد التفاعل مع المنتج".

تضع التقارير العامة نطاق التأثر ضمن إصدارات Langflow حتى الإصدار 1.4.2 شاملاً، وهو الإصدار الذي بُنيت عليه وحدة Metasploit التي أُضيفت لاحقاً واختُبرت مقابله. وعند هذا الحد ينتهي اليقين، ويوضّح قسم الإصلاحات أدناه السبب.

ما الذي تثبته اكتشافات 360 وما الذي لا تثبته

Canaries التابعة لـ VulnCheck هي أجهزة استشعار متصلة بالإنترنت صُممت لتبدو كالشيء الذي يبحث عنه المهاجم أثناء الفحص. ورصدت الشركة أول استغلال لـ CVE-2026-0768 في 29–30 أغسطس 2026: أكثر من 50 عملية رصد خلال ساعات قليلة يوم الأحد، لترتفع إلى أكثر من 360 بحلول الاثنين. ووصف كوندون، نائب رئيس أبحاث التهديدات في VulnCheck، النشاط على LinkedIn بأنه "مزيج من الاستطلاع وحصاد بيانات الاعتماد"، مضيفًا أن حركة المرور المصدرية نشأت أساسًا من روسيا و"اقتصرت حتى الآن حصريًا على Canaries في المملكة المتحدة."

تسلسل الأوامر الذي التقطته المستشعرات محدد بما يكفي ليكون دليلًا تنفيذيًا. استعلم المهاجمون من البيئة عن LANGFLOW_SUPERUSER، وعن متغيرات تطابق OPENAI_API، وعن مفاتيح AWS_ACCESS وAWS_SECRET — وهي عائلات بيانات الاعتماد الثلاث التي يُرجَّح أن يحتفظ بها مضيف Langflow. قرؤوا مفتاح السر المخزَّن مؤقتًا في /root/.cache/langflow/secret_key. وفحصوا إمكانية الوصول إلى .ssh وفحصوا حجم .bash_history، وكلاهما يدل على ما إذا كان بإمكان مشغّل التحرك جانبيًا لا مجرد قراءة الأسرار. ويضيف تقرير مجتمعي عن السلسلة، استشهدت به Cloud Security Alliance، أن النشاط نفسه بحث في أشجار المصدر وملفات .env عن أسرار مضمّنة، وسرّب ما عثر عليه، وتحقق مما إذا كان قد زُرع في مضيف سابقًا باب خلفي بواسطة مشغّل سابق قبل أن يضيف آلية استمراريته الخاصة.

ما يثبته ذلك هو أن الاستغلال يعمل، وأنه استُخدم ضد نسخ Langflow المتاحة عبر الإنترنت، وأن الهدف كان الحصول على بيانات الاعتماد لا إحداث التعطيل. وما لا يثبته هو وجود ضحية. فأنظمة الكناري (Canaries) طُعوم مضللة؛ والاكتشاف ما هو إلا طلب، وليس سرقة مؤكدة. يصنّف الأرشيف هذا السجل بوصفه ضررًا فعليًا، والضرر الموثّق في المصادر العامة هو التنفيذ المؤكد لشيفرة حصاد بيانات الاعتماد ضد أنظمة مكشوفة — لا منظمة محددة بالاسم جرى استهلاك مفاتيحها.

ثمة تفصيل واحد يتعارض مع الرواية المعتادة عن الإفصاح. وفقًا لـ VulnCheck، لم يكن هناك إثبات مفهوم علني لـ CVE-2026-0768 موجودًا عندما بدأ الاستغلال. كانت النشرة الأمنية علنية لما يقرب من ثمانية أشهر، ووصفت الثغرة بدقة كافية ليتمكن شخص ما من بناء استغلال من النص. وقراءة الشركة، كما نقلت The Hacker News، هي أن هذا كان اشتقاقًا مستقلًا وليس إعادة استخدام لكود مسرّب.

اثنا عشر عيبًا، وخمسة عشر ألف محاولة — وأين تنحرف تلك الأرقام

الإحصائية التي تمنح هذا الحادث ثقله تأتي من VulnCheck، ويستحق الاقتباس بكلمات الشركة نفسها لا بإعادة صياغة. وقالت: «قبل 2026، أظهرت الأدلة وجود ثغرة Langflow واحدة فقط معروفة بأنها مُستغلة في البرية». «في 2026، تغيّرت الأمور بسرعة». ويذكر SecurityWeek أن VulnCheck يتتبع «11 ثغرة إضافية استُهدفت وأُبلِغ عن استغلالها في البرية» خلال 2026.

أضف تلك، فتحصل على اثنتي عشرة ثغرة مستغلة في Langflow، إحداها تسبق هذا العام. وهذا ليس مماثلاً لوجود اثنتي عشرة ثغرة في 2026، والمصادر تتنقل بين الصيغتين. يُسمّي عنوان Forkast الرئيسي CVE-2026-0768 «ثغرة Langflow المستغلة رقم 12 في 2026»، بينما يصف متن المقال نفسه الثغرات الاثنتي عشرة بأنها «11 ثغرة جديدة وواحدة رُصدت قبل بداية العام». ويتبع عنوان السجل العنوان الرئيسي. ووفق قراءة حرفية، تمثل 2026 إحدى عشرة من الثغرات الاثنتي عشرة، فيما تشكّل الثانية عشرة — تلك المعروفة قبل هذا العام — الباقي.

لرقم 15,000 حدّة مماثلة. فـ SecurityWeek وThe Hacker News وForkast تنسب جميعها «أكثر من 15,000 هجوم ناجح» إلى ثلاث ثغرات مسماة: CVE-2026-0769 وCVE-2025-3248 وCVE-2026-5027. هذا رقم كبير، لكنه إحصاء عبر ثلاث ثغرات CVE، وليس عبر محفظة Langflow كاملة لعام 2026. وصياغته على أنها محاولات استغلال ضد المحفظة — كما يفعل ملخص الأرشيف — أوسع مما نشرته VulnCheck.

الإدخالات الفردية الكامنة وراء هذا النمط موثّقة. كان CVE-2025-3248 ثغرة حقن تعليمات برمجية في النقطة الطرفية نفسها /api/v1/validate/code، وتم تصحيحها في Langflow 1.3.0 عبر استبدال التنفيذ بالتحقق القائم على التجميع فقط، وفقاً للتنبيه الأمني GitHub GHSA-rvqx-wpfh-mfx7 كما نقله Cloud Security Alliance — ما يعني أن CVE-2026-0768 من الفئة نفسها من الأخطاء في المسار البرمجي نفسه، بعد نحو أربعة أشهر من إصدار ذلك الإصلاح. أما CVE-2026-33017، وهو تنفيذ تعليمات برمجية عن بُعد (RCE) غير مصادق عليه في نقطة نهاية بناء التدفق العامة، فقد جرى تسليحه خلال نحو 20 ساعة من الكشف عنه في مارس 2026، واستُخدم للحصول على بيانات اعتماد OpenAI وAnthropic وAWS قبل التحول إلى تعدين Monero، وفقاً لما أوردته Cloud Security Alliance. وتغطي مذكرة التحالف نفسها المؤرخة 12 يونيو 2026 الثغرة CVE-2026-5027، وهي ثغرة اجتياز مسار في نقطة نهاية رفع الملفات ربطها الباحثون بالمجموعة الإيرانية المدعومة من الدولة MuddyWater، كما تسجّل مذكرته المؤرخة 4 سبتمبر الثغرة CVE-2026-55255، وهي تجاوز للتفويض يتيح لمستخدم مُصادق عليه تشغيل تدفقات مستخدم آخر، وقد أُضيفت إلى كتالوج CISA للثغرات المعروفة المستغلة في 7 يوليو 2026. تشترك هذه الثغرات الأربع في نمط واحد: نقطة نهاية إما تخطّت المصادقة أو تخطّت تنقية المدخلات، في منصة تتمثل مهمتها في حفظ بيانات الاعتماد لكل ما تتواصل معه.

لماذا تستحق منصة تنسيق العناء؟

تُعدّ نسخة Langflow قيد التشغيل في بيئة الإنتاج مهيأة بمفاتيح API الخاصة بمزوّدي الخدمات، وبيانات اعتماد السحابة، وسلاسل اتصال قواعد البيانات، وأسرار التكاملات، لأن التدفقات التي تشغّلها تحتاج إليها وقت الاستدعاء. وبالتالي فإن اختراق المضيف يمنح وصولًا فعّالًا إلى كل خدمة تخزّن النسخة بيانات اعتمادها. كما أن مفاتيح OpenAI أو Anthropic المسروقة تتيح للمهاجم تحميل تكلفة الاستدلال على الضحية أو انتحال هوية المؤسسة في التعاملات اللاحقة؛ بينما تفتح مفاتيح AWS المسروقة بابًا إلى بنية تحتية تتجاوز بكثير حاوية Langflow. وهذا النفوذ، وليس أي قدرة خاصة بالذكاء الاصطناعي، هو ما كانت الأوامر المرصودة تسعى إليه.

يرى Cloud Security Alliance أن تكرار المشكلات عبر أربعة أنظمة فرعية مختلفة في Langflow خلال سنة واحدة — مدقق الشيفرة، ونقطة النهاية العامة لبناء التدفقات، ورفع الملفات، وتنفيذ سير العمل — يشير إلى فجوة منهجية في هندسة الأمن بدلاً من سلسلة عيوب غير مترابطة. هذا تقييم التحالف، وقد أُورد في مذكرة بحثية، وليس نتيجة توصل إليها مدقق مستقل، ولم ترد Langflow عليه علنًا في المواد التي روجعت هنا.

ما الذي تم إصلاحه، وما الذي لا يزال غامضًا

هذا هو أضعف جزء في السجل العام، ويجدر توضيح السبب بدقة. لا تذكر استشارة ZDI أي إصدار مُرقّع. تُدرج قاعدة بيانات Snyk الخاصة بهذه الثغرة CVE الإصدارات المتأثرة على أنها كل ما سبق 1.10.1، وتوصي بالترقية إلى 1.10.1 أو أحدث. أما التقارير العامة، بما في ذلك SecurityWeek وSecurity Affairs، فتصف نطاق التأثر بأنه الإصدارات حتى 1.4.2، لكنها لا تحدد أي إصدار مُصلح. وقد لاحظت Cloud Security Alliance في 4 سبتمبر أن القائمين على صيانة Langflow لم ينشروا استشارة أمنية مخصصة تذكر هذه CVE، وأن أدوات التتبع اختلفت حول الإصدار الذي عالجها فعليًا — وهو غموض تقول Cloud Security Alliance إنه يكرر حالة سابقة لـ Langflow ظل فيها إصدار أُبلغ عن إصلاحه عرضة للاستغلال.

أصدرت Langflow بالفعل إصلاحات في المجال الصحيح، وفي اليوم الصحيح. نُشر الإصدار 1.11.6 في 1 سبتمبر 2026، وهو الاثنين الذي تجاوز فيه عدد مصائد العسل 360، وتصف ملاحظات الإصدار إعادة دمج (backport) لإصلاحات أمنية تشمل «سد فجوات فحص شيفرة المكوّنات» و«حل التعليقات التوضيحية دون تنفيذ» (طلب السحب 14876). ثم صدر الإصدار 1.12.0 في ذلك المساء. واستمر المزيد من التحصين لمسار الشيفرة نفسه بعد ذلك: إذ يشير طلب سحب لاحق بعنوان «منع validate_code من تنفيذ الاستيرادات» إلى أن نقطة النهاية validate كانت لا تزال تُشدَّد بعد أسابيع من أول استغلال. ولا يشكّل أيٌّ من ذلك تصريحًا من البائع بأن CVE-2026-0768 قد أُصلح في إصدار مسمّى، ولم يُعثر على أيٍّ منه في المصادر المذكورة في السجل.

ما تغيّر على جانب المهاجم أوضح. فقد فُتحت وحدة استغلال في Metasploit خاصة بالثغرة كطلب سحب في 2 سبتمبر 2026 — وهو اليوم نفسه الذي نشرت فيه Security Affairs — ودُمجت في 8 أكتوبر 2026، بعد اختبارها ضد Langflow 1.4.2. ومهما كانت حالة الاشتقاق الأصلي، فقد توقف استغلال هذه الثغرة عن اشتراط عمل أصلي بعد ستة أسابيع من بدء استغلالها.

توصي Cloud Security Alliance باتباع تسلسل "التصحيح ثم التدوير" بدلاً من التصحيح وحده: تحقّق من الإصدار قيد التشغيل وانتقل إلى الإصدار المستقر الحالي؛ وتعامل مع أي نسخة مكشوفة على الإنترنت تعمل بإصدار متأثر على أنها مخترقة إلى أن يثبت العكس، لأن النشاط المرصود هو حصاد صامت للبيانات وليس تعطيلاً ظاهراً؛ ودوّر كل سرّ كان بمقدور النسخة الوصول إليه — كلمة مرور المستخدم الخارق في Langflow، ومفاتيح API الخاصة بالمزوّدين، ومفاتيح وصول AWS ومفاتيحها السرية، ومفتاح Langflow السرّي نفسه، مع إعادة تشفير بيانات الاعتماد المخزنة بدلاً من مجرد استبدال الملف. كما توصي بمراجعة سجلات الوصول بحثاً عن طلبات إلى نقطة نهاية validate، وفحص authorized_keys بحثاً عن مفاتيح SSH غير مألوفة، والبحث عن أدلة على أن مشغّلاً سابقاً كان قد زرع باباً خلفياً في المضيف بالفعل. وحيث يجب أن تبقى المنصة قابلة للوصول، تقترح تقييد الوصول إلى نقطة نهاية validate أو تعطيلها، والانتقال بعيداً عن المفاتيح طويلة الأجل عالية الامتيازات المخزنة مباشرةً في المنصة.

مُثبت، ومُبلَّغ عنه، وغير مُثبت

ثبت: أن CVE-2026-0768 عبارة عن تنفيذ تعليمات برمجية عن بُعد (RCE) غير مصادق عليه في نقطة النهاية validate في Langflow، وينفّذ Python بصلاحيات الجذر، وموثّق في ZDI-26-034 ومنسوخ باسم GHSA-x5pr-rvjj-j6qm؛ وأن الاستغلال بدأ في 29–30 أغسطس 2026؛ وأن VulnCheck سجّلت أكثر من 50 اكتشافًا خلال ساعات وأكثر من 360 بحلول 1 سبتمبر، مقابل مستشعرات المملكة المتحدة، مع حركة مرور مصدرها روسيا في الأساس؛ وأن الطلبات المرصودة استهدفت بيانات اعتماد المستخدم الخارق في Langflow وOpenAI وAWS بالإضافة إلى المفتاح السري المخزن مؤقتًا و.ssh و.bash_history. وهذه مستمدة من التنبيه نفسه ومن بيانات القياس عن بُعد الخاصة بـVulnCheck كما نقلتها بشكل مستقل SecurityWeek وSecurity Affairs وThe Hacker News.

مُبلَّغ عنه، غير مُتحقَّق منه بشكل مستقل: كل عدد من أعداد الاكتشافات. إن الأعداد 50 و360 و15,000 هي أرقام VulnCheck نفسها، نشرتها الشركة وكرّرتها منافذ إعلامية تنسبها إليها؛ ولم تنشر أي شبكة مصائد عسل ثانية عددًا مؤيِّدًا. كما أن نَسب ذلك إلى بنية تحتية روسية هو أيضًا قراءة VulnCheck لحركة المرور المصدرية، وليس تقييمًا أيدته أي حكومة أو CERT في المواد التي جرى مراجعتها.

غير مُثبت: أن أي منظمة مذكورة فقدت بيانات اعتماد. لم تُحدَّد أي ضحية في مصادر السجل. ولا توجد نسخة مُصحَّحة مؤكدة: فلا يذكر ZDI أيًا منها، وتقول Snyk إنها 1.10.1، وتذكر التقارير أن التأثر يمتد حتى 1.4.2، بينما تصف ملاحظات إصدار 1.11.6 إصلاحات أمنية دون ربطها بهذا CVE. كما أن إحصاء «العيب الثاني عشر لعام 2026» ليس متسقًا داخليًا عبر مصادره الخاصة، على النحو المبين أعلاه.

الجزء الذي ينبغي أن يقلق الأشخاص الذين يطبقون التحديثات وفق جدول زمني

الفجوة البالغة ثمانية أشهر هي الاكتشاف. نُشرت CVE-2026-0768 كثغرة يوم-صفر في 9 يناير 2026، مع وصف تقني مفصّل بما يكفي لإعادة البناء منه، ولم يحدث شيء تجاه مستشعرات VulnCheck حتى عطلة نهاية الأسبوع الأخيرة من أغسطس. ثم وصلت مئات المحاولات خلال ثلاثة أيام، من مشغّلين لم يكن لديهم، بحسب الشركة، أي استغلال علني لنسخه. ومهما كان ما أبقى تلك النسخ غير مُرقّعة طوال ثمانية أشهر من تحذير علني بالغ الخطورة، فهو الشيء نفسه الذي جعل الثغرة تستحق الاستغلال عندما كتب أحدهم الشيفرة أخيرًا.

وهذا أيضًا يغلق حلقةً فتحتها ثغرات Langflow السابقة. جرى إصلاح CVE-2025-3248 بإزالة التنفيذ من مسار التحقق نفسه؛ لكن CVE-2026-0768 ينفّذ على ذلك المسار رغم ذلك. الإصلاح الذي يزيل سلوكًا دون إزالة قرار التصميم الذي أنتجه يشتري وقتًا، وفي هذه الحالة اشترى نحو أربعة أشهر.