Fuite critique de mémoire et failles RCE non corrigées affectent Ollama
Une vulnérabilité critique dans **Ollama**, surnommée 'Bleeding Llama', pourrait permettre à des attaquants non authentifiés de voler la mémoire de processus sensible. De plus, deux failles de RCE non corrigées dans le mécanisme de mise à jour Windows d'Ollama présentent un risque important, soulignant la nécessité de mesures de sécurité immédiates.

Des chercheurs en cybersécurité ont découvert une vulnérabilité de sécurité critique dans **Ollama** qui, si elle est exploitée, pourrait permettre à un attaquant distant et non authentifié de voler toute la mémoire du processus.
Cette faille de lecture hors limites, qui pourrait potentiellement affecter plus de 300 000 serveurs dans le monde, est suivie sous la référence **CVE-2026-7482** (score CVSS : 9.1) et a été nommée **Bleeding Llama** par **Cyera**.
**Ollama** est un framework open-source populaire qui permet l'exécution locale de grands modèles de langage (LLM). Le projet compte plus de 171 000 étoiles et a été forké plus de 16 100 fois sur GitHub.
"Ollama avant la version 0.17.1 contient une vulnérabilité de lecture hors limites du tas dans le chargeur de modèles GGUF", selon la description du CVE. "Le point d'accès `/api/create` accepte un fichier GGUF fourni par un attaquant dans lequel le décalage et la taille du tenseur déclarés dépassent la longueur réelle du fichier ; lors de la quantification dans fs/ggml/gguf.go et server/quantization.go (WriteTo()), le serveur lit au-delà du tampon alloué du tas."
**GGUF** (GPT-Generated Unified Format) est un format de fichier pour stocker de grands modèles de langage pour le chargement et l'exécution locaux.
La vulnérabilité découle de l'utilisation par Ollama du package `unsafe` lors de la création d'un modèle à partir d'un fichier GGUF, spécifiquement dans la fonction `WriteTo()`, contournant ainsi les garanties de sécurité de la mémoire.
### Scénario d'attaque
Un acteur malveillant peut envoyer un fichier GGUF spécialement conçu à un serveur Ollama exposé, en définissant la forme du tenseur sur un nombre extrêmement élevé pour déclencher la lecture hors limites du tas lors de la création du modèle via le point d'accès `/api/create`. Une exploitation réussie peut permettre de voler des données sensibles de la mémoire du processus Ollama.
Ces données volées peuvent inclure des variables d'environnement, des clés API, des invites système et les données de conversation des utilisateurs simultanés, qui peuvent ensuite être exfiltrées en téléchargeant l'artefact de modèle résultant via le point d'accès `/api/push` vers un registre contrôlé par l'attaquant.
La chaîne d'exploitation implique les étapes suivantes :
* Télécharger un fichier GGUF spécialement conçu avec une forme de tenseur gonflée vers un serveur Ollama accessible par le réseau à l'aide d'une requête HTTP POST.
* Utiliser le point d'accès `/api/create` pour activer la création du modèle, déclenchant ainsi la vulnérabilité de lecture hors limites.
* Utiliser le point d'accès `/api/push` pour exfiltrer les données de la mémoire du tas vers un serveur externe.
"Un attaquant peut apprendre pratiquement tout sur l'organisation à partir de votre inférence IA — clés API, code propriétaire, contrats clients, et bien plus encore", a déclaré Dor Attias, chercheur en sécurité chez **Cyera**.

"De plus, les ingénieurs connectent souvent Ollama à des outils comme Claude Code. Dans ces cas, l'impact est encore plus élevé — toutes les sorties des outils affluent vers le serveur Ollama, sont enregistrées dans le tas, et peuvent potentiellement tomber entre les mains d'un attaquant."
Il est conseillé aux utilisateurs d'appliquer les derniers correctifs, de limiter l'accès réseau, d'auditer les instances en cours d'exécution pour l'exposition à Internet, et de les isoler et de les sécuriser derrière un pare-feu. Le déploiement d'un proxy d'authentification ou d'une passerelle API devant toutes les instances Ollama est également recommandé, car l'API REST manque d'authentification intégrée.
### Deux failles non corrigées dans Ollama mènent à une exécution de code persistante
Des chercheurs de **Striga** ont détaillé deux vulnérabilités dans le mécanisme de mise à jour Windows d'Ollama qui peuvent être chaînées pour une exécution de code persistante. Ces lacunes restent non corrigées après leur divulgation le 27 janvier 2026, suite à une période de divulgation de 90 jours.
Selon Bartłomiej "Bartek" Dmitruk, co-fondateur de **Striga**, le client de bureau Windows démarre automatiquement à la connexion depuis le dossier Démarrage de Windows, écoute sur 127.0.0[.]1:11434, et interroge périodiquement les mises à jour en arrière-plan via le point d'accès `/api/update` pour exécuter toute mise à jour en attente au prochain démarrage de l'application.
Les vulnérabilités identifiées concernent un parcours de répertoire et une vérification de signature manquante qui, lorsqu'ils sont combinés avec la routine de démarrage automatique, peuvent permettre à un attaquant ayant la capacité d'influencer les réponses de mise à jour d'exécuter du code arbitraire à chaque connexion. Les failles sont listées ci-dessous :
* **CVE-2026-42248** (score CVSS : 7.7) - Une vulnérabilité de vérification de signature manquante qui ne vérifie pas le binaire de mise à jour avant l'installation, contrairement à sa version macOS.
* **CVE-2026-42249** (score CVSS : 7.7) - Une vulnérabilité de parcours de répertoire qui découle du fait que le programme de mise à jour Windows crée le chemin local du répertoire de staging de l'installateur directement à partir des en-têtes de réponse HTTP sans le nettoyer.
Pour exploiter ces failles, l'attaquant doit contrôler un serveur de mise à jour accessible par le client Ollama de la victime. Cela pourrait conduire à un scénario où un exécutable arbitraire est fourni dans le cadre du processus de mise à jour et est écrit dans le dossier Démarrage de Windows sans déclencher de problèmes de vérification de signature.
Une approche consiste à remplacer OLLAMA_UPDATE_URL pour pointer le client vers un serveur local en HTTP simple. La chaîne d'attaque suppose également que AutoUpdateEnabled est activé, ce qui est le paramètre par défaut.
Le contrôle d'intégrité manquant peut conduire à une exécution de code à lui seul, sans exploiter la vulnérabilité de parcours de répertoire. Dans ce cas, l'installateur est déposé dans le répertoire de staging attendu. Lors du prochain lancement depuis le dossier Démarrage, le processus de mise à jour est appelé sans revérifier la signature, provoquant l'exécution du code de l'attaquant.
Bien que cette exécution de code à distance ne soit pas persistante, car la prochaine mise à jour légitime écrase le fichier préparé, l'ajout du parcours de répertoire permet à un acteur malveillant de rediriger l'exécutable pour qu'il soit écrit en dehors du chemin habituel, réalisant ainsi une exécution de code persistante.
Selon **CERT Polska**, qui a pris en charge le processus de divulgation coordonnée, les versions 0.12.10 à 0.17.5 d'Ollama pour Windows sont vulnérables à ces deux failles. Dans l'intervalle, il est recommandé aux utilisateurs de désactiver les mises à jour automatiques et de supprimer tout raccourci Ollama existant du dossier Démarrage ("%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup") pour désactiver la voie d'exécution silencieuse au démarrage.
"Toute installation d'Ollama pour Windows exécutant les versions 0.12.10 à 0.22.0 est vulnérable", a déclaré Dmitruk. "Le parcours de répertoire écrit des exécutables choisis par l'attaquant dans le dossier Démarrage de Windows. La vérification de signature manquante les y maintient : le nettoyage post-écriture qui supprimerait les fichiers non signés sur un programme de mise à jour fonctionnel est une opération nulle sur Windows. Lors de la prochaine connexion, Windows exécute tout ce qui reste."
"La chaîne produit une exécution de code persistante et silencieuse au niveau de privilège de l'utilisateur exécutant Ollama. Les charges utiles réalistes incluent des shells inversés, des voleurs d'informations exfiltrant des secrets de navigateur et des clés SSH, ou des droppers qui pivotent vers des mécanismes de persistance supplémentaires. Tout ce qui s'exécute en tant qu'utilisateur actuel. La suppression du binaire déposé du dossier Démarrage met fin à la persistance, mais les failles sous-jacentes demeurent."