Bleeding Llama : une faille de parsing GGUF expose la mémoire d'Ollama à des attaquants non authentifiés

De quoi s’agit-il ?

En mai 2026, des chercheurs de Cyera ont divulgué publiquement la CVE-2026-7482 (CVSS 9.1), une lecture hors limites non authentifiée dans Ollama, le moteur d’inférence locale très répandu. Ils l’ont nommée Bleeding Llama. La faille permet à un attaquant distant joignant l’API HTTP d’un serveur Ollama d’extraire des fragments arbitraires de la mémoire tas du serveur — variables d’environnement, clés d’API, system prompts, fragments de conversations d’autres utilisateurs — sans jamais s’authentifier.

Le défaut se situe dans le parser GGUF d’Ollama. Lorsque le serveur traite un fichier modèle GGUF dont les champs d’offset et de taille de tenseur déclarés dépassent la taille réelle du fichier, les fonctions de fs/ggml/gguf.go et server/quantization.go lisent au-delà du buffer alloué sur le tas pendant la phase de quantization. Le résultat est une fuite mémoire contrôlable.

Le correctif a été publié dans Ollama v0.17.1 le 25 février 2026 sans être identifié comme une release de sécurité. La CVE n’a été attribuée par Echo (un CNA tiers) que le 28 avril 2026, après que MITRE n’a pas répondu pendant près de deux mois, et le compte-rendu public a été publié en mai 2026. Pendant environ dix semaines, le correctif existait mais les exploitants n’avaient aucun signal pour le prioriser. Les instances Ollama exposées sur Internet — estimées à plus de 300 000 serveurs dans le monde — sont restées vulnérables pendant toute cette fenêtre.

Comment ça marche

Bleeding Llama est un cas d’école de rupture de périmètre de confiance : un serveur parse un format de fichier non fiable et fait confiance aux champs de métadonnées qui décrivent comment lire la charge utile.

# Schéma conceptuel basé sur l'advisory publique de Cyera.
# Aucun payload exploitable contre un système en production n'est reproduit.

[ attaquant ]
     │
     │ 1. POST /api/create   ─── upload d'un GGUF forgé avec une taille de tenseur gonflée
     ▼
[ serveur Ollama ]
     │
     │ 2. parsing des métadonnées GGUF
     │    └── l'offset / la taille du tenseur ne sont PAS bornés contre la taille du fichier
     │
     │ 3. l'étape de quantization lit N octets du tas
     │    où N est issu du descripteur de tenseur contrôlé par l'attaquant
     │    └── lecture hors limites au-delà du buffer alloué
     │
     │ 4. POST /api/push     ─── le serveur exporte le "modèle" résultant
     ▼
[ endpoint d'exfil de l'attaquant ]
     │
     └── octets du tas : env vars, clés API, system prompts, conversations d'autres utilisateurs

Deux éléments de contexte expliquent l’ampleur de l’impact.

D’abord, le format GGUF est le packaging standard des poids de modèles en local — tous les modèles open-weight modernes sont livrés sous cette forme. Un fichier GGUF n’est rien d’autre qu’un blob binaire avec un en-tête de métadonnées qui indique au chargeur où vit chaque tenseur et quelle est sa taille. Bleeding Llama est exactement la classe de bug que l’on prédirait pour cette architecture : le parser a fait confiance à l’en-tête.

Ensuite, les deux endpoints utilisés dans la chaîne (/api/create et /api/push) sont non authentifiés par défaut dans Ollama. La documentation amont le précise, et l’adresse de bind par défaut est 127.0.0.1, mais beaucoup de déploiements réels la surchargent avec OLLAMA_HOST=0.0.0.0 pour que la machine puisse servir le réseau d’un développeur ou une flotte de containers. Cette seule modification de variable d’environnement transforme Bleeding Llama d’une nuisance locale en primitive d’attaque distante exposée sur Internet.

La mémoire fuitée est le tas du processus Ollama, qui contient régulièrement : le system prompt en cours de service, les prompts utilisateur récents et les sorties du modèle, les variables d’environnement (qui sur les VM cloud incluent souvent des clés AWS / GCP / Anthropic / OpenAI), et du matériel TLS si la pile en a touché. Trois appels API suffisent pour reproduire une fuite contrôlable.

Pourquoi c’est important

Trois enseignements à retenir pour les équipes qui exploitent une infrastructure LLM.

Le premier est le plus évident : la surface d’attaque des runtimes LLM « locaux » est bien plus large que ce que les équipes anticipent. Ollama est souvent déployé avec le modèle mental d’un outil de développeur, mais c’est en pratique un serveur d’inférence joignable sur le réseau qui manipule des secrets et des données personnelles dès qu’un utilisateur lui parle. Les scans menés par des chercheurs externes en mai 2026 ont montré qu’une fraction significative de l’infrastructure IA auto-hébergée est exposée sur Internet sans authentification. Bleeding Llama est un exemple côté divulgation mémoire, mais la même posture est ce qui a rendu la CVE-2026-33626 (SSRF LMDeploy) et la CVE-2026-42208 (SQLi LiteLLM) massivement exploitables en quelques heures.

