ثغرة llms.txt: كيف يثبّت وكلاء الذكاء الاصطناعي كوداً ضاراً تلقائياً عبر ملفات التوثيق

يوم الخميس، 27 أغسطس، نشرت Ars Technica تحقيقاً يجب أن يدفع أي مطور يستخدم وكلاء الذكاء الاصطناعي للكود لإعادة النظر في أمانه. باحثون من شركة ناشئة إسرائيلية في وضع التخفي (stealth) فحصوا 6,214 نطاقاً تابعاً لشركات Fortune 500، ومقاولي الدفاع، وعمالقة التقنية — ووجدوا 120 ملف llms.txt تجبر وكلاء الذكاء الاصطناعي على تثبيت حزم غير موجودة من PyPI و npm تلقائياً.

جوهر المشكلة بسيط ومرعب: llms.txt هو في الأساس "robots.txt للذكاء الاصطناعي" — ملف خريطة موقع بصيغة markdown يساعد الوكلاء على فهم بنية التوثيق بسرعة. لكن المواصفة لا تتضمن أي مصادقة، أو توقيعات، أو فحوصات سلامة. إذا احتوى مثل هذا الملف على سطر pip install حزمة-غير-موجودة أو npm install حزمة-غير-موجودة، وكان لدى الوكيل صلاحية تنفيذ الأوامر — فسوف يثبّت ببساطة ما هو مكتوب هناك.

كيف يعمل ذلك

عثر الباحثون على 8,265 ملف llms.txt و llms-full.txt (العديد من المواقع تحتفظ بالملفين). في 120 منها — عبر 120 نطاقاً مختلفاً — كانت هناك إشارات إلى حزم أو نطاقات غير موجودة في السجلات. كل ما يحتاجه المهاجم هو تسجيل مثل هذا الاسم ورفع كود ضار.

للتحقق من الهجوم، سجل الباحثون أنفسهم عدة أسماء "حرة" ووضعوا فيها حزم غير ضارة ترسل إشارة "لقد بدأت" إلى خادمهم. خلال ساعة تلقوا استجابة من شركة في Fortune 500. مع الوقت، وصلت عشرات الاستجابات — من عمالقة آخرين وشركات ناشئة. بيانات العمليات أظهرت من قام بتثبيت الحزم تحديداً: Claude Code، و OpenAI Codex، و Hermes من Nous Research.

أخطر حالة — clerk.com

على موقع clerk.com الشرعي، كان ملف llms.txt يحتوي على أمر npx clerk-next-fix-auth-protection. بخلاف npm install العادي، يمكن لـ npx تحميل حزمة في ذاكرة npm المؤقتة وتنفيذ ملفها الثنائي دون إضافتها إلى قائمة تبعيات المشروع. نجح شخص ما في الاستيلاء على هذا الاسم الحر ورفع برامج ضارة حقيقية إليه. أصلحت Clerk المشكلة، لكن النمط أصبح بالفعل في الإنتاج.

لماذا هذا ليس مجرد "خطأ في النموذج"

هذا ليس هلوسة ولا هروب من بيئة معزولة (sandbox). الملف موجود على النطاق الرسمي للشركة، يُقدَّم عبر HTTPS، بصيغة موحدة مصممة لاستهلاك الذكاء الاصطناعي. الوكيل ليس لديه سبب للشك فيه — الملف هو السلطة. المشكلة تكمن في أن معيار llms.txt (المقترح من جيريمي هوارد من Answer.AI في سبتمبر 2024) لا يحتوي على أي أحكام أمنية: لا توقيعات، لا تحقق من المصدر، لا تحقق من الحزم.

سلسلة الثقة متعدية: llms.txt لا يجب أن يكون على موقع شركة Fortune 500 نفسه — يمكن أن يكون في توثيق شريك، أو مرجع SDK لمزود، أو دليل مشروع مجتمعي. إذا كان الوكيل يثق في الطرف الثالث، وأشار ذلك الطرف إلى حزمة غير مسجلة — تعمل السلسلة بنفس الطريقة.

ماذا تفعل الآن

1. تدقيق. تحقق من llms.txt و llms-full.txt لديك. تأكد من أن كل حزمة، نطاق، ورابط مذكور موجود، تحت سيطرتك، ولديه مُحافظ معروف. احذف الإشارات إلى التبعيات التي لا تستطيع شرحها من الذاكرة.
2. وسيط (Proxy) بين الوكلاء والسجلات. احظر الحزم الجديدة (حزم slopsquatted جديدة بحكم التعريف)، وفرض فترة تبريد 24–72 ساعة بعد الإصدار الأول لأي تبعية، تحقق من provenance (SLSA/Sigstore) قبل التثبيت.
3. لا تعطِ الوكلاء أعلام --yolo، --dangerously-skip-permissions، --trust-all-tools. هذه الأعلام موجودة ليتحمل المطور المسؤولية. إذا كان الوكيل يثبّت حزم دون تأكيدك — فقد سلمته مفاتيح البنية التحتية الخاصة بك.

الخلاصة

سباق جعل المواقع قابلة للقراءة من قبل الوكلاء اصطدم للتو بسباق استغلال سلسلة توريد البرمجيات. هذا ليس خطأ نموذج واحد أو بائع واحد — إنه عيب تصميمي في معيار لم يفكر فيه أحد ككود قابل للتنفيذ. إلى أن تفرض الصناعة التحقق مما يقرأه الوكلاء على الويب، كل llms.txt سيء هو نقطة دخول محتملة إلى شبكتك.

تريد اختبار سير عمل الذكاء الاصطناعي الخاصة بك للأمان؟ في NeuralSpace يمكنك تشغيل توليد الكود واختبار الوكلاء في بيئة معزولة — جرب الدردشة أو وضع الكود.