Incidents associés
%20(1).png)
La prolifération de l'IA a rapidement introduit de nombreuses nouvelles technologies logicielles, chacune présentant des erreurs de configuration potentielles pouvant compromettre la sécurité des informations. D'où la mission d'UpGuard Research : identifier les vecteurs propres à une nouvelle technologie et mesurer son cyber-risque.
Cette étude porte sur llama.cpp, un framework open source permettant d'utiliser des modèles de langage volumineux (LLM). Llama.cpp est susceptible de divulguer des invites utilisateur, mais comme il existe un petit nombre de serveurs llama.cpp en circulation, le risque absolu de fuite dû à llama.cpp est faible.
Cependant, en examinant les données d'invite exposées par des serveurs llama.cpp mal sécurisés, nous avons découvert deux adresses IP générant du texte pour des jeux de rôle sexuellement explicites impliquant des personnages mineurs. Bien que notre objectif en menant cette recherche soit de comprendre les risques associés aux serveurs llama.cpp exposés, les données exposées soulèvent certaines des préoccupations de sécurité les plus pressantes liées à l'IA générative.
Qu'est-ce que llama.cpp ?
Llama.cpp est un projet open source d'inférence du modèle LLaMA de Meta (et d'autres) en C/C++ pur. En termes simples, llama.cpp est un logiciel libre qui facilite l'exécution de modèles d'IA libres. Les produits d'IA les plus connus, comme ChatGPT d'OpenAI, Claude d'Anthropic ou Gemini de Google, utilisent des modèles propriétaires accessibles via une application créée par le propriétaire (comme celle que vous pouvez trouver sur chatgpt.com) ou via des API offrant un accès payant à ces modèles. Il existe également de nombreux modèles de langage étendus, gratuits et open source, que les utilisateurs peuvent télécharger, modifier et exécuter dans leurs propres environnements. Llama fait partie de la famille de modèles ouverts publiée par Meta et c'est pourquoi tant de logiciels liés à l'IA contiennent « llama » dans leur nom. Des projets comme llama.cpp ou Ollama fournissent l'interface permettant d'utiliser ces modèles.
Llama.cpp peut être configuré comme un serveur HTTP avec des API permettant aux utilisateurs distants d'interagir avec llama.cpp. Si llama.cpp est configuré pour exécuter un serveur et expose son interface à l'Internet public, les utilisateurs distants anonymes peuvent détecter le serveur llama.cpp et interagir avec lui. D'une manière générale, il est déconseillé d'exposer des API à Internet, sauf si elles sont réellement destinées à être accessibles à tous. Cependant, llama.cpp étant un logiciel libre et ouvert, il est couramment utilisé par des amateurs qui ne se soucient pas forcément de la sécurité des informations d'une application de simulation dans leur laboratoire personnel.
Ces deux fonctionnalités – des API HTTP accessibles au public et couramment utilisées par des personnes extérieures à la gouvernance d'entreprise – augmentent la probabilité que les utilisateurs configurent les serveurs llama.cpp avec des paramètres non sécurisés.
Risques liés à l'exposition des API llama.cpp
Pour étudier la prévalence réelle de ces risques, nous avons utilisé deux API llama.cpp « GET » : `/props` et `/slots`. Llama.cpp fournit également plusieurs API « POST » que nous n'avons pas tenté d'utiliser en raison du risque de perturbation du fonctionnement du serveur. Pour un audit de sécurité complet d'une application utilisant llama.cpp, vous devez également vous assurer que ces API « POST » ne peuvent pas être utilisées de manière abusive.
Le point de terminaison « /props » fournit des métadonnées sur les paramètres du modèle. Ceci est similaire aux données généralement exposées par les API Ollama. Les points de terminaison « v1/models » et « /health » fournissent les mêmes données accessibles via « /props », séparées pour être compatibles avec OpenAI ou simplifier les vérifications d'intégrité, respectivement. Comme ils fournissent des données redondantes, nous n'avons pas pris la peine de les appeler.
Le point de terminaison « /slots » fournit le texte des invites ainsi que les métadonnées relatives à leur génération. Si « /slots » est activé et accessible sans authentification, les utilisateurs anonymes peuvent lire les messages envoyés au modèle. Si quelqu'un utilise le modèle de quelque manière que ce soit, il est déconseillé d'exposer ses entrées. La documentation de llama.cpp inclut cet avertissement concernant « /slots » : « Ce point de terminaison est destiné au débogage et peut être modifié dans les versions futures. Pour des raisons de sécurité, nous déconseillons fortement de l'activer en environnement de production. » Bon conseil, équipe llama.cpp !
Prévalence et distribution globales de llama.cpp
Il convient tout d'abord de noter qu'un nombre relativement faible de serveurs llama.cpp ont été exposés dans le monde : seulement environ 400 à un moment donné lors de nos recherches en mars 2025. À titre de comparaison, le nombre de serveurs Ollama exposés est actuellement d'environ 20 000, soit près du triple de ce qu'il était il y a deux mois. Cependant, la possibilité pour des utilisateurs anonymes de lire les invites des serveurs llama.cpp les rend potentiellement plus efficaces et moins difficiles à exploiter.
Géographiquement, les serveurs llama.cpp sont concentrés aux États-Unis, l'Allemagne et la Chine occupant clairement la deuxième place. En comparant la distribution des serveurs llama.cpp à celle d'Ollama, llama.cpp est proportionnellement moins répandu en Chine et plus répandu en Allemagne.
Comme pour Ollama, les organisations propriétaires des adresses IP sont dispersées, ce qui indique une fois de plus des utilisateurs amateurs plutôt que des déploiements d'entreprise qui ont tendance à se regrouper chez les principaux fournisseurs de cloud comme AWS, Azure et Google.
Répartition des points de terminaison /slots et /props
Étant donné que /slots expose des informations plus sensibles que `/props(et que la documentation le déconseille explicitement), nous nous attendions à trouver beaucoup moins d'instances de/slotsque de/props`. Cependant, le nombre d'instances llama.cpp exposant leurs données d'invite était plus élevé que prévu : environ un tiers de tous les serveurs.
À l'inverse, le nombre d'instances exposant des propriétés système (un peu plus de la moitié) est relativement faible comparé aux milliers d'adresses IP exposant des données similaires via les API Ollama.
Que contiennent les invites ? ----------------------
Sur les 117 adresses IP exposant leurs invites, très peu correspondaient à une utilisation en « production ». Cinquante serveurs affichaient la dernière invite comme question par défaut pour tester les LLM : « Comment le principe d'incertitude affecte-t-il le comportement des particules ? » Quarante-quatre n'avaient aucune invite enregistrée. Une poignée d'entre eux comportaient des analyses standard de vulnérabilités logicielles, des invites identiques pour créer des questionnaires à choix multiples ou des documents publics – preuves de tests du modèle, mais non d'informations sensibles, et non utilisés en cours.
Les serveurs lama présentant de loin les invites les plus longues – celles dont la quantité de contenu pourrait indiquer une utilisation en « production » – étaient trois chatbots proposant des invites pour des jeux de rôle érotiques élaborés, de longue durée. Chacune de ces IP uniques utilisait un modèle différent – Midnight-Rose-70B, magnum-72b et L3.3-Nevoria-R1-70b – indiquant qu'il s'agissait très probablement de projets distincts partageant une fonction similaire. Deux de ces adresses IP étaient fréquemment mises à jour avec de nouvelles invites issues de différents scénarios ou personnages. Pour mesurer leur activité, nous avons collecté les invites sur ces adresses IP depuis « /slots » une fois par minute pendant 24 heures. À l'aide d'un hachage du texte de l'invite, nous avons ensuite dédupliqué les invites pour un total de 952 messages uniques sur cette période, soit environ 40 invites par heure. Nous n'avons ni soumis ni interagi avec l'interface d'invite, mais avons uniquement observé les invites exposées publiquement et accessibles via une analyse passive.
Après examen des données, la principale préoccupation était que certains contenus créés par ces LLM décrivaient des enfants (fictifs) âgés de 7 à 12 ans ayant des relations sexuelles.
Pour compter le nombre de scénarios uniques, nous avons extrait les 100 premiers caractères de chaque message afin d'obtenir un échantillon représentatif de l'invite système pour chaque scénario. Cette méthode a identifié 108 invites système ou scénarios narratifs uniques. Le scénario avec la conversation la plus longue comptait 150 messages sur la période de 24 heures. Sur les 108 scénarios, cinq impliquaient des enfants.
Bien que ce contenu ne concerne pas de véritables enfants, la prévalence du contenu d'abus pédosexuels généré par l'IA, même dans une faible proportion de ces données, montre à quel point les LLM ont facilité la création de ce type de contenu. De plus, il ne s'agit pas simplement de texte statique, mais d'un jeu de rôle interactif d'abus pédosexuels basé sur du texte, un contenu répugnant, voire illégal, que la technologie LLM rend facile à créer. En effet, de nombreux sites permettent déjà aux utilisateurs de créer des « personnages » pour des jeux de rôle « non censurés » dans des centaines de milliers de scénarios.
Conclusion
Les équipes de sécurité informatique doivent être conscientes que llama.cpp est une technologie susceptible d'être mal configurée et d'exposer des données confidentielles. L'analyse des cyberrisques d'UpGuard détecte les adresses IP exécutant llama.cpp afin de prévenir les violations de données par des tiers. Lors de l'utilisation de llama.cpp, les implémenteurs doivent connaître les consignes de configuration sécurisée, notamment l'interdiction d'activer le point de terminaison « /slots ». Dans cette enquête, nous n'avons détecté aucune exposition de données d'entreprise, mais le risque existe et les programmes de sécurité informatique doivent continuer à surveiller de tels événements.
Les détails des données accessibles via les API llama.cpp ne sont pas particulièrement pertinents pour les équipes de sécurité de l'information des entreprises, mais s'appliquent à la discussion plus large sur la sécurité de l'IA. L'observation empirique de l'exécution des LLM par le biais d'enquêtes de recherche s'inscrira dans le cadre du projet continu visant à comprendre l'impact de l'IA sur la société et les mesures de protection nécessaires.