LMDeploy SSRF : quand un chargeur d'images détourne l'infrastructure IA

Ce qui s’est passé

Le 21 avril 2026, l’équipe InternLM publie l’avis GHSA-6w67-hwm5-92mq pour CVE-2026-33626, une vulnérabilité de Server-Side Request Forgery dans LMDeploy, l’un des kits open source les plus déployés pour servir des modèles vision-langage et de grands modèles de langage. Le bug se loge dans load_image() (lmdeploy/vl/utils.py) : la fonction télécharge n’importe quelle URL fournie dans une requête vision sans vérifier si la destination pointe vers une adresse link-local, loopback ou RFC1918. NIST attribue la note CVSS 7.5 (élevée). Toutes les versions jusqu’à 0.12.2 incluse, compilées avec le support vision-langage, sont vulnérables ; 0.12.3 corrige.

Le sujet n’est pas le bug en lui-même — un SSRF reste un classique — mais le délai. L’équipe Sysdig observe la première tentative d’exploitation armée 12 heures et 31 minutes après la mise en ligne de l’avis GitHub, depuis l’IP 103.116.72[.]119. En une session de huit minutes, l’attaquant convertit le chargeur d’images en primitive HTTP SSRF générique et sonde la surface interne du nœud GPU.

Comment cela fonctionne

LMDeploy expose des endpoints vision-langage qui acceptent un corps JSON référençant une image. La bibliothèque passe cette URL à load_image(), qui appelle requests.get sans liste blanche, sans liste noire et sans DNS pinning. Tout ce que le conteneur d’inférence atteint, l’attaquant peut l’atteindre via l’API du modèle.

# Esquisse conceptuelle issue de l'avis public et de l'analyse Sysdig.
# Ne JAMAIS utiliser contre un système dont vous n'êtes pas propriétaire.
POST /v1/chat/completions  HTTP/1.1
Host: model.example.com
Content-Type: application/json

{
  "model": "internvl-2-8b",
  "messages": [{
    "role": "user",
    "content": [
      {"type": "text",      "text": "describe this image"},
      {"type": "image_url", "image_url": {
         "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
      }}
    ]
  }]
}

La chaîne d’exploitation reconstituée par Sysdig à partir des traces du honeypot touche cinq cibles successives : AWS Instance Metadata Service (IMDS) à 169.254.169.254, un port Redis interne, MySQL sur le même sous-réseau VPC, une interface administrative HTTP secondaire, puis un endpoint d’exfiltration DNS hors bande pour récupérer ce que les messages d’erreur du chargeur renvoient. Comme les nœuds vision-LLM tournent typiquement sur des instances GPU avec des rôles IAM larges — artefacts de modèles sur S3, datasets d’entraînement, parfois assume-role inter-comptes — un seul appel IMDS réussi suffit à basculer dans le compte cloud.

La preuve de concept publiée est la requête HTTP la plus simple possible ; pas d’astuce cryptographique nouvelle, pas d’exploit côté modèle. Tout l’intérêt éditorial est ailleurs : une catégorie entière d’infrastructure de service IA tournait silencieusement avec un bug d’application web hérité des années 2010, derrière un front-end GPU 2026.

Pourquoi c’est important

Trois propriétés justifient un article dédié.

La primitive est spécifique à l’IA, mais l’impact est cloud-wide. Un endpoint vision qui accepte une URL est, structurellement, un proxy HTTP doté d’identifiants. Quiconque expose de l’inférence open source derrière une route publique hérite de tout ce que le nœud GPU peut atteindre — et cette surface est large par construction (buckets de stockage de modèles, sinks de télémétrie, observabilité, APIs d’outils internes).

Le délai d’exploitation est quasi nul. 12 h 31 min est en dessous du cycle des workflows de patch management. Sysdig en fait un point d’inflexion : les attaquants surveillent désormais les avis GitHub des dépôts d’infrastructure IA et arment les divulgations en moins d’une journée de travail. Traiter les stacks GPU comme du code de recherche plutôt que comme des services web de production n’est plus tenable.

Les nœuds vision-LLM sont des coffres-forts d’identifiants. Le rôle d’instance qui permet au serveur d’inférence de streamer un modèle 70B depuis S3 atteint aussi l’IMDS. Aucune valeur par défaut « minimum privilege » n’est intégrée aux charts Helm et aux recettes Docker les plus déployés ; les équipes appliquent le rôle large géré par AWS parce qu’il fonctionne.

Défenses

Aucune mitigation côté modèle. Les correctifs sont d’infrastructure et d’exploitation.

1. Passez à LMDeploy 0.12.3 ou plus récent pour le correctif de validation d’URL. Revérifiez tous les forks et toutes les copies vendorées en interne — la fonction concernée est lmdeploy/vl/utils.py:load_image. L’avis est GHSA-6w67-hwm5-92mq.
2. Imposez IMDSv2 avec hop-limit 1 sur chaque instance GPU/inférence. IMDSv2 oblige un aller-retour par token que les primitives SSRF sans contrôle des en-têtes ne peuvent pas réaliser.
3. Filtrez en sortie le trafic des nœuds GPU et d’inférence. Le HTTP sortant d’un serveur de modèles doit atteindre une courte liste nommée d’endpoints : stockage objet, sinks de logs, télémétrie modèle. Tout le reste est bloqué, y compris par défaut link-local et RFC1918.
4. Scoper les rôles IAM par charge de travail. Un rôle de lecture des artefacts de modèles dans S3 suffit pour l’inférence. Le rôle utilisé pour l’entraînement, le fine-tuning ou l’orchestration de pipeline ne doit pas être attaché au nœud de service public.
5. Traitez les endpoints vision comme des récupérateurs de fichiers non sûrs. Tout service d’inférence qui résout des URLs côté serveur (vision, RAG, outils de scraping, document QA) doit faire ses fetchs dans un sous-réseau isolé, sans métadonnées, sans accès réseau interne, sans IAM partagé. Le conseil vaut pour vllm, Triton, Text Generation Inference et tout plug-in d’outil qui prend une URL.
6. Souscrivez aux GitHub Security Advisories des dépôts d’infra IA (InternLM/lmdeploy, vllm-project/vllm, huggingface/text-generation-inference, triton-inference-server/server, BerriAI/litellm, langchain-ai/langchain, microsoft/semantic-kernel). La mesure Sysdig devient l’hypothèse de travail : entre l’avis et l’exploit, comptez en heures, pas en jours.

Statut

Élément	Date	Statut
Avis GitHub GHSA-6w67-hwm5-92mq publié	2026-04-21	Public
Première exploitation observée dans la nature (Sysdig)	2026-04-22	Confirmée
Patch publié — LMDeploy 0.12.3	2026-04-21	Disponible
Note CVSS	—	7.5 (élevée)
Versions affectées	≤ 0.12.2 avec lmdeploy[vl]	Vulnérables

Au-delà du cas LMDeploy, la leçon plus large : les stacks d’inférence IA sont désormais traitées par les attaquants comme des services web à forte valeur. Le playbook défensif est, lui aussi, ordinaire — contrôles d’egress, IMDSv2, IAM scopé, patchs rapides — mais il doit réellement être appliqué aux machines qui font tourner les modèles, pas seulement à la couche applicative en amont.