3 min de lecture
LMDeploy CVE-2026-33626 : une faille SSRF exploitée en moins de 13 heures
Une vulnérabilité critique dans LMDeploy, un outil populaire de déploiement de modèles de langage, a été activement exploitée moins de 13 heures après sa divulgation publique.
LMDeploy CVE-2026-33626 : une faille SSRF exploitée en moins de 13 heures
Le 24 avril 2026, la CVE-2026-33626 a été rendue publique. LMDeploy, un kit open source développé par Shanghai AI Laboratory pour compresser et déployer des modèles de langage, contient une faille de type SSRF (Server-Side Request Forgery) dans son module de traitement d'images pour les modèles vision-langage. Douze heures et trente et une minutes après la publication de l'avis, les premiers systèmes exposés étaient déjà sous attaque.
La rapidité de l'exploitation illustre une tendance qui s'est accentuée ces derniers mois : l'infrastructure IA, souvent déployée sur des instances GPU avec des droits d'accès très larges, est devenue une cible de choix pour les attaquants.
La mécanique de la vulnérabilité
La faille réside dans la fonction load_image() du module lmdeploy/vl/utils.py. Cette fonction, conçue pour charger des images à partir d'URL distantes dans les modèles vision-langage, ne valide pas les adresses IP privées ou internes. Un attaquant peut donc soumettre une URL pointant vers des ressources réseau internes plutôt que vers une image légitime.
En pratique, cela transforme le nœud d'inférence en proxy involontaire. Les chercheurs de Sysdig ont observé, lors d'une session d'attaque de huit minutes, un attaquant scanner le réseau interne via cette primitive SSRF : service de métadonnées AWS (IMDS), Redis, MySQL, interface d'administration HTTP secondaire, et exfiltration DNS hors-bande. Le score CVSS est fixé à 7,5. Toutes les versions antérieures à 0.12.0 intégrant le support vision-langage sont concernées.
Pourquoi l'impact potentiel est particulièrement grave
Les instances qui font tourner des nœuds LMDeploy sont typiquement des machines GPU avec des rôles IAM étendus : accès aux artefacts de modèles sur S3, aux jeux de données d'entraînement, et parfois à des permissions inter-comptes via assume-role. Une seule requête aboutie vers l'IMDS suffit à récupérer des jetons d'accès temporaires et, potentiellement, à compromettre l'ensemble du compte cloud.
Ce profil de risque dépasse largement celui d'une faille applicative classique. Il concerne directement les équipes qui hébergent des pipelines d'inférence sur AWS, GCP ou Azure, en particulier celles qui ont déployé des modèles multimodaux sans audit de sécurité préalable de la couche réseau.
La situation fait écho à d'autres incidents récents ciblant l'infrastructure de développement : la brèche OAuth sur Vercel Context AI ou encore les 1700 paquets npm malveillants attribués à la Corée du Nord. La surface d'attaque se déplace vers les couches basses de l'outillage IA.
Ce que ça signifie pour vous
La première action est de vérifier la version de LMDeploy utilisée dans vos pipelines et de mettre à jour vers 0.12.0 ou supérieur. Si une mise à jour immédiate n'est pas possible, l'exposition du port d'inférence au réseau public doit être bloquée, et les règles réseau doivent interdire les requêtes sortantes vers les plages d'adresses internes et l'IMDS.
Plus largement, cet incident invite à traiter les serveurs d'inférence avec le même niveau de vigilance que n'importe quel service exposé. Les permissions IAM attachées aux instances GPU méritent un audit régulier, et le principe du moindre privilège s'applique ici aussi.
Sources : The Hacker News · Sysdig · GitLab Advisory · Vulert