CVE-2026-33626 : LMDeploy révèle segmentation AI Stack en 12,5h
LMDeploy-SSRF (CVE-2026-33626) a été exploité en 12,5 heures. Trois conséquences architecturales pour les équipes cloud utilisant des piles de vision-inférence.
Le 22 avril 2026 à 03:35 UTC, Sysdig a observé la première tentative réelle d’exploitation de CVE-2026-33626 dans un honeypot, 12 heures et 31 minutes après la publication de l’avis GitHub. Le chemin d’attaque dans une installation de modèle Vision-Language de LMDeploy a traversé le service AWS Instance Metadata, une instance Redis locale et un port backend MySQL en moins de huit minutes. Pour les architectes cloud, ce cas est moins un problème de LMDeploy qu’une question architecturale : pourquoi les serveurs d’inférence se trouvent-ils dans le même segment VPC que les backends stateful ; qui porte la responsabilité opérationnelle de cette segmentation dans la pile IA de 2026 ?
- CVE-2026-33626 dans LMDeploy (CVSS 7.5) : Vision-LLM-SSRF via la fonction load_image(), exploit documenté par Sysdig-Honeypot en 12,5 heures après l’avis (22.04.2026, 03:35 UTC).
- Chaîne d’attaque : le point de terminaison Vision-API charge n’importe quelle URL sans validation de l’IP privée. Résultat : accès IMDS (169.254.169.254), énumération des services internes, exfiltration des identifiants cloud.
- L’exploit utilise des rappels de dépôt de requêtes et des modèles changeants (internlm-xcomposer2, InternVL2-8B) pour le camouflage. Outil automatisé, non manuel.
- La leçon structurelle : les serveurs de modèles ne doivent pas se trouver dans le même segment VPC que les backends stateful. Les bloqueurs d’IP privées ne suffisent plus comme mesure de protection en 2026.
- Pour les architectes cloud DACH, cela signifie trois tâches concrètes : segmentation du réseau, mise en œuvre de IMDSv2 et surveillance des sorties spécifiques à LLM dans la prochaine planification de sprint.
Ce que la CVE-2026-33626 génère techniquement
Qu’est-ce que la falsification de requête côté serveur (SSRF) ? La SSRF désigne une classe de vulnérabilités où un attaquant incite le serveur à envoyer des requêtes HTTP vers des destinations qui ne sont pas directement accessibles à l’attaquant. Classiquement, les attaquants utilisent cela pour cibler des services internes (points de terminaison de métadonnées, bases de données, interfaces d’administration) qui devraient être isolés de l’Internet public. Dans les piles d’inférence, la SSRF est particulièrement dangereuse car les serveurs Vision-LLM sont architecturalement conçus pour charger des images à partir de n’importe quelle URL – et c’est précisément ce cas standard qui constitue le vecteur d’attaque.
Dans LMDeploy, la vulnérabilité réside dans la fonction load_image() du module lmdeploy/vl/utils.py. La fonction accepte une URL et charge l’image pour le pipeline de vision en aval. Une validation de l’adresse IP privée fait défaut dans la version affectée. Un attaquant envoie une requête de vision normale avec une URL comme http://169.254.169.254/latest/meta-data/iam/security-credentials/ et reçoit, tant que le serveur d’inférence possède des identifiants AWS-IAM, les métadonnées de réponse correspondantes. Le Vision-LLM devient ainsi le messager qui publie son propre magasin de crédits cloud.
La chaîne d’attaque observée par Sysdig est méthodique et pilotée par des outils. Phase une : appel au AWS-IMDS pour l’exfiltration des identifiants. Phase deux : sondes contre Redis localhost (port 6379) pour énumérer les caches clé-valeur mal configurés. Phase trois : scans du port MySQL 3306 sur les adresses internes, accompagnés de rappels DNS hors bande via requestrepo.com pour confirmer les chemins SSRF aveugles. Selon Sysdig, l’ensemble du processus prend moins de huit minutes et est plus difficile à détecter en raison des rotations de modèles qu’une attaque classique de script kiddie.
Pourquoi les piles d’inférence sont systématiquement vulnérables
Les serveurs de modèles de langage de vision ont une propriété qui est rarement aussi prononcée dans le monde traditionnel du backend : leur tâche fonctionnelle est de charger et de traiter des contenus externes. C’est un vecteur SSRF né. En même temps, ces serveurs sont souvent exploités dans les mêmes segments VPC que les bases de données vectorielles, les magasins de fonctionnalités et les caches d’applications dans de nombreuses piles d’inférence DACH, car la latence doit être optimisée et l’architecture semble « logique » sur le tableau blanc. Cette co-localisation n’est plus supportable en 2026.
Trois indicateurs clés issus de l’avis de Sysdig
Les trois tâches pour les architectes cloud
Tâche 1 : Serveurs d’inférence dans des segments VPC dédiés
La première et la plus importante mesure : les serveurs de modèles de vision et de langage doivent être placés dans des segments VPC dédiés sans route directe vers les backends stateful comme Redis, MySQL, Postgres, MongoDB ou les interfaces d’administration internes. Ce n’est pas de la théorie, mais une conséquence de la propriété fonctionnelle du serveur de modèle (chargement d’URL arbitraires). Dans les configurations Terraform, cela signifie concrètement : des sous-réseaux dédiés, des groupes de sécurité dédiés avec des règles de sortie explicites, pas de routes de peering vers les sous-réseaux de bases de données. Ceux qui n’ont pas cette segmentation ne peuvent pas empêcher complètement l’exploit LMDeploy, peu importe la rapidité avec laquelle le patch est appliqué.
Une étape intermédiaire pragmatique : l’introduction d’une « zone AI » comme troisième zone de sécurité aux côtés de la DMZ et du réseau interne. Dans la zone AI, les serveurs de modèles, les passerelles de modèles et les répliques de Vector-DB fonctionnent. Les backends stateful restent dans le réseau interne. Le trafic entre les zones passe exclusivement par des comptes de service avec des politiques strictes. Nous constatons chez nos clients que cette topologie peut être mise en place en quatre à six semaines, même dans des environnements brownfield avec une infrastructure existante.
Tâche 2 : Forcer IMDSv2, ne pas permettre de restes v1
L’exploit LMDeploy a récupéré les identifiants IAM via le chemin IMDSv1 (Simple HTTP GET sur 169.254.169.254). AWS a défini IMDSv2 comme standard depuis 2023, mais de nombreux déploiements legacy fonctionnent encore sur v1. Azure et GCP disposent de services de métadonnées analogues avec des mécanismes de protection similaires. La conséquence opérationnelle : forcer IMDSv2 dans tous les modèles de lancement EC2 (HttpTokens = « required »), sécuriser le service de métadonnées d’instance Azure avec des requêtes d’en-tête, et sécuriser les métadonnées GCP avec une vérification d’en-tête de type Metadata-Flavor. Pour les équipes DACH avec plusieurs comptes AWS, nous recommandons une politique SCP au niveau de l’organisation qui interdit globalement IMDSv1. Cela permet également de capturer les charges de travail legacy qui passent à travers les mailles des configurations de comptes individuels.
Tâche 3 : Surveillance Egress spécifique aux LLM
Un SIEM classique ne détecte souvent pas une attaque SSRF sur un LLM de vision, car les requêtes ressemblent à des chargements d’images normaux. La détection fonctionne mieux au niveau Egress : quelles destinations le serveur d’inférence a-t-il réellement contactées ? Si un LLM de vision a fait 15 requêtes à 169.254.169.254 au cours de la dernière heure, c’est un signal. Si le même serveur envoie des requêtes à requestrepo.com, oast.pro ou burpcollaborator.net, c’en est un autre. La mise en œuvre concrète : un proxy Egress avec un routage basé sur une liste d’autorisation et des alertes sur les anomalies dans le trafic sortant. Ceux qui n’ont pas cela ne verront l’attaque que dans les rapports de facturation, lorsque les identifiants auront déjà été exfiltrés.
Regard sur la chaîne d’approvisionnement des composants d’inférence
Un autre aspect qui reste caché dans le cas actuel est la dimension de la chaîne d’approvisionnement. LMDeploy est un composant open-source utilisé dans de nombreuses piles de production DACH, souvent comme dépendance transitive dans des pipelines d’inférence faits maison ou comme partie de déploiements Kubernetes à partir de charts Helm tiers. Ceux qui n’ont pas un SBOM (Software Bill of Materials) clair pour leur infrastructure AI ne savent pas où LMDeploy est actif en cas d’urgence. Cela transforme le patching en un jeu de cache-cache et retarde considérablement le temps de réaction.
La contre-mesure pragmatique : un SBOM pour l’ensemble de la pile AI, idéalement automatisé par la génération de CycloneDX ou SPDX dans la pipeline CI. Pour les équipes de taille moyenne, un snapshot SBOM hebdomadaire avec un rapport delta reflétant les CVE critiques contre la liste des composants internes suffit pour la première année. L’ensemble d’outils pour cela est disponible (Trivy, Syft, Dependency-Track), l’organisation doit simplement l’introduire. Ceux qui le font maintenant seront beaucoup mieux préparés pour la prochaine CVE dans trois semaines que les organisations qui ont dû rechercher LMDeploy manuellement.
Ce que cela signifie pour votre propre processus de patch
L’observation de l’exploitation rapide chez LMDeploy n’est pas un cas isolé. La CVE-2026-33626 s’inscrit dans une série de vulnérabilités de la pile d’inférence qui ont été exploitées en heures plutôt qu’en semaines en 2026. Cela a des conséquences pour le processus de patch. Un accord de niveau de service (SLA) de patch classique de 30 jours n’est plus approprié pour les piles d’inférence. La nouvelle attente : des patches critiques dans les composants des serveurs d’IA dans un délai de 24 à 72 heures, idéalement automatisés via des mises à jour de Helm Chart avec des déploiements contrôlés par des politiques.
Pour les organisations de la région DACH (Allemagne, Autriche, Suisse), cela signifie un investissement dans la pipeline de patch : surveillance continue des CVE pour l’ensemble de l’inventaire de la pile d’IA (LMDeploy, vLLM, TGI, Ray Serve, Triton, Ollama, LiteLLM), responsabilité claire pour chaque composant et déploiements automatiques avec une stratégie de canary. Ceux qui n’ont pas cette pipeline sont structurellement en dehors de la réponse de 24 heures nécessaire en 2026.
L’aspect organisationnel est souvent plus complexe que l’aspect technique. De nombreuses équipes DACH maîtrisent bien le processus de patch pour les serveurs d’applications et les bases de données, car les responsabilités y sont claires. Les piles d’IA sont organisationnellement situées entre l’ingénierie de plateforme, la science des données et la sécurité, et chaque partie croit que l’autre est responsable. La conséquence pour les leaders dans cet environnement : désigner un responsable de patch pour chaque composant d’IA par écrit, avec des SLA d’escalade et des responsabilités dans le tableau de bord des opérations. Ceux qui traitent ce sujet comme une affaire intermédiaire n’auront pas la prochaine CVE corrigée plus rapidement, mais plus tard. La question de la responsabilité est celle qui déterminera la capacité de patch de votre organisation au cours des trois prochains trimestres. Ceux qui la laissent non résolue retarderont chaque nouveau cas d’exploit exactement aussi longtemps que la coordination entre les trois équipes prendra.
Le rôle du Model-Gateway dans la nouvelle topologie
Un sujet souvent absent des discussions actuelles sur LMDeploy : le rôle du Model-Gateway en tant que couche architecturale. Un Model-Gateway (Kong AI-Gateway, LiteLLM, Portkey, Vercel AI Gateway) est idéalement placé avant le serveur de modèle lui-même et prend en charge l’authentification, la limitation de débit, le filtrage des PII et l’observabilité. Pour les attaques SSRF, le gateway a une fonction supplémentaire : il peut valider les URL d’images avant de les transmettre au serveur de modèle, filtrer les plages d’IP privées et imposer des règles de sortie. Ceux qui intègrent un gateway dans leur topologie obtiennent une deuxième ligne de défense qui fonctionne indépendamment du code du serveur de modèle lui-même.
L’intégration d’un Model-Gateway coûte entre 30 000 et 90 000 euros la première année dans un environnement typique de PME (licence, intégration, formation opérationnelle). L’investissement s’amortit principalement par deux effets. Premièrement, la réduction du rayon d’impact des vulnérabilités du serveur de modèle comme la CVE-2026-33626. Deuxièmement, l’observabilité unifiée sur plusieurs serveurs de modèle, qui doit autrement être laborieusement mise en place pour chaque fournisseur dans des configurations hétérogènes. Ceux qui n’ont pas encore de Model-Gateway en 2026 devraient l’introduire au plus tard au troisième trimestre.
Ce que le collègue de la sécurité de l’App-Dev en dit
Un bref retour à la réalité de la pratique du point de vue des Cloud-Ops : ceux qui ont grandi dans le monde de l’App-Dev connaissent le SSRF depuis des années grâce à l’OWASP Top 10. Les contre-mesures classiques (validation des URL, blocage des IP privées, protection contre le DNS rebinding) sont souvent disponibles en tant que middleware dans les frameworks web. Dans les piles d’inférence de 2024 et 2025, cette couche a souvent été négligée ou déclarée « spécifique à l’IA ». L’exploit de LMDeploy montre que les leçons de l’App-Dev s’appliquent aux piles d’IA sans changement, avec seulement de petites adaptations. Ceux qui demandent à leur organisation de sécurité de réaliser une revue SSRF sur tous les composants d’IA obtiennent généralement une analyse des écarts fiable en deux semaines. C’est le retour sur investissement le plus rapide dans la semaine post-LMDeploy.
Questions fréquentes
Quelles versions de LMDeploy sont affectées ?
L’avis de GitHub liste toutes les versions antérieures à la version corrigée. Les chaînes de version spécifiques se trouvent dans l’avis et dans les trackers de sécurité GitLab et NIST. Les utilisateurs de LMDeploy en production devraient immédiatement mettre à jour vers la version actuelle et valider le chemin de chargement des images.
D’autres piles d’inférence sont-elles vulnérables de manière similaire ?
Toute pile d’inférence avec des capacités de vision ou multi-modales et une fonction de chargement d’images devrait être vérifiée pour les risques de SSRF. vLLM, Ray Serve et Text Generation Inference ont des schémas fonctionnels similaires. Un audit interne SSRF sur l’ensemble de la pile d’IA est approprié pour 2026.
Un pare-feu d’application web (WAF) est-il utile ?
De manière limitée. Les règles WAF contre les plages d’IP privées dans les corps HTTP interceptent une partie des attaques, mais sont souvent insuffisantes car les attaquants combinent les plages d’IP privées IPv6, le rebinding DNS et l’encodage des URL. Le WAF est un complément, pas un substitut à une segmentation réseau propre et à des processus de patch.
Quelle est la stratégie minimale de détection pour cette classe d’attaques ?
Trois signaux se sont avérés efficaces dans la pratique : des groupes cibles inhabituels dans les sorties (169.254.*, 10.*, 172.16-31.*, 192.168.*), des domaines de rappel (requestrepo.com, oast.pro, burpcollaborator.net), ainsi que des pics soudains de latence dans les journaux des serveurs de modèles dus aux appels HTTP effectués vers des destinations inconnues. Intégrer ces trois signaux dans un système SIEM ou d’observabilité est un sujet de sprint.
Comment cela se rapporte-t-il aux architectures Zero-Trust ?
Les architectures Zero-Trust adressent le cœur de cette attaque de manière propre : authentifier chaque connexion, autoriser chaque accès, ne jamais faire confiance au niveau du réseau. Ceux qui mettent en œuvre Zero-Trust de manière cohérente ont désamorcé structurellement l’exploit LMDeploy, car le serveur d’inférence n’aurait pas de droits implicites sur les backends stateful même en cas de SSRF.
Devons-nous ajuster nos contrats avec les fournisseurs de piles d’inférence ?
Pour de nombreuses entreprises, oui. Le temps de 12,5 heures entre l’avis et l’exploit signifie que les SLAs des fournisseurs avec des délais de patch de 30 jours ou plus ne sont pas acceptables. Une renégociation pour des patches en 72 heures pour les vulnérabilités critiques dans les composants de la pile d’IA est appropriée pour 2026. Ne pas ajuster cela comporte un risque structurel en production.
Réseau : Lire la suite dans cloudmagazin
- Classification architecturale du protocole A2A 1.2 et intégration du service mesh
- Vue multi-cloud sur les services de courtage cloud et rapport FinOps du 21.04.2026
- Contexte sur la poussée Commvault-Clumio vers Cloud Next 2026
Source de l’image de titre : Pexels / Christina Morillo (px:1181263)
