szybnev/cve-2026-7482يعيد إنتاج قراءة خارج الحدود في الكومة (heap out-of-bounds read) لثغرة CVE-2026-7482 في تحميل وقياس ملفات GGUF في Ollama، مع تحليل تفاضلي للقطع الأثرية المكمّمة لإظهار تأثير القراءة خارج الحدود.
يحتوي هذا المستودع على سكربت إعادة الإنتاج المحلي الخاص بي لـ CVE-2026-7482، وهو قراءة خارج الحدود في كومة الذاكرة في مسارات تحميل وقياس الكم GGUF الخاصة بـ Ollama.
النتيجة المهمة من هذا العمل ضيقة: تمكنت من جعل حالة القراءة خارج الحدود في كومة الذاكرة تحدث بشكل موثوق وإنتاج ملفات GGUF مكمّمة متأثرة بالقراءة خارج الحدود. لم أتمكن من إظهار تأثير واضح من نوع الصندوق الأسود مثل استعادة النص السري الموثوقة أو الاستخراج المباشر لسلاسل الكناري من الملف الناتج.
يقوم exp.py بإنشاء ملفي GGUF:
يقوم برفع كلا الملفين إلى مثيل Ollama ضعيف عبر واجهة برمجة تطبيقات Ollama المحلية، ويطلق عملية قياس الكم عبر /api/create، وينسخ ملفات GGUF المولدة من حاوية Docker المحلية، ويقارن المخرجات الخبيثة بمخرجات التحكم الصفرية.
المقارنة التفاضلية مفيدة لأنها تُظهر أن مسار قياس الكم الضعيف استخدم بايتات لم تكن موجودة في ملف GGUF الخبيث الأصلي. في اختباراتي، كان هذا السلوك مستقرًا على Ollama 0.17.0 وتم رفضه بواسطة المسار المُصلح 0.17.1.
requests0.17.0 مكشوف على منفذ API محليollama-old-testمثال على هدف المختبر:
docker run -d --name ollama-old-test -p 11435:11434 ollama/ollama:0.17.0
قم بتثبيت الاعتماد الوحيد على Python:
python3 -m pip install requests
قم بتشغيل الاختبار الافتراضي ضد http://localhost:11435 والحاوية ollama-old-test:
python3 exp.py
وسائط صريحة:
python3 exp.py http://localhost:11435 ollama-old-test Q4_K_M F16
python3 exp.py http://localhost:11435 ollama-old-test Q8_0 F16
python3 exp.py http://localhost:11435 ollama-old-test Q8_0 F32
يكتب السكربت ملفات محلية مثل:
malicious_model.ggufcontrol_model.ggufquantized_model.ggufcontrol_quantized_model.ggufq8_dequantized_f32.binq8_pseudo_f16.binq8_pseudo_f16.txtفي اختباراتي المحلية، أنشأت نسخة Ollama الضعيفة مخرجات مكمّمة حيث اختلف حمولة الموتر الخبيث عن موتر التحكم الصفري على الرغم من أن ملف GGUF الخبيث لم يحتوي على تلك البايتات.
هذا كافٍ لإظهار ملف متأثر بالقراءة خارج الحدود. لكنه ليس كافيًا للادعاء بكشف بيانات عملي من نوع الصندوق الأسود.
اختبرت أيضًا بيانات من نمط الكناري في مطالبات نماذج متزامنة وبحثت في الملفات المولدة، وبايتات Q8_0 المُزالة الكم بفواصل عشرية 32-بت، ومخرجات إعادة بناء F16 الزائفة. لم أستطع استعادة كناريات دقيقة أو أجزاء نصية واضحة ذات معنى.
السبب المرجح هو أن البايتات لا تُنسخ كذاكرة كومة خام. بل تمر عبر خط أنابيب تحويل النموذج وقياس الكم:
heap bytes -> interpreted as F16/F32 tensor values -> converted/quantized -> GGUF tensor output
هذا المسار فاقد للمعلومات، خاصة مع الصيغ المكمّمة مثل Q4_K_M. يحافظ Q8_0 على معلومات رقمية أكثر من Q4_K_M، لكنه ما زال لا ينتج استعادة نصية موثوقة في اختباراتي من نمط الصندوق الأسود.
هذا مساعد لإعادة إنتاج محلية في المختبر وتحليل ملفات.
لا يوفر أداة استخراج أسرار عن بُعد موثوقة. كما يتطلب وصول Docker محليًا لنسخ الملف المولد من Ollama من حاوية الاختبار، لذا فإن خطوة التحليل ليست سير عمل صندوق أسود عن بُعد خالص.
الاستنتاج العملي من اختباراتي هو:
يوجد أيضًا مستودع PoC منفصل بواسطة 0x0OZ:
يُظهر هذا التنفيذ سير عمل أقوى من نمط الصندوق الأبيض من خلال دفع الملف النموذجي المولد إلى سجل مُتحكم به. مع إصلاح تدفق رفع السجل من طلب السحب الخاص بي، يكتمل بنجاح في مختبرتي المحلية:
حتى مع مسار جمع الملفات الأفضل من البداية إلى النهاية، يبقى نفس التحذير حول جودة البيانات مهمًا: المخرجات هي بيانات مكمّمة/محولة نموذجيًا، وليست تفريغًا خامًا مباشرًا لكومة الذاكرة.
هذا المستودع مخصص فقط لأبحاث الثغرات المصرح بها وإعادة الإنتاج الدفاعية. اختبر فقط ضد الأنظمة التي تملكها أو لديك إذن صريح بتقييمها.