كشفت Oasis Security عن نقطة ضعف في NVIDIA NemoClaw قد تسمح لصفحة ويب يتحكم بها المهاجم بالوصول إلى نسخة Ollama المحلية التي تشغّل وكيل الذكاء الاصطناعي دون مصادقة. الخطر لا يتوقف عند الوصول إلى الخدمة فقط، بل قد يصل إلى زرع تعليمات مخفية داخل النموذج نفسه لتعمل لاحقًا مع المحادثات الجديدة.
شاركت Oasis Security نتائج البحث مع The Hacker News قبل نشرها، وأوضحت أنها أبلغت فريق NVIDIA Product Security Incident Response Team المعروف باسم PSIRT مسبقًا. وحتى 25 أغسطس 2026 لا يوجد رقم CVE مرتبط بالمشكلة، كما لم يتم الإبلاغ عن استغلالها فعليًا.
بحسب Elad Luz رئيس الأبحاث في Oasis Security، فإن NemoClaw بالإصدار v0.0.35 عالج المشكلة على macOS وLinux. أما مسار Windows وWSL فلا يزال دون إصلاح كامل، بينما أضاف الإصدار v0.0.34 دعم التثبيت على Windows مع تحذير متعلق بهذه الطريقة من التشغيل.
#ما هو NemoClaw أصلًا
NemoClaw هو مشروع مفتوح المصدر من NVIDIA يقدم بنية مرجعية لتشغيل الوكلاء مثل OpenClaw داخل بيئات OpenShell المعزولة. ومن بين محركات الاستدلال المحلية التي يدعمها المشروع يأتي Ollama.
المشكلة التي وصفتها Oasis Security تبدأ عندما يتم تشغيل Ollama باستخدام:
OLLAMA_HOST=0.0.0.0:11434
هذا الإعداد يجعل خادم النموذج يستمع على جميع واجهات الشبكة بدلًا من الاكتفاء بالواجهة المحلية. وبحسب الباحثين يمكن أن يتحول ذلك إلى نقطة دخول تسمح بتعديل قالب المحادثة الخاص بالنموذج وزرع تعليمات خفية يتم تطبيقها على كل محادثة لاحقة.
"Sandboxing protects the endpoint, but taking over the agent takes over its access and tools."
بمعنى آخر، قد تحمي الـ Sandbox النظام المضيف، لكن السيطرة على الوكيل نفسه تعني السيطرة على الصلاحيات والأدوات التي يمتلكها ذلك الوكيل.
#المشكلة تختلف حسب نظام التشغيل
توثيق NVIDIA الخاص بإعداد Ollama يوضح أن طريقة الربط تختلف حسب المنصة. ويمكن مراجعة التفاصيل في توثيق NVIDIA الرسمي لإعداد Ollama.
- على الأنظمة غير المعتمدة على WSL يبقى Ollama على
127.0.0.1:11434خلف Reverse Proxy محمي برمز وصول ويعمل على0.0.0.0:11435. - على Docker Desktop داخل WSL يتم تجاوز الـ Proxy لأن الحاوية تستطيع الوصول إلى Loopback الخاص بالمضيف عبر
host.docker.internal. - على Windows Host يتم ضبط
OLLAMA_HOST=0.0.0.0:11434حتى تستطيع حاويات Docker Desktop الوصول إلى الخدمة، ولا توجد مصادقة مطلوبة على المنفذ 11434.
صفحة تكامل Ollama مع NemoClaw توصي أيضًا باستخدام OLLAMA_HOST=0.0.0.0 عند التشغيل داخل WSL2 أو Container. وهذه ليست المرة الأولى التي يظهر فيها خطر ربط Ollama بهذه الطريقة، إذ سبق أن تم توثيق أن الربط على 0.0.0.0 قد يعرّض مثيلات Ollama خارج الجهاز المحلي.
#كيف يمكن للمتصفح الوصول إلى Ollama
واجهة Ollama على المنفذ 11434 لا تستخدم مصادقة افتراضيًا. ويعتمد منع الطلبات القادمة من صفحات الويب على طبقتين من Middleware تتعاملان مع Host Header وسياسة CORS.
المشكلة أن فحص Host Header يتم تجاوزه عندما لا يكون عنوان الربط Loopback. وإذا كانت Origin وHost تحملان نطاق المهاجم نفسه فقد تتعامل طبقة CORS مع الطلب باعتباره Same Origin وتسمح به.
هنا يأتي دور DNS Rebinding.
في هذا السيناريو يبدأ نطاق المهاجم بالإشارة إلى خادمه الحقيقي. وبعد ذلك يتغير حل اسم النطاق ليشير إلى 127.0.0.1 بينما يستمر المتصفح في اعتبار الطلبات صادرة إلى المصدر نفسه.
بحسب Luz تم اختبار سلسلة الهجوم كاملة على macOS باستخدام Firefox ضد إصدار ضعيف من NemoClaw. ويظل التحقق الصارم من Host وOrigin من أهم وسائل الحماية ضد هذا النوع من الهجمات.
#المشكلة ليست جديدة بالكامل
هجمات DNS Rebinding ضد Ollama موثقة منذ فترة. فقد أصدرت Ollama إصلاحًا في الإصدار v0.1.29 بتاريخ 14 مارس 2024، ثم نشرت NCC Group لاحقًا التنبيه الأمني CVE-2024-28224.
التوصية وقتها كانت واضحة. يجب على الخادم التحقق من Host Header والسماح فقط بقيم معتمدة مسبقًا.
وبحسب Luz أضافت Ollama هذا التحقق بعد الإفصاح في 2024. لكن المشكلة تظهر عندما تكون الخدمة مربوطة بعنوان غير Loopback، لأن التحقق يتم تجاوزه في هذه الحالة، و0.0.0.0 هو تحديدًا الإعداد المستخدم في بعض مسارات NemoClaw.
#من الوصول إلى الخدمة إلى تسميم النموذج
بمجرد الوصول إلى API يصبح السيناريو أخطر من مجرد إرسال طلبات إلى نموذج محلي. فالتقرير يوضح أن الحمولة الخبيثة تستطيع إرسال قالب Go معدل عبر المسار:
/api/create
قالب المحادثة يحدد الطريقة التي تتحول بها الرسائل المنظمة إلى نص خام قبل أن يعالجه النموذج. وإذا تم تعديل هذا القالب يستطيع المهاجم إضافة تعليمات يتحكم بها إلى كل System Message أثناء الاستدلال.
هذه التعليمات لا تظهر للمستخدم بشكل طبيعي. ووفق التقرير يمكنها الاستمرار عبر المحادثات اللاحقة حتى عندما يرسل الوكيل System Prompt خاصًا به.
"The client cannot detect or prevent this. The template is a model-level property invisible to API consumers."
وهنا تكمن خطورة الهجوم. التسميم لا يحدث فقط في المحادثة الحالية، بل على مستوى خاصية مرتبطة بالنموذج نفسه لا يراها العميل الذي يستخدم الـ API.
#ماذا وجدت مراجعة NemoClaw
راجع The Hacker News مستودع NemoClaw عند Commit يحمل الرقم 17f0ca3b بتاريخ 25 أغسطس. ووجد أن الـ Proxy المحلي الخاص بـ Ollama يرفض التشغيل إذا كان Backend مربوطًا بواجهة غير Loopback.
هذا السلوك أصبح افتراضيًا منذ الإصدار v0.0.106 الصادر في 10 أغسطس. وعند اكتشاف الربط غير الآمن يخرج الـ Proxy برسالة تحذير واضحة تطلب إعادة Ollama إلى 127.0.0.1.
النص الذي يظهر للمشغل يتضمن ما يلي:
Refusing to start: an Ollama daemon reachable on a non-loopback interface bypasses the proxy's token check entirely.
Set OLLAMA_HOST=127.0.0.1:${port} on the Ollama systemd unit
or set NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1 to override (not recommended).
يمكن تجاوز هذا الفحص باستخدام:
NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1
كما أن الفحص لا يفشل بالضرورة بطريقة مغلقة Fail Closed على الأنظمة التي لا يستطيع فيها تنفيذ اختبار الربط.
#Windows يبقى المسار الأكثر حساسية
الفحص الأمني السابق يعمل داخل الـ Proxy نفسه. لكن NemoClaw لا يشغّل هذا الـ Proxy في مسارات WSL، ومسار Ollama على Windows Host واحد منها.
لهذا فإن الحماية التي أضيفت في v0.0.106 لا تصل إلى المسار نفسه الذي يتم فيه ضبط 0.0.0.0. وهذا يترك اختلافًا مهمًا بين الحماية المتاحة على الأنظمة المختلفة.
المراجعة نفسها لم تجد آلية تتحقق من سلامة Chat Template داخل المستودع. استخدام /api/show في NemoClaw يركز على معرفة Context Length وقدرة النموذج على Tool Calling، وليس على التحقق مما إذا كان قالب المحادثة قد تم تعديله.
#لماذا لا يكفي منع الوصول من الشبكة
توثيق NVIDIA ينصح مستخدمي مسار Windows Host بعدم تعريض المنفذ 11434 إلى الشبكة المحلية أو الإنترنت. هذه النصيحة مهمة ضد الاتصالات القادمة من أجهزة أخرى.
لكن DNS Rebinding يغيّر طبيعة التهديد.
الصفحة الخبيثة تعمل داخل متصفح المستخدم نفسه. وبعد إعادة ربط DNS يستطيع المتصفح الوصول إلى الخدمة على 127.0.0.1 من داخل الجهاز، ولذلك لا يحتاج المهاجم أصلًا إلى فتح المنفذ للإنترنت أو إلى جهاز آخر داخل الشبكة.
#Poisoned Chat Templates تعود من جديد
فكرة تسميم Chat Template حتى تنفذ تعليمات إضافية أثناء الاستدلال ليست جديدة. فقد تم توثيق أسلوب مشابه سابقًا ضمن أبحاث عن Poisoned Chat Templates.
كما وثقت Oasis Security تقنية مشابهة ضد Paperclip في وقت سابق من أغسطس 2026. واستخدم الباحثون أيضًا مسارًا قريبًا من المتصفح إلى Localhost في فبراير ضمن هجوم استهدف وكلاء OpenClaw المحليين.
القصة هنا ليست مجرد منفذ مفتوح أو إعداد شبكة غير مثالي. عندما يصبح نموذج الذكاء الاصطناعي المحلي جزءًا من وكيل يمتلك أدوات وصلاحيات، فإن السيطرة على طبقة الاستدلال نفسها قد تتحول إلى سيطرة غير مباشرة على ما يستطيع الوكيل فعله.
ومع انتقال المزيد من نماذج الذكاء الاصطناعي إلى أجهزة المستخدمين، تصبح خدمات Localhost وقوالب المحادثة ومسارات التكامل بين المتصفح والوكيل جزءًا من سطح الهجوم الذي يجب التعامل معه كأي مكوّن أمني حساس.
