LMDeploy CVE-2026-33626 : SSRF exploité en 12 heures

Ce qui s'est passé

La vulnérabilité CVE-2026-33626 affecte LMDeploy, la boîte à outils open source du Shanghai AI Laboratory pour déployer et servir des modèles vision-language et de gros modèles de langage. La fonction load_image() de lmdeploy/vl/utils.py récupère des URLs arbitraires sans valider les adresses IP internes ou privées, ouvrant la porte à une Server-Side Request Forgery côté serveur de modèle. Toutes les versions antérieures à 0.12.3 sont concernées, ce qui représente la quasi-totalité des déploiements en production à la date de divulgation. Selon l'analyse publiée par la société de sécurité cloud Sysdig, le premier essai d'exploitation a été observé sur ses honeypots 12 heures et 31 minutes seulement après la publication du correctif sur GitHub, un délai parmi les plus courts jamais documentés pour une CVE non triviale dans l'écosystème LLM open source.

L'attaquant a détourné le loader d'images comme primitive HTTP générique pour cartographier le réseau interne derrière le serveur de modèle : Instance Metadata Service AWS (IMDS), Redis, MySQL, une interface admin HTTP secondaire, plus une exfiltration out-of-band via DNS vers un domaine contrôlé par l'attaquant. Le score CVSS de 7.5 sous-estime largement le risque réel : sur les nœuds vision-LLM, qui tournent généralement sur des instances GPU à rôles IAM larges (S3 d'artefacts modèles, datasets d'entraînement, cross-account assume-role), une seule requête IMDS suffit à compromettre l'intégralité du compte cloud.

Pourquoi c'est important

Cette CVE illustre une tendance de fond : les outils d'inférence LLM open source sont devenus des cibles de premier plan, et l'écart entre publication d'un advisory et premier exploit se compte désormais en heures. La logique business est imparable côté attaquant : un GPU H100 compromis vaut financièrement plus qu'un serveur web classique, et les permissions IAM accordées aux workloads ML sont presque toujours surdimensionnées par rapport au principe du moindre privilège. Les équipes MLOps, encore jeunes en moyenne, n'ont souvent pas intégré les réflexes hardening de la sécurité cloud traditionnelle.

Pour les équipes françaises qui exploitent des serveurs vision-LLM en production, le réflexe à adopter est double : isoler les inférences derrière un VPC sans accès IMDS v1 (forcer IMDSv2 avec hop limit à 1), et auditer systématiquement les rôles IAM attachés aux nœuds GPU pour les ramener au strict nécessaire. Côté supply chain, surveiller les advisories des dépôts upstream LMDeploy, vLLM et Triton avec la même rigueur que pour les CVE Linux ou Apache devient indispensable.

Ce qu'il faut retenir

• LMDeploy en version inférieure à 0.12.3 doit être mis à jour immédiatement, l'exploitation est confirmée.
• Forcer IMDSv2 et limiter les rôles IAM des nœuds vision-LLM réduit drastiquement l'impact.
• Le délai entre advisory et exploit sur les outils LLM est désormais inférieur à 24 heures.