szybnev/cve-2026-7482Reproduit la lecture hors limites du tas CVE-2026-7482 dans le chargement et la quantification GGUF d'Ollama, avec une analyse différentielle des artefacts quantifiés pour démontrer l'influence de la lecture hors limites.
Ce dépôt contient mon script de reproduction local pour CVE-2026-7482, une lecture hors limites du tas dans les chemins de chargement et de quantification GGUF vulnérables d'Ollama.
Le résultat important de ce travail est ciblé : j'ai réussi à déclencher de manière fiable la condition de lecture hors limites du tas et à produire des artefacts GGUF quantifiés influencés par cette lecture OOB. Je n'ai pas réussi à démontrer un impact clair en boîte noire, comme la récupération fiable de secrets en clair ou l'extraction directe de chaînes canary de l'artefact résultant.
exp.py crée deux fichiers GGUF :
Il téléverse les deux fichiers vers une instance Ollama vulnérable via l'API Ollama locale, déclenche la quantification avec /api/create, copie les blobs GGUF générés depuis le conteneur Docker local, et compare la sortie malveillante à la sortie de contrôle zéro.
La comparaison différentielle est utile car elle montre que le chemin de quantification vulnérable a utilisé des octets qui n'étaient pas présents dans le fichier GGUF malveillant d'origine. Lors de mes tests, ce comportement était stable sur Ollama 0.17.0 et rejeté par le chemin corrigé .
0.17.1requests0.17.0 exposé sur un port API localollama-old-testExemple de cible de laboratoire :
docker run -d --name ollama-old-test -p 11435:11434 ollama/ollama:0.17.0
Installez la seule dépendance Python :
python3 -m pip install requests
Exécutez le test par défaut contre http://localhost:11435 et le conteneur ollama-old-test :
python3 exp.py
Arguments explicites :
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
Le script écrit des artefacts locaux tels que :
malicious_model.ggufcontrol_model.ggufquantized_model.ggufcontrol_quantized_model.ggufq8_dequantized_f32.binq8_pseudo_f16.binq8_pseudo_f16.txtLors de mes tests locaux, la version vulnérable d'Ollama a créé des sorties quantifiées où la charge utile du tenseur malveillant différait d'un tenseur de contrôle zéro, malgré le fait que le fichier GGUF malveillant ne contenait pas ces octets.
Cela suffit à montrer un artefact influencé par une lecture OOB. Cela ne suffit pas à revendiquer une divulgation pratique de données en boîte noire.
J'ai également testé des données de type canary dans des invites de modèle concurrentes et recherché dans les artefacts générés, les octets float32 déquantifiés Q8_0 et la sortie de reconstruction pseudo-F16. Je n'ai pas récupéré de canaries exactes ni de fragments de texte en clair significatifs.
La raison probable est que les octets ne sont pas copiés tels quels depuis la mémoire du tas. Ils passent par le pipeline de conversion et de quantification du modèle :
octets du tas -> interprétés comme des valeurs de tenseur F16/F32 -> convertis/quantifiés -> sortie de tenseur GGUF
Ce chemin est avec pertes, en particulier avec des formats quantifiés tels que Q4_K_M. Q8_0 préserve plus d'informations numériques que Q4_K_M, mais il n'a toujours pas produit de récupération fiable de texte en clair lors de mes tests de type boîte noire.
Il s'agit d'une reproduction en laboratoire local et d'un outil d'analyse d'artefacts.
Il ne fournit pas une primitive fiable d'exfiltration de secrets à distance. Il nécessite également un accès Docker local pour copier le blob généré par Ollama depuis le conteneur de test, donc l'étape d'analyse n'est pas un flux de travail pur en boîte noire à distance.
La conclusion pratique de mes tests est la suivante :
Il existe également un dépôt PoC séparé par 0x0OZ :
Cette implémentation démontre un flux de travail plus fort de type boîte blanche en poussant l'artefact de modèle généré vers un registre contrôlé. Avec le correctif du flux de téléversement de registre de ma PR, il se termine proprement dans mon laboratoire local :
Même avec ce meilleur chemin de collecte d'artefacts de bout en bout, la même réserve sur la qualité des données reste importante : la sortie est des données quantifiées/transformées par le modèle, pas un vidage direct de la mémoire du tas brute.
Ce dépôt est destiné uniquement à la recherche de vulnérabilités autorisée et à la reproduction défensive. Testez uniquement contre des systèmes que vous possédez ou pour lesquels vous avez une autorisation explicite d'évaluer.