Quand le chargeur d'images devient une SSRF : vol de métadonnées cloud sur les nœuds vision-LLM

De quoi s’agit-il ?

Le 21 avril 2026, les mainteneurs de LMDeploy — une boîte à outils open source très utilisée pour compresser, déployer et servir des grands modèles de langage et des modèles vision-langage — ont publié un avis de sécurité concernant une faille de server-side request forgery (SSRF) dans son module vision-langage. Le bug a été signalé par Igor Stepansky, chercheur chez Orca Security. En 12 heures et 31 minutes, l’équipe de recherche de Sysdig a enregistré la première tentative d’exploitation sur ses pots de miel, et dès le lendemain la faille était exploitée en conditions réelles. Cet article s’appuie sur l’avis public des mainteneurs et l’analyse post-incident ; aucun exploit fonctionnel n’y est reproduit.

La leçon dépasse largement une seule boîte à outils : lorsqu’un serveur de modèle récupère une URL pour vous, cette récupération constitue une surface d’attaque — et sur un nœud d’inférence GPU, elle peut se révéler particulièrement précieuse.

Comment ça marche

Les points d’accès multimodaux acceptent des images. Plutôt que d’obliger chaque appelant à téléverser des octets bruts, la plupart des piles de service permettent de passer une URL d’image, que le serveur récupère docilement. Dans le code concerné, la fonction de chargement d’image récupérait des URL arbitraires sans vérifier leur destination — pas de vérification de résolution de nom d’hôte, pas de liste de blocage des réseaux privés, pas de protection contre les adresses lien-local.

Cela transforme le point d’accès vision en une primitive de requête HTTP généraliste, contrôlée par quiconque peut appeler l’API. Au lieu d’une image, l’attaquant fournit une URL pointant vers l’infrastructure située derrière le serveur :

POST /v1/chat/completions            (une requête vision normale)
  image_url: http://169.254.169.254/latest/meta-data/iam/security-credentials/
        |
  le serveur récupère l'URL côté serveur, sans validation de destination
        |
  la réponse (ou le timing/erreur) révèle des ressources internes :
  métadonnées cloud (IMDS), Redis, MySQL, interfaces d'admin, ports loopback

Lors de l’intrusion observée, l’attaquant ne s’est pas contenté de confirmer la faille. En une seule session de huit minutes, il a utilisé le chargeur d’images pour sonder le réseau interne : le service de métadonnées cloud, une instance Redis, MySQL, une interface HTTP d’administration secondaire, et un rappel DNS hors bande pour confirmer l’accès sortant. Il alternait aussi entre différents modèles vision sur le même serveur pour se fondre dans le trafic légitime.

Pourquoi c’est important

Une SSRF classique est déjà problématique ; une SSRF sur un nœud de service d’IA l’est davantage, à cause de ce que ces nœuds détiennent. Les workers vision-LLM tournent généralement sur des instances GPU dotées de rôles cloud étendus — accès aux buckets d’artefacts de modèles, aux jeux de données d’entraînement, et souvent à des permissions d’assume-role inter-comptes. Une seule récupération réussie du service de métadonnées d’instance peut livrer à l’attaquant des identifiants IAM temporaires, et de là le rayon d’impact devient l’ensemble du compte cloud, pas seulement un conteneur.

La chronologie constitue l’autre point inquiétant. Cette faille a été armée en bien moins d’une journée, avant que la plupart des opérateurs ne puissent corriger, et sans preuve de concept publique à l’époque. Cela correspond à un schéma que les intervenants ont pointé directement : un avis détaillé — fichier concerné, nom de paramètre, explication de la cause racine, code d’exemple — équivaut à une invite prête à l’emploi pour qu’un modèle rédige un exploit. Les infrastructures d’IA sont scannées et frappées dans les heures qui suivent toute divulgation, quelle que soit la taille du projet.

Défenses

Validez chaque destination de récupération côté serveur. Résolvez d’abord le nom d’hôte, puis rejetez les plages privées, loopback et lien-local (y compris l’adresse de métadonnées) ainsi que les schémas non-HTTP. Revérifiez après résolution pour contrer le DNS rebinding, et privilégiez une liste d’autorisation d’hôtes d’images attendus plutôt qu’une liste de blocage.

Verrouillez le service de métadonnées. Exigez IMDSv2 (jeton de session) et fixez la limite de saut de la réponse à 1, afin qu’une SSRF relayée ne puisse pas l’atteindre. Ce seul contrôle neutralise l’étape la plus critique de l’attaque observée.

Appliquez le moindre privilège aux nœuds d’inférence. Un serveur de modèle a rarement besoin de rôles S3 ou inter-comptes étendus attachés à l’instance. Restreignez le rôle à ce que le service exige exactement, et gardez les permissions sur les données d’entraînement et les artefacts sur des identités distinctes.

Cloisonnez le trafic sortant et l’accessibilité interne. Refusez par défaut le trafic sortant des workers d’inférence, isolez-les de Redis, des bases de données et des interfaces d’administration, et alertez si un hôte de modèle se met soudainement à ouvrir des connexions DNS ou TCP vers des plages internes.

Corrigez dès l’avis, pas à votre convenance. Comme les failles d’infrastructure d’IA sont exploitées en quelques heures, traitez les avis des piles de service comme des changements d’urgence : passez rapidement à la version corrigée et surveillez les indicateurs publiés avec l’avis.

Statut

Élément	Détail
Référence	Avis GitHub GHSA-6w67-hwm5-92mq (CVE-2026-33626), CVSS 7.5
Divulgation	21 avril 2026 ; première tentative en conditions réelles en ~12,5 heures
Concerné	Module vision-langage de LMDeploy, toutes les versions avec support vision jusqu’à la version corrigée (0.12.x et antérieures selon l’avis)
Cause racine	load_image() récupérait des URL arbitraires sans valider les destinations internes/privées/lien-local
Impact	Scan du réseau interne, accès à Redis/MySQL/interfaces d’admin, vol de métadonnées cloud et d’identifiants IAM
Correctif	Passer à la version corrigée ; appliquer la validation de destination décrite dans l’avis