Comment auditer votre infrastructure LLM contre les vulnerabilites SSTI en 7 etapes

La multiplication des deploiements LLM en entreprise cree une nouvelle surface d attaque que la plupart des equipes securite n ont pas encore cartographiee. Les vulnerabilites de type SSTI (Server-Side Template Injection) dans les frameworks de serving LLM representent un risque critique : elles permettent l execution de code arbitraire a distance, souvent sans authentification. La recente CVE-2026-5760 dans SGLang (CVSS 9.8) en est la demonstration parfaite.

Ce guide vous donne une methodologie d audit en 7 etapes, applicable quelle que soit la taille de votre infrastructure d inference IA. Chaque etape est accompagnee d actions concretes, d outils recommandes et de criteres de validation.

— Etape 1 : Inventorier tous vos deploiements LLM

La premiere etape de tout audit est la cartographie. Vous ne pouvez pas securiser ce que vous ne connaissez pas. Les deploiements LLM ont la particularite d etre souvent inities par les equipes data science ou les equipes metier, parfois en dehors du perimetre de visibilite du RSSI.

Actions concretes :

• Scanner le reseau interne a la recherche de ports typiques des frameworks de serving LLM : port 30000 (SGLang), port 8000 (vLLM), port 8080 (TGI), port 11434 (Ollama). Utilisez nmap avec les scripts de detection de services.
• Interroger les equipes data science et R&D pour identifier les deploiements non recenses, les environnements de developpement et les POC (proof of concept) qui pourraient etre exposes sur le reseau interne.
• Verifier les orchestrateurs de conteneurs (Kubernetes, Docker Compose, ECS) pour les images contenant SGLang, vLLM, TGI ou Ollama. Utilisez kubectl get pods --all-namespaces ou docker ps pour lister les conteneurs actifs.
• Documenter chaque instance avec : nom du framework, version, modele(s) charge(s), format de modele (GGUF, SafeTensors, PyTorch), endpoints exposes, niveau d authentification, zone reseau.

Critere de validation : Vous disposez d un inventaire complet et a jour de tous les deploiements LLM de votre organisation, avec les informations de version et de configuration pour chaque instance.

— Etape 2 : Analyser les moteurs de templates utilises

Chaque framework de serving LLM utilise un moteur de templates pour formater les conversations, rendre les prompts et traiter les metadonnees des modeles. L objectif de cette etape est d identifier quel moteur est utilise et comment il est configure.

Points de verification par framework :

• SGLang : Utilise Jinja2 pour le rendu des chat_template. Verifiez le fichier entrypoints/openai/serving_rerank.py et tout fichier utilisant jinja2.Environment(). C est le vecteur exact de la CVE-2026-5760.
• vLLM : Utilise egalement Jinja2. Verifiez si SandboxedEnvironment ou ImmutableSandboxedEnvironment est utilise. Les versions recentes integrent le sandboxing, mais les versions anterieures peuvent etre vulnerables.
• TGI (Text Generation Inference) : Utilise minijinja, un moteur de templates Rust. Moins susceptible aux SSTI Python classiques, mais verifiez la version et les eventuelles vulnerabilites specifiques a minijinja.
• Ollama : Utilise les templates Go natifs. Le risque SSTI Python est elimine, mais d autres vecteurs d attaque peuvent exister dans le traitement des fichiers Modelfile.

Outils recommandes : Utilisez grep -r "jinja2.Environment" . dans le code source de chaque framework installe pour identifier les usages non sandboxes. Les outils d analyse statique comme Semgrep ou Bandit (Python) peuvent automatiser cette detection avec des regles predefinies pour les SSTI Jinja2.

— Etape 3 : Verifier la configuration du sandboxing

Le sandboxing est la defense principale contre les SSTI Jinja2. Cette etape consiste a verifier que chaque usage de Jinja2 dans votre stack LLM utilise un environnement sandboxe.

La difference critique :

• jinja2.Environment() : Environnement standard, AUCUNE restriction. Permet l acces aux classes Python, aux modules systeme, a l execution de commandes. C est la configuration vulnerable.
• jinja2.sandbox.SandboxedEnvironment() : Environnement sandboxe, bloque l acces aux attributs dangereux des objets Python. Empeche la plupart des payloads SSTI classiques.
• jinja2.sandbox.ImmutableSandboxedEnvironment() : Version la plus restrictive du sandboxing. Bloque egalement les modifications d objets. C est la configuration recommandee pour tout traitement de templates provenant de sources non fiables.

Actions concretes : Pour chaque instance identifiee a l etape 1, verifiez la configuration du moteur de templates. Si vous trouvez des usages de jinja2.Environment() traitant des donnees provenant de fichiers de modeles, c est une vulnerabilite critique a corriger immediatement. Remplacez par ImmutableSandboxedEnvironment() et testez que le rendu des templates fonctionne toujours correctement.

— Etape 4 : Scanner les fichiers de modeles charges

Meme avec un sandboxing correctement configure, les fichiers de modeles malveillants representent un risque. Cette etape consiste a inspecter systematiquement les metadonnees de chaque fichier de modele utilise dans votre infrastructure.

Actions concretes :

