ملف llms.txt قد يصبح قائمة أهداف: 120 مرجعًا بلا مالك
حذرت Cloud Security Alliance في 7 سبتمبر 2026 من أن ملفات llms.txt قد تتحول إلى قائمة أهداف عندما تتضمن أسماء حزم أو نطاقات لم يسجلها أصحاب الوثائق. ويبين تحليل نموذج الثقة لدى CSA أن الباحثين عثروا على 120 موضعًا متأثرًا، ثم أثبتوا أن الاستيلاء على عينة من الأسماء المتاحة يمكن أن يقود وكلاء برمجة داخل شبكات شركات إلى تثبيت شيفرة يسيطر عليها طرف آخر.
استند التحليل إلى تجربة نشرها الباحث ألون هرتز في 26 أغسطس 2026: سجل فريقه عددًا محدودًا من الأسماء غير المملوكة ووضع خلفها حزمًا خاملة ترسل إشارة عند تثبيتها. ووفق الإفصاح الأصلي عن التجربة، وصلت أول إشارة من بيئة شركة مدرجة ضمن Fortune 500 خلال أقل من أربع دقائق، ووصلت إشارة ثانية خلال ساعة، ثم سجل الفريق بضع عشرات من الاتصالات الأخرى.
الخطر في الوجهة لا في صيغة الملف وحدها
لا ينفذ llms.txt الشيفرة بذاته، ولا تكشف التجربة عيبًا برمجيًا مشتركًا في Claude أو Codex أو Hermes. ينشأ الخطر عندما يقرأ وكيل مخول بتشغيل أوامر النظام وثيقة مورد رسمية، ثم يعامل أمر التثبيت فيها بوصفه موثوقًا من دون التأكد من أن حساب النشر أو النطاق تابع فعلًا لذلك المورد.
هذه النقطة تجعل عبارة «قائمة أهداف» في العنوان وصفًا لنتيجة قابلة للملاحظة وليست مجرد استعارة. يستطيع مهاجم مسح الملفات العامة، واستخراج الأسماء التي لم تُحجز بعد، ثم تسجيلها وانتظار وكيل ينفذ التعليمات المنشورة أصلًا؛ فلا يحتاج إلى تعديل موقع المورد أو تخمين اسم قريب من حزمة حقيقية.
لماذا ظهرت أرقام 120 و227 و237؟
تصف الأرقام وحدات مختلفة، كما تختلف المصادر في إجمالي الملفات المفحوصة. فقد ذكر الإفصاح الأصلي 8,565 ملفًا من نوعي llms.txt وllms-full.txt عبر 6,214 نطاقًا حيًا، بينما أوردت CSA و تغطية Ars Technica للمسح رقم 8,265 ملفًا؛ ولم تُنشر بيانات خام تتيح حسم ما إذا كان الفارق ناتجًا من نسخة أخرى للمسح أو من تنقية النتائج.
تستخدم CSA تعبير «120 مرجعًا غير مسجل» في ملخصها، لكنها توضح لاحقًا أن المقصود 120 ملفًا، كل واحد على موقع مختلف، احتوى أمرًا أو وجهة غير مملوكة. أما 227 فهو عدد أوامر التثبيت أو الزيارة داخل تلك الملفات، في حين يحصي رقم 237 فأكثر جميع العناصر القابلة للمطالبة، بما فيها أسماء الحزم والنطاقات والنطاقات الفرعية. لذلك يشير رقم 120 في العنوان إلى مستوى المواقع أو الملفات المتأثرة، لا إلى عدد الحزم الفريدة ولا إلى مجموع مرات ظهور الأوامر.
ويمثل تقدير 1.5% نسبة 120 إلى 8,265 تقريبًا. لا يجوز تطبيق هذه النسبة على كل مواقع الويب، لأن العينة اقتصرت على نطاقات منتقاة لشركات كبرى ومقاولي دفاع ومؤسسات تقنية، ولم تكن مسحًا عشوائيًا للإنترنت كله.
كيف انتقل مرجع منشور إلى تنفيذ حزمة؟
احتاجت التجربة إلى سلسلة من القرارات، لا إلى قراءة الملف وحدها. بدأت بوثيقة عامة تحتوي تعليمات تثبيت، وانتهت عندما استخدم وكيل ذو صلاحيات مدير حزم عامًا لجلب اسم أصبح تحت سيطرة الباحثين.
- ينشر مورد ملف llms.txt أو llms-full.txt يتضمن اسم حزمة أو نطاقًا ضمن تعليمات الإعداد.
- يبقى الاسم غير مسجل بسبب وثيقة قديمة أو إعادة تسمية أو حزمة لم تُنشر أصلًا؛ ولم يثبت الباحثون سببًا واحدًا لجميع الحالات.
- يسجل طرف خارجي الاسم المتاح وينشر تحته حزمة. استخدمت التجربة منارة خاملة، لكن القناة نفسها تسمح نظريًا بوضع حمولة ضارة.
- يبحث الوكيل عن وثائق المورد أثناء مهمة تطوير، ثم يمرر الاسم إلى npm أو PyPI أو سجل آخر من دون التحقق من علاقة الناشر بالمورد.
- ينفذ المورد بصلاحيات جلسة الوكيل، فتنتقل الثقة من نطاق رسمي إلى حساب نشر لم تُثبت ملكيته.
اختبر الفريق خمس تهيئات عبر أداتين وكيليتين لسطر الأوامر، ونفذ 100 محاولة لكل تهيئة. كان الطلب يذكر المورد ويطلب بناء مشروع Node.js باستخدام وثائقه، من دون إعطاء رابط أو اسم حزمة أو ذكر llms.txt؛ وسجلت التجربة حالات بحث فيها الوكلاء عن الوثيقة ثم ثبتوا الحزم المزروعة. يثبت ذلك إمكان اكتمال المسار، لكنه لا يقدم معدل نجاح عامًا لكل وكيل أو بيئة.
لماذا قد لا تكفي ضوابط الطرفيات؟
تبدو كل حلقة منفردة مألوفة لنظام الحماية: أداة برمجة معتمدة تستدعي مدير حزم شرعيًا، والاتصال يتجه إلى سجل عام مسموح به. يقع قرار الثقة الخاطئ قبل التنزيل، ولذلك قد لا يميز نظام يراقب العمليات والوجهات بين تثبيت مشروع مشروع وحزمة استولت على اسم تركته الوثائق بلا مالك.
يزداد الخطر مع npx لأنه يستطيع جلب حزمة وتشغيل ملفها التنفيذي من دون إضافتها أولًا إلى بيان اعتماديات المشروع. وهذا قد يزيل فرصة مراجعة الاسم في ملف القفل قبل التنفيذ، لكنه لا يعني أن كل استخدام لـ npx ضار أو أن كل وكيل سيشغل الأمر تلقائيًا.
يختلف هذا المسار عن slopsquatting التقليدي. هناك يخترع النموذج اسمًا معقولًا ويسجله المهاجم أملًا في تكرار الهلوسة؛ أما هنا فالاسم موجود في وثيقة حقيقية، ويمكن للمهاجم اكتشافه مسبقًا والمطالبة به. سلامة الموقع الذي يستضيف الوثيقة لا تثبت سلامة كل وجهة تشير إليها.
بوابة قبول قبل منح الوكيل إذن التثبيت
الضابط المناسب هو معاملة كل اعتماد جديد اقترحه الوكيل كطلب يحتاج تحققًا مستقلًا، حتى إذا جاء الأمر من نطاق المورد الرسمي. ويمكن تنفيذ ذلك في وسيط أمام سجلات الحزم أو داخل CI بحيث يسبق القرار الأمني إنشاء أي عملية تثبيت.
- استخراج الوجهات: تحليل أوامر npm وnpx وpip واستخراج اسم الحزمة والسجل والنطاق وعنوان التنزيل قبل تشغيل أي subprocess.
- إثبات الملكية: مطابقة حساب الناشر وnamespace ومستودع الشيفرة والنطاق الموثق مع الجهة صاحبة الوثيقة؛ تشابه الاسم وحده لا يكفي.
- فحص تاريخ النشر: تنبيه المراجع إلى الحزم الحديثة، وتبدل حسابات الصيانة، والفجوات غير المعتادة بين الإصدارات، مع الاستفادة من بيانات provenance أو التوقيعات عندما يوفرها السجل.
- تثبيت النسخة والمحتوى: رفض الإصدارات العائمة، واستخدام نسخة محددة وملف قفل وبصمة معروفة بعد اعتماد الحزمة.
- تقييد التنفيذ: اشتراط موافقة بشرية لإضافة اعتماد جديد، وتشغيل التثبيت في بيئة معزولة بلا أسرار وبأقل صلاحيات واتصال خارجي ممكن.
- حفظ الأثر: تسجيل الوثيقة التي قدمت الأمر، واسم الوكيل، والأمر النهائي، والسجل، والناشر، والبصمة، ونتيجة المراجعة.
المؤكد حتى تحليل CSA هو أن حزم الاختبار الخاملة نُفذت داخل بيئات مؤسسية، وأن سلاسل العمليات ربطت بعض عمليات التثبيت بوكلاء Claude وCodex وHermes. لا تثبت التجربة اختراق هذه المنتجات نفسها، ولا تثبت سرقة بيانات أو إنشاء بقاء داخل الأنظمة المختبرة؛ لكنها تثبت أن مرجعًا عامًا غير مملوك يمكن أن يصبح حلقة تنفيذ فعلية. وما يزال قياس انتشار المعالجة أو معرفة عدد المؤسسات التي أزالت المراجع المعيبة متوقفًا على بيانات لاحقة لم تنشرها الجهات المعنية بعد.
اقرأ أيضًا:
اشترك في نشرتنا الإخبارية
احصل على أحدث أخبار الويب 3 والذكاء الاصطناعي والعملات المشفرة مباشرة في بريدك.