édition quotidiennecurated dispatchespas de rewritediffusion à l'aubelecture longuepublication rarearchivé à viesilence, puis signal
veilletechno
security2026.04.23il y a 15 jours2 min de lecture

CVE-2026-5760 (CVSS 9,8) : exécution de code arbitraire dans SGLang via un fichier GGUF piégé

CVE-2026-5760 affecte SGLang 0.59 : injection SSTI Jinja2 non sandbox sur /v1/rerank permet l'RCE via un GGUF malveillant. CVSS 9,8, aucun patch officiel disponible — mitigation manuelle requise.

#rce#llm#jinja2#ssti#gguf
§

Contexte

Les frameworks d'inférence LLM sont devenus une surface d'attaque critique. Le 20 avril 2026, CERT/CC coordonne la divulgation de CVE-2026-5760, une vulnérabilité de code injection de score CVSS 9,8 dans SGLang — l'un des runtimes LLM haute performance les plus utilisés en production pour servir des modèles open source. Le vecteur est inhabituel et préoccupant : l'attaque transite par un fichier de modèle GGUF spécialement forgé, ce qui signifie qu'un simple téléchargement depuis un dépôt communautaire non vérifié peut déboucher sur une prise de contrôle complète du serveur d'inférence.

Cette vulnérabilité appartient à une classe bien documentée sur les runtimes LLM : le CVE-2024-34359 (Llama Drama, llama_cpp_python, CVSS 9,7) et le CVE-2025-61620 (vLLM) exploitaient le même vecteur GGUF/Jinja2.

Points clés

  • Endpoint vulnérable : /v1/rerank — l'API de reclassification utilisée dans les pipelines RAG
  • Mécanisme : injection SSTI (Server-Side Template Injection) dans le champ tokenizer.chat_template d'un fichier GGUF malveillant
  • Déclencheur : une phrase associée au reranker Qwen3 active le chemin vulnérable dans entrypoints/openai/serving_rerank.py
  • Cause racine : jinja2.Environment() utilisé sans sandboxing au lieu de ImmutableSandboxedEnvironment
  • Impact : exécution de code arbitraire dans le contexte du processus SGLang
  • Versions affectées : SGLang ≤ 0.59
  • Patch officiel : aucun — les mainteneurs n'ont fourni ni réponse ni correctif lors de la coordination CERT/CC

Chaîne d'exploitation

L'attaquant construit un fichier GGUF avec un tokenizer.chat_template contenant un payload Jinja2. Lors du chargement du modèle, SGLang lit ce template. Dès qu'une requête atteint /v1/rerank, le template est rendu sans sandbox, exécutant le code Python arbitraire embarqué — y compris des appels système.

Le scénario le plus réaliste : un modèle communautaire malveillant posté sur HuggingFace Hub ou ModelScope, téléchargé par un opérateur sans vérification de l'intégrité du fichier. Dans les architectures multi-tenant où SGLang sert plusieurs équipes, la compromission d'un seul endpoint expose l'ensemble du nœud.

Mitigation (sans patch officiel)

  1. Remplacer jinja2.Environment() par jinja2.sandbox.ImmutableSandboxedEnvironment() dans le source SGLang
  2. Bloquer l'endpoint /v1/rerank si le reranking n'est pas utilisé (règle nginx ou pare-feu applicatif)
  3. Vérifier systématiquement le checksum (SHA-256) des fichiers GGUF avant chargement, et ne charger que depuis des sources de confiance
  4. Surveiller les appels syscall anormaux depuis le processus SGLang (via seccomp, Falco ou équivalent)
  5. Mettre à jour vers la prochaine release dès qu'un patch officiel est publié — suivre le dépôt sgl-project/sglang pour les advisories

Disclosure CERT/CC via CIRCL · PT Security advisory · The Hacker News