• Fichiers GGUF : Utilisez l outil gguf-dump (disponible dans le package gguf de llama.cpp) pour extraire et afficher toutes les metadonnees. Inspectez particulierement le champ tokenizer.chat_template a la recherche de patterns suspects : __class__, __mro__, __subclasses__, __import__, os.system, subprocess, eval, exec.
• Fichiers PyTorch (.pt, .bin) : Les fichiers PyTorch utilisent pickle pour la serialisation, ce qui permet l execution de code arbitraire au chargement. Utilisez fickling ou picklescan pour detecter les payloads malveillants. Privilegiez les modeles au format SafeTensors qui eliminent ce risque.
• Provenance des modeles : Documentez la source de chaque modele : depot Hugging Face officiel, fork communautaire, depot interne, partage ad hoc. Verifiez les signatures et les checksums SHA-256 lorsqu ils sont disponibles.

Critere de validation : Chaque fichier de modele en production a ete scanne et sa provenance documentee. Aucun payload suspect n a ete detecte dans les metadonnees. Les modeles provenant de sources non verifiees ont ete remplaces ou mis en quarantaine.

— Etape 5 : Tester l exploitation SSTI sur chaque endpoint

L analyse statique (etapes 2-4) ne suffit pas. Il faut valider les findings par des tests d exploitation reels dans un environnement controle. Cette etape est un mini-pentest cible sur les endpoints de vos serveurs d inference LLM.

Methodologie de test SSTI :

1. Preparez un modele GGUF de test contenant un payload SSTI benin dans le champ chat_template. Par exemple, un payload qui ecrit un fichier temoin dans /tmp/ sans causer de dommage. Ne jamais utiliser de payload destructif, meme en environnement de test.
2. Chargez le modele de test sur une instance de chaque framework identifie a l etape 1 (dans un environnement isole, jamais en production).
3. Envoyez des requetes vers chaque endpoint expose (/v1/rerank, /v1/chat/completions, /v1/completions) avec des inputs concus pour declencher le rendu du template.
4. Verifiez si le payload a ete execute (presence du fichier temoin, comportement anormal du serveur).
5. Documentez les resultats : endpoint, framework, version, resultat du test (vulnerable/non vulnerable), evidence.

Outils recommandes : Burp Suite Professional avec l extension Server-Side Template Injection pour automatiser les tests SSTI. tplmap (outil open source dedie aux SSTI) pour les tests manuels. Notre guide sur les methodologies de pentest detaille l approche complete.

— Etape 6 : Segmenter le reseau et durcir les serveurs d inference

Meme avec un sandboxing parfait et des modeles verifies, le principe de defense en profondeur impose d isoler les serveurs d inference pour limiter l impact d une eventuelle compromission. Cette etape couvre la segmentation reseau et le durcissement systeme.

Segmentation reseau :

• Placez les serveurs d inference dans un VLAN dedie avec des regles de firewall strictes. Les seuls flux autorises en entree doivent etre les requetes d inference depuis les applications clientes autorisees.
• Bloquez tout flux sortant non necessaire. Un serveur d inference n a pas besoin d acceder a Internet (sauf pour le telechargement initial des modeles, qui doit etre controle). Bloquez les reverse shells.
• Interdisez l acces direct aux bases de donnees de production, aux systemes d authentification (Active Directory, LDAP) et aux reseaux de management depuis le segment LLM.

Durcissement systeme :

• Executez les processus d inference avec un compte de service dedie, sans privileges root. Utilisez --user dans Docker ou les SecurityContext Kubernetes.
• Appliquez des profils seccomp et AppArmor restrictifs limitant les appels systeme autorises. Bloquez execve, ptrace et les sockets reseau non necessaires.
• Montez les systemes de fichiers contenant les modeles en lecture seule (readOnly: true dans Kubernetes, :ro dans Docker).
• Activez la journalisation des commandes executees et des connexions reseau sur chaque serveur d inference. Integrez ces logs dans votre SIEM.

— Etape 7 : Documenter les resultats pour la conformite NIS2

La derniere etape est la formalisation des resultats de l audit. La documentation n est pas une formalite administrative : c est une preuve de diligence raisonnable en cas de controle ANSSI ou d incident de securite. NIS2 impose aux entites regulees de pouvoir demontrer qu elles ont mis en oeuvre des mesures de gestion des risques proportionnees.

Elements a documenter :

• Inventaire des deploiements LLM (etape 1) : date d inventaire, instances identifiees, shadow IT decouvert le cas echeant.
• Analyse des moteurs de templates (etapes 2-3) : framework, version, type d environnement Jinja2 (sandboxe ou non), actions correctives appliquees.
• Rapport de scan des modeles (etape 4) : liste des modeles audites, provenance, resultats du scan, modeles mis en quarantaine.
• Resultats des tests d exploitation (etape 5) : endpoints testes, payloads utilises, resultats (vulnerable/corrige), preuves.
• Architecture reseau et durcissement (etape 6) : diagramme du VLAN LLM, regles de firewall, profils de securite appliques.
• Plan de remediation : vulnerabilites identifiees, actions correctives, responsables, delais, statut.
• Politique de supply chain des modeles : processus d approbation des modeles, sources autorisees, frequence de re-scan.

Critere de validation final : Vous disposez d un dossier d audit complet, date et signe, demontrant que votre infrastructure LLM a ete evaluee contre les risques SSTI et que des mesures correctives proportionnees ont ete mises en oeuvre. Ce dossier est directement exploitable en cas de controle ANSSI dans le cadre de NIS2. Pour approfondir, consultez notre guide sur la mise en conformite NIS2.

— FAQ