
Preuve de concept pour CVE-2026-7482, une lecture hors limites du tas non authentifiée dans le chargeur GGUF d'Ollama, démontrant l'exfiltration de mémoire via un fichier de modèle conçu à cet effet.
Ce dépôt contient une chaîne d'exploitation Proof of Concept (PoC) 1-day pour CVE-2026-7482, une vulnérabilité de lecture hors limites (OOB) non authentifiée dans le chargeur de modèles GGUF d'Ollama (versions antérieures à 0.17.1).
Remarque : Il s'agit d'une reproduction de recherche 1-day. Je n'ai pas découvert la CVE d'origine. Ce PoC a été conçu sur la base des détails de l'avis public afin de démontrer les mécanismes de la vulnérabilité à des fins de recherche éducative et défensive.
En fournissant un fichier GGUF tronqué et malveillant à l'endpoint /api/create, un attaquant peut forcer l'analyseur de quantification dans fs/ggml/gguf.go et server/quantization.go à lire au-delà du tampon de tas alloué. La mémoire divulguée est ensuite exfiltrée en poussant l'artefact de modèle résultant vers un registre Docker contrôlé par l'attaquant via l'endpoint /api/push.
Au cours de cette recherche 1-day, reproduire le crash était trivial, mais obtenir une exfiltration stable sans faire planter le serveur ni déclencher les blocages de validation de l'API a nécessité un forgeage architectural spécifique :
F16 (general.file_type = 1) pour satisfaire les contrôles préalables stricts de l'API Ollama.Q4_K_M. Comme la charge utile est considérée comme F16, le backend C++ ggml est forcé de traiter la charge utile plutôt que d'effectuer une copie mémoire sécurisée 1:1.token_embd.weight) doit être façonné comme une matrice 2D dont la dimension la plus interne est exactement 256 (par exemple, [num_rows, 256]). Cela s'aligne strictement avec les exigences de blocs Q4_K_M, empêchant le backend de sauter la couche.pip install requests numpy gguf
Vous avez également besoin d'un écouteur HTTP accessible publiquement (comme Ngrok) pour capturer les poussées de couches Docker exfiltrées.
1. Démarrer le registre malveillant Démarrez l'écouteur pour capturer les blobs de mémoire divulgués.
sudo python3 registry.py
2. Forger la charge utile malveillante
Générez le fichier GGUF tronqué. Vous pouvez ajuster TARGET_LEAK_SIZE_MB dans le script pour contrôler la quantité de mémoire de tas récupérée par requête. (Recommandé : 0,5 Mo à 2,0 Mo pour éviter les défauts de segmentation sur les pages non mappées).
python3 forge.py
3. Déclencher l'exploit
Modifiez exploit.py pour inclure votre IP cible et l'URL de votre registre malveillant, puis exécutez :
python3 exploit.py
4. Analyser l'artefact
Le registre déposera les dumps de tas divulgués dans le répertoire exfils/.
Remarque sur l'intégrité des données (le piège de la quantification) : Bien que l'exploit capture et exfiltre avec succès jusqu'à plusieurs mégaoctets de mémoire de tas du serveur, les données sont soumises à l'algorithme de sous-quantification Q4_K_M d'Ollama pendant la lecture hors limites. Le backend convertit les octets de mémoire bruts en float16 et applique un schéma de compression par blocs de 4 bits avec perte. Par conséquent, la mémoire divulguée est mathématiquement altérée. Les outils standard d'extraction ASCII produiront des données binaires inexploitables, rendant la récupération d'identifiants en clair pratiquement non viable via cette voie de coercition spécifique.
Ce projet est destiné uniquement à des fins éducatives et de recherche de vulnérabilités autorisées. N'utilisez pas cet outil contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas l'autorisation explicite de tester.