Aller au contenu
Kreomnis.Vigie
CVE-2026-33626Élevée

LMDeploy : l'IA détournée en proxy d'attaque (SSRF sur le moteur d'inférence)

Publiée le 11/06/2026// Kreomnis
CVSS 3.1
-
EPSS : probabilité d'exploitation
-
Source : FIRST.org, modèle EPSS v3
Produits/versions affectés
  • LMDeploy < 0.12.3

Le contexte

LMDeploy est une boîte à outils pour compresser, déployer et servir des grands modèles de langage. CVE-2026-33626 est une Server-Side Request Forgery (SSRF) dans son module vision-langage, qui transforme le moteur d'inférence en proxy d'attaque.

Le tempo est caractéristique de 2026 : divulgation le 21 avril 2026, premières tentatives d'exploitation observées contre des honeypots moins de 12 h 31 plus tard. Le débrief tient en une phrase : « l'IA comme proxy d'attaque ».

La mécanique

La fonction load_image() dans lmdeploy/vl/utils.py récupère des URL arbitraires sans valider les adresses internes, privées, loopback ou link-local. Quand LMDeploy reçoit une URL d'image (cas d'usage normal d'un vision-LLM), le chargeur côté serveur va la chercher, y compris si elle pointe vers l'infrastructure interne.

Ce que l'attaquant en tire :

  • scan du réseau interne depuis le serveur d'inférence,
  • accès aux services de métadonnées cloud (typiquement 169.254.169.254, d'où la récupération de credentials de rôle),
  • énumération de services internes qui ne devraient jamais être joignables de l'extérieur.

La correction en 0.12.3 introduit une validation d'URL en bonne et due forme (is_safe_url), qui bloque les plages sensibles : 127.0.0.0/8 (loopback), 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 (link-local).

Versions impactées

| Produit | Version | Statut | | --- | --- | --- | | LMDeploy | < 0.12.3 | Vulnérable | | LMDeploy | 0.12.3 et ultérieures | Corrigée |

Comment patcher

pip install --upgrade "lmdeploy>=0.12.3"

Mitigations et durcissement :

  • Isolez le réseau du serveur d'inférence : pas d'accès sortant vers les plages internes ni vers l'endpoint de métadonnées cloud (169.254.169.254).
  • Sur les fournisseurs cloud, exigez IMDSv2 (jeton requis) pour neutraliser le vol de credentials via métadonnées.
  • Filtrez en sortie (egress) : un moteur d'inférence n'a aucune raison d'initier des connexions vers le RFC 1918 interne.
  • Si le patch tarde, désactivez le chargement d'images par URL ou restreignez-le à une allowlist de domaines.

PoC

Un laboratoire de reproduction et l'analyse Sysdig sont publics. L'exploitation étant confirmée in-the-wild, considérer toute instance exposée comme cible. Lier vers la source, ne pas ré-héberger d'exploit.

Ce qu'il faut retenir

Donner à un modèle la capacité d'aller chercher une URL, c'est lui donner un pouvoir de requête côté serveur. Sans validation, le moteur d'inférence devient une tête de pont vers votre réseau interne et vos métadonnées cloud.

Pour les RSSI et les équipes MLOps :

  • Patchez vers 0.12.3.

  • Tout composant IA qui fetch une URL est un SSRF en puissance : appliquez le même réflexe qu'aux webhooks et aux importeurs d'images : allowlist, blocage des plages internes, IMDSv2.

  • Cloisonnez l'inférence : segmentation réseau et filtrage egress limitent radicalement la valeur d'un SSRF.

  • Kreomnis

Références

#lmdeploy#ssrf#inference#vision-llm#cloud-metadata