DEF CON 34 : 10 vulnérabilités mettent l’IA locale en danger

L’IA locale offre aux organisations davantage de confidentialité, de maîtrise des coûts et de contrôle de leurs données, mais l’exécution des modèles en local n’élimine pas les risques de sécurité. 

Les recherches présentées dans le cadre de DEF CON 34 ont identifié 10 vulnérabilités dans llama[.]cpp, un moteur d’inférence largement adopté qui sous-tend de nombreuses applications d’IA locale.

À retenir

• Les chercheurs ont identifié 10 vulnérabilités dans llama[.]cpp, notamment des failles de type use-after-free, de dépassement d’entier et d’accès mémoire hors limites affectant plusieurs frontières de confiance.
• Deux vulnérabilités de llama-server ont reçu un score CVSS de 9,2, soulignant le risque potentiel pour les organisations qui exposent des services d’inférence d’IA locale à du trafic non fiable.
• L’IA locale n’élimine pas les risques de sécurité.Conserver les invites et les données sensibles sur l’infrastructure de l’organisation exige néanmoins de sécuriser le moteur d’inférence, les modèles, les API, les dépendances et l’infrastructure de support.
• Les organisations doivent identifier où llama[.]cpp est déployé et réduire son exposition, notamment en renforçant la sécurité des API exposées sur Internet, en validant les entrées non fiables, en corrigeant les composants vulnérables, en segmentant les charges de travail d’IA et en surveillant toute activité suspecte.

Comprendre llama.cpp et l’inférence locale des LLM

L’inférence d’un grand modèle de langage (LLM) consiste à charger en mémoire les poids d’un modèle entraîné, à traiter les jetons d’entrée par le modèle et à générer la sortie un jeton à la fois. 

Avec une inférence distante, les invites et les données sont transmises à un fournisseur externe. L’inférence locale effectue au contraire ces opérations sur une infrastructure contrôlée par l’utilisateur ou l’organisation.

Cette distinction est importante pour les organisations qui traitent de la propriété intellectuelle, des informations classifiées, des stratégies financières propriétaires ou d’autres données sensibles qui ne peuvent pas être transmises à des fournisseurs d’IA tiers.

Qu’est-ce que llama.cpp et comment prend-il en charge l’IA locale ?

Llama[.]cpp est devenu un composant majeur de cet écosystème. 

Écrite principalement en C/C++, cette bibliothèque charge les fichiers de modèles GGUF, gère les contextes d’inférence, effectue la tokenisation et les calculs du modèle, et fournit des interfaces utilisées par d’autres applications. 

Elle sert de backend ou de couche d’intégration à des produits comme Ollama, LM Studio, Jan et GPT4All.

Son adoption généralisée signifie également que les vulnérabilités du moteur sous-jacent peuvent potentiellement affecter de nombreuses implémentations en aval.

Les vulnérabilités de Llama[.]cpp exposent de graves failles de sécurité mémoire

Les chercheurs de Cyera ont audité llama[.]cpp en s’intéressant particulièrement à trois frontières de confiance : 

• les intégrations Android Java Native Interface (JNI)
• le cycle de vie HTTP de llama-server
• le traitement des métadonnées des modèles GGUF

La recherche a identifié des vulnérabilités liées à des problèmes classiques de sécurité mémoire, notamment les use-after-free (UAF), les dépassements d’entier et les accès hors limites. 

VulnCheck a ensuite attribué les identifiants CVE-2026-43622 à CVE-2026-43632 aux vulnérabilités signalées, à l’exception de CVE-2026-43625 (vulnérabilité de CodexBar).

En juin 2026, après évaluation de la build b9445 et de gguf-v0.19.0, les chercheurs ont indiqué que cinq des 10 vulnérabilités n’avaient toujours pas été corrigées. 

Parmi les plus importantes figuraient deux vulnérabilités UAF du serveur, CVE-2026-43631 et CVE-2026-43632, chacune affichant un score CVSS de 9,2.

Comment les failles de concurrence créent des risques pour la sécurité mémoire dans l’IA locale

Plusieurs résultats montrent comment la concurrence peut transformer de simples erreurs de gestion mémoire en vulnérabilités de sécurité.

La concurrence dans le JNI Android crée des risques de use-after-free

Dans une ancienne intégration JNI Android, plusieurs opérations partageaient des pointeurs natifs globaux. 

Un thread d’arrière-plan pouvait effectuer une inférence tandis qu’un autre libérait le même contexte. 

En l’absence d’une synchronisation suffisante, le premier thread pouvait ensuite accéder à une zone mémoire déjà libérée.

