LMDeploye sous la menace SSRF exploitée en heures expose les recours internes

Moins de 13 heures après être devenue publique, une vulnérabilité élevée à LMDeploy - la boîte à outils open source pour compresser, déployer et servir des modèles de langage et de vision - était déjà exploitée dans des environnements réels. L'échec, enregistré comme CVE-2026-33626 Avec le score CVSS 7.5, est une variante de Server-Side Request Forgery (SSRF) dans le module de langage vision : une fonction qui télécharge des images à partir d'URL non valides si ces adresses appartiennent à des réseaux internes ou des services de métadonnées cloud, ouvrant la porte à un accès non autorisé à des ressources sensibles.

Le vecteur est simple et dangereux : le chargeur d'images accepte les URLs arbitraires. Un attaquant de contrôle d'entrée peut forcer le serveur à demander des ressources internes telles que le service de métadonnées d'instance AWS (IMDS), des bases de données locales, des interfaces administratives en boucle ou des paramètres internes qui ne sont normalement pas accessibles depuis Internet. Dans le cas signalé, les attaquants ont combiné le balayage interne du port et l'exfiltration par DNS OOB pour confirmer et exploiter la capacité SSRF comme "HTTP primitive".

Le fait que l'exploitation ait eu lieu en quelques heures n'est pas une coïncidence. Dans la pratique, les divulgations techniques qui incluent le fragment de code vulnérable, le nom du paramètre et des exemples fonctionnels agissent comme des instructions précises pour les acteurs malveillants - et aujourd'hui aussi comme des incitations pour les modèles commerciaux - accélérant la traduction d'un problème détecté à une explosion opérationnelle. Cela montre une dynamique inquiétante dans l'écosystème des infrastructures de l'IA: un temps de réponse extrêmement court entre la publication et l'attaque.

Les conséquences potentielles sont importantes et multiples. Le nuage identifie le vol par IMDS, la reconnaissance et le mouvement latéral vers les services internes, l'engagement de bases de données ou de files d'attente, et la possibilité de persister si le serveur concerné a étendu les autorisations sont des scénarios plausibles. Pour les environnements industriels ou les contrôleurs exposés et les PLC, la combinaison de tests massifs et de scans sélectifs est une recette pour les interruptions et les manipulations.

Du point de vue opérationnel, la première priorité immédiate devrait être de contenir l'exposition. Si votre organisation utilise LMDeploy avec un support en langage visuel, appliquez la correction officielle si elle est déjà disponible ou désactivez temporairement les fonctions de chargement d'image à distance. À titre de mesure de confinement supplémentaire, bloquer ou restreindre le trafic sortant des serveurs d'inférence, mettre en œuvre des règles d'évacuation qui n'autorisent que les domaines et les gammes explicitement nécessaires et s'assurer qu'il n'y a pas d'accès direct à 169.254.169.254 (IMDS) ou aux interfaces loopback des processus qui acceptent les URL des clients.

Il y a une atténuation spécifique dans le nuage qui réduit l'impact de ce type de SSRF. Pour les instances AWS, activez IMDSv2 et définissez la limite de saut ou désactivez l'accès aux métadonnées lorsqu'il n'est pas nécessaire de limiter la capacité d'un attaquant à voler des identifiants. Il est également recommandé d'appliquer une stricte segmentation du réseau, d'appliquer des listes blanches de domaines pour les fets sortants et d'utiliser des proxies inverses ou validateurs qui vérifient toutes / les listes noires des IP et des gammes RFC1918 avant d'autoriser une application externe. En termes généraux, la validation et la normalisation des entrées d'URL est obligatoire; éviter cette validation était la racine de l'incident.

Dans la détection et la réponse, recherchez des indicateurs clairs: les demandes du serveur environ 169.254.169.254, connexions loopback 127.0.0.1 à partir de processus qui ne les exécutent pas normalement, chaînes de consultation contenant des URL fournies par des tiers, et consultations DNS atypiques aux domaines OOB (hors bande). Vérifiez le service de modèles pour les modèles de demande qui changent entre les différents modèles ou montrent les tentatives de scanner des ports internes. Si vous soupçonnez un engagement, isolez l'instance, recueillez des preuves et faites pivoter les références exposées.

Cet incident devrait rappeler que la sécurité dans l'infrastructure modèle n'est pas seulement un durcissement traditionnel : il s'agit d'examiner comment les fonctions conçues pour la flexibilité (comme le chargement d'une image à distance) peuvent devenir des vecteurs d'accès au réseau interne. Les gestionnaires de produits et l'équipement de sécurité devraient intégrer des examens de conception axés sur l'exposition au réseau, des tests SSRF et des contrôles de sortie par défaut dans tout composant qui traite des URL externes.

Pour approfondir les modèles de prévention et d'atténuation du SSRF, veuillez consulter le guide du PAOAO sur le sujet et la documentation du SSFE pour le service des métadonnées, qui décrivent les contrôles de production spécifiques : OWASP SSRF Feuille antichaleur et Documentation du Service des métadonnées d'instance du SSFE (IMDS). De plus, la publication même de la constatation et de la correction se trouve dans l'avis public du projet : Avis GitHub GHSA-6w67-hwm5-92mq.

En bref, les organisations qui déploient des modèles d'inférence et des passerelles doivent supposer que les exploits arriveront très rapidement après la divulgation et prépareront des correctifs et des mesures compensatoires et des capacités de détection. Mettre à jour, segmenter, surveiller et valider les entrées sont les piliers de la réduction des risques immédiats; une amélioration durable nécessite l'intégration de ces pratiques dans le cycle de développement et de déploiement de l'infrastructure de l'IV.