Le deuxième est le problème du patch silencieux. Le correctif a été publié en v0.17.1 le 25 février avec une note de version non sécurité. La CVE a été attribuée le 28 avril. Pendant soixante-dix jours, les opérateurs utilisant des scanners de vulnérabilités ou des outils de gestion de patchs n’avaient ni CVE à matcher ni signal de sévérité pour les pointer vers la mise à jour. Ce schéma n’est pas spécifique à Ollama — beaucoup de frameworks IA n’ont pas de pipeline d’advisory sécurité, et plusieurs backlogs de CNA MITRE ont dérapé sur la dernière année. Si votre inventaire IA dépend des flux CVE pour déclencher le patching, vous êtes structurellement en retard sur l’infrastructure IA.

Le troisième est l’implication GGUF en chaîne d’approvisionnement. Les fichiers de modèle sont désormais l’équivalent d’artefacts exécutables — ils pilotent de la logique de parsing complexe côté serveur. Les traiter comme des données inertes est une erreur. Tout pipeline qui ingère des fichiers GGUF venant de sources externes (téléchargements Hugging Face, registres mirrorés, fine-tunes uploadés par utilisateurs) est exposé à n’importe quel bug de parsing du consommateur. Bleeding Llama en est un ; ce ne sera presque certainement pas le dernier.

Défenses

Mettez à jour vers Ollama v0.17.1 ou ultérieur. C’est le seul correctif du bug de parser sous-jacent. Les anciennes versions ne sont pas patchables proprement en place car les vérifications de bornes ont été ajoutées à plusieurs endroits dans les chemins GGUF et de quantization.

Auditez votre adresse de bind et votre authentification. Si votre Ollama tourne avec OLLAMA_HOST=0.0.0.0 ou derrière un load balancer public, traitez-le comme un service exposé. Bindez sur 127.0.0.1 et accédez-y via SSH ou un VPN, ou placez-le derrière un reverse-proxy qui impose authentification et rate-limit sur /api/create et /api/push. L’advisory runZero documente des requêtes que vous pouvez utiliser pour repérer vos propres instances exposées.

Segmentez réseau votre runtime LLM hors des secrets. Une fuite de tas n’exfiltre que ce que le processus touche. Ne faites pas transiter de credentials cloud production, de clés d’API tierces, ni de PII via les variables d’environnement d’un serveur d’inférence exposé publiquement. Utilisez un sidecar avec un rôle IAM étroitement scoppé, ou un broker de secrets qui distribue des jetons à courte durée de vie à la demande. C’est le même principe qui limite le rayon d’impact d’une SSRF ou d’une RCE dans la même famille de frameworks IA.

Traitez le GGUF comme une entrée non fiable. Si votre pipeline tire des fichiers modèles de sources que vous ne contrôlez pas de bout en bout, validez l’en-tête de fichier hors process — par exemple en parsant les métadonnées dans un binaire sandboxé et en rejetant les fichiers dont les étendues de tenseur déclarées ne correspondent pas à la taille du fichier. Plusieurs registres open-weight commencent à publier des manifestes GGUF signés ; préférez-les.

Abonnez-vous aux advisories de vos éditeurs de runtime IA, pas seulement aux flux CVE. Bleeding Llama est le cas d’école qui montre pourquoi les flux CVE seuls sont insuffisants. Abonnez-vous directement aux GitHub Security Advisories d’Ollama, LiteLLM, LMDeploy, vLLM, et de votre fournisseur d’inférence. Surveillez leurs notes de version pour repérer les patchs silencieux et back-portez l’hypothèse que tout changement non trivial dans un parser peut être pertinent côté sécurité.

Adoptez les mitigations supply-chain du Top 10 OWASP LLM. OWASP LLM03 (Supply Chain) et LLM07 (System Prompt Leakage) s’appliquent directement ici. La révision 2026 référence désormais explicitement le parsing de fichiers modèles dans le périmètre supply-chain.

Statut

Élément	Référence	Date	Notes
CVE	CVE-2026-7482, CVSS 9.1	Attribuée le 2026-04-28 (CNA Echo)	Soumission initiale MITRE le 2026-03-02 ; réattribuée par Echo après non-réponse de MITRE
Découverte	Cyera Research (« Bleeding Llama »)	Divulgation publique mai 2026	Timeline de divulgation responsable documentée dans l’advisory Cyera
Patch	Ollama v0.17.1	2026-02-25	Publié sans étiquette de sécurité dans les notes de version
Compte-rendu public	Cyera / The Hacker News	2026-05	Confirme plus de 300 000 serveurs exposés dans le monde
Composant affecté	fs/ggml/gguf.go, server/quantization.go	—	Lecture hors limites sur le tas pendant la quantization
Versions affectées	Ollama < 0.17.1	—	Inclut toutes les branches mineures antérieures
Correspondance OWASP	LLM03 (Supply Chain), LLM07 (System Prompt Leakage)	Révision 2026	Le parsing de fichiers modèles est désormais dans le périmètre supply-chain
Divulgations liées	LMDeploy CVE-2026-33626 (SSRF), LiteLLM CVE-2026-42208 (SQLi), Langflow CVE-2026-33873 (RCE)	2026	Même schéma : endpoints non authentifiés de frameworks IA

Bleeding Llama n’est pas une attaque novatrice exotique — c’est un bug de safety mémoire classique dans un parser, enveloppé autour d’un format de fichier propre à l’IA. Ce qui justifie de le pointer du doigt, c’est la réalité opérationnelle qui l’entoure : le runtime est plus exposé réseau que ses utilisateurs ne le pensent, le patch a été silencieux, la CVE est arrivée en retard, et les octets fuités sont exactement les secrets que les déploiements LLM accumulent. Traitez vos serveurs d’inférence comme les services data-plane de production qu’ils sont devenus.