Les chercheurs ont indiqué avoir exploité cette situation en récupérant la mémoire libérée et en manipulant l’exécution ultérieure du programme.

Une faille de llama-server expose une autre condition de use-after-free

Un problème similaire de gestion du cycle de vie affectait llama-server. 

Lorsque la fonctionnalité –sleep-idle-seconds était activée, l’arrêt des ressources inutilisées pouvait libérer des ressources du modèle ou du vocabulaire tandis qu’un autre worker continuait de traiter une requête utilisant ces ressources. 

Cela créait une autre condition UAF potentiellement accessible via l’interface du serveur.

Ces résultats soulignent un aspect important de la sécurité de l’IA locale : conserver les invites sur site ne garantit pas automatiquement la fiabilité de la pile d’inférence sous-jacente. 

Comment atténuer les vulnérabilités de llama[.]cpp

Les organisations qui utilisent llama[.]cpp doivent d’abord déterminer où la bibliothèque est présente dans leur environnement d’IA, y compris dans les applications qui l’intègrent indirectement.

Renforcer llama-server et l’exposition des API

Les déploiements de llama-server exposés sur Internet ne doivent pas activer la fonctionnalité –sleep-idle-seconds lorsqu’ils acceptent du trafic HTTP non fiable, tant qu’il n’est pas confirmé que les vulnérabilités UAF concernées ont été corrigées. 

Les API doivent éviter toute exposition sans restriction sur 0.0.0.0 et utiliser plutôt une authentification avec un proxy inverse ou une couche comparable de contrôle d’accès afin de limiter les accès non autorisés. 

Sécuriser les intégrations de llama.cpp et les entrées non fiables

Les développeurs Android qui utilisent l’ancien wrapper JNI llama-android[.]cpp doivent abandonner les versions antérieures à la build b7446 et examiner les composants natifs pour détecter tout accès concurrent non sécurisé.

Les applications qui utilisent llama_batch_init doivent valider toute entrée non fiable avant de la transmettre au code natif. 

De même, les applications doivent éviter de restaurer un état ou des données de cache KV provenant de sources non fiables tant que les vulnérabilités de sécurité mémoire correspondantes n’ont pas été résolues. 

Comment sécuriser l’IA locale et les modèles à poids ouverts

L’inférence locale offre d’importants avantages en matière de confidentialité et de contrôle, mais ces avantages impliquent de sécuriser également l’environnement d’exécution lui-même.

La corruption mémoire, les cycles de vie d’objets non sécurisés, les fichiers de modèles malveillants et les API d’inférence exposées peuvent créer des surfaces d’attaque comparables à celles des applications natives traditionnelles.

Les organisations qui adoptent l’IA à poids ouverts doivent donc considérer les moteurs d’inférence comme une infrastructure sensible du point de vue de la sécurité et mettre en place des contrôles tels que :

• Tenir à jour un inventaire des modèles d’IA locale, des moteurs d’inférence, des dépendances et des autres composants.
• Limiter l’exposition réseau et segmenter les charges de travail d’IA des systèmes de production sensibles.
• Appliquer le principe du moindre privilège et une authentification forte aux API d’inférence et aux fonctions d’administration.
• Valider et analyser les fichiers de modèles, les fichiers d’état, les dépendances et les autres artefacts avant leur déploiement.
• Appliquer rapidement les correctifs de sécurité et surveiller les projets en amont ainsi que les dépendances à la recherche de nouvelles vulnérabilités divulguées.
• Isoler les charges de travail d’inférence dans des conteneurs, des machines virtuelles ou d’autres mécanismes d’isolation lorsque cela est approprié.
• Journaliser et surveiller l’activité des systèmes d’IA, et tester régulièrement les plans de réponse aux incidents afin de garantir que les équipes peuvent contenir les incidents de sécurité liés à l’IA et s’en remettre.

Ensemble, ces mesures peuvent aider les organisations à réduire leur exposition aux menaces liées à l’IA tout en renforçant leur résilience. 

En résumé

Les vulnérabilités de llama[.]cpp mettent en évidence une réalité importante de l’IA locale : conserver les données sensibles dans l’environnement de l’organisation peut améliorer la confidentialité et le contrôle, mais n’élimine pas les risques de sécurité. 

Les organisations doivent sécuriser les moteurs d’inférence, les modèles, les dépendances et l’infrastructure qui traite ces données afin de réduire leur exposition et de renforcer la résilience de leurs déploiements d’IA locale. 

Zero Trust peut étendre ces protections en imposant le principe du moindre privilège, en validant continuellement la confiance et en limitant l’impact potentiel d’une charge de travail ou d’un composant d’IA compromis.