| Nom du plugin | Outil de syndication de contenu |
|---|---|
| Type de vulnérabilité | SSRF |
| Numéro CVE | CVE-2026-3478 |
| Urgence | Moyen |
| Date de publication du CVE | 2026-03-23 |
| URL source | CVE-2026-3478 |
Contournement de requête côté serveur (SSRF) dans l'outil de syndication de contenu (<= 1.3)
CVE : CVE-2026-3478
Gravité: Moyen (CVSS 7.2)
Versions concernées : Plugin Outil de syndication de contenu ≤ 1.3
Signalé : 23 mars 2026
Privilège requis : Non authentifié
En tant que professionnels de la sécurité WordPress, nous suivons les problèmes nouvellement divulgués afin que les administrateurs puissent prendre des mesures immédiates et efficaces. Le plugin Outil de syndication de contenu (≤ 1.3) contient une vulnérabilité de contournement de requête côté serveur (SSRF) non authentifiée via un paramètre URL. Ce type de faille permet à un attaquant non authentifié de forcer votre site à effectuer des requêtes HTTP vers des destinations arbitraires — exposant potentiellement des services internes, des points de terminaison de métadonnées ou d'autres ressources protégées.
Cet article explique la vulnérabilité dans un langage clair et actionnable, décrit des atténuations immédiates et à long terme, et montre comment WP‑Firewall aide à protéger votre site pendant que vous appliquez un correctif permanent ou supprimez le plugin vulnérable.
Table des matières
- Qu'est-ce que la SSRF et pourquoi cela compte pour WordPress
- Résumé du problème de l'outil de syndication de contenu (CVE-2026-3478)
- Comment un attaquant peut abuser de cette vulnérabilité (scénarios d'attaque)
- Impact et risque réalistes pour votre site et votre infrastructure
- Détection : signes qu'une personne pourrait exploiter le SSRF
- Étapes d'atténuation immédiates (ordre recommandé)
- Renforcement et règles WAF (exemples pratiques)
- Actions post-incident et surveillance
- Foire aux questions
- Plan de protection WP‑Firewall (informations sur le niveau gratuit et inscription)
- Recommandations finales
Qu'est-ce que la SSRF et pourquoi cela compte pour WordPress
Le contournement de requête côté serveur (SSRF) est une classe de vulnérabilité où un attaquant trompe un serveur pour qu'il effectue des requêtes HTTP/HTTPS en son nom. Comme ces requêtes proviennent du serveur, elles peuvent atteindre des services internes uniquement (comme des API de métadonnées, des interfaces d'administration sur des réseaux locaux ou d'autres microservices internes) auxquels un attaquant externe ne peut normalement pas accéder.
Dans les contextes WordPress, le SSRF est particulièrement important pour trois raisons :
- Les sites WordPress fonctionnent souvent sur une infrastructure qui expose des services internes (points de terminaison de métadonnées dans de nombreux fournisseurs de cloud, ports d'administration internes, bases de données locales, etc.). Si un plugin accepte des URL arbitraires et les demande sans validation appropriée, le serveur peut agir comme un proxy non intentionnel vers des ressources privées.
- De nombreux plugins mettent en œuvre des fonctionnalités de récupération, d'importation ou de syndication qui prennent des URL fournies par l'utilisateur. Si cette entrée n'est pas validée ou restreinte, elle devient un vecteur pour le SSRF.
- Le SSRF peut être enchaîné avec d'autres vulnérabilités. Par exemple, un attaquant pourrait utiliser le SSRF pour accéder à un panneau d'administration interne ou à un service de métadonnées cloud, puis exploiter des identifiants divulgués pour escalader l'accès.
Comme la vulnérabilité de l'outil de syndication de contenu est exploitable sans authentification (non authentifiée), la portée est plus large et peut être utilisée dans des campagnes de masse automatisées.
Résumé du problème de l'outil de syndication de contenu (CVE-2026-3478)
- Type de vulnérabilité : Contournement de requête côté serveur (SSRF) via un paramètre URL.
- Plugin affecté : Content Syndication Toolkit
- Versions affectées : ≤ 1.3
- Authentification : Non requise — des attaquants non authentifiés peuvent déclencher le comportement.
- CVSS : 7.2 (réflecte l'impact réseau, l'exploitabilité et le potentiel d'impact en chaîne)
- Patch : Aucun patch officiel publié au moment de la divulgation. Cela augmente l'urgence de l'atténuation.
En résumé : un paramètre (généralement nommé “ url ” ou similaire) est utilisé par le plugin pour récupérer du contenu distant sans validation appropriée ou sans liste blanche de domaine et sans protections contre les requêtes vers des plages d'IP internes. Les attaquants peuvent fournir des hôtes qui se résolvent en adresses IP internes ou en points de terminaison de métadonnées cloud, amenant le serveur à récupérer du contenu et potentiellement à renvoyer des informations sensibles à l'attaquant.
Comment un attaquant peut abuser de cette vulnérabilité (scénarios d'attaque)
Voici des cas d'abus réalistes qu'un attaquant pourrait tenter.
- Reconnaissance des services internes
L'attaquant fournit une IP privée ou un nom d'hôte (par exemple, 169.254.169.254 pour les métadonnées cloud, 127.0.0.1:8080 pour les API d'administration locales, ou 10.0.0.5:2375 pour une API Docker non sécurisée) dans le paramètre vulnérable. Le serveur effectue la requête et renvoie des données qui révèlent des services internes. - Exfiltration de métadonnées cloud
De nombreux fournisseurs de cloud exposent des API de métadonnées accessibles uniquement depuis l'instance. Si le plugin interroge une URL fournie par un attaquant, il peut récupérer des clés API, des identifiants IAM ou d'autres métadonnées sensibles. - Analyse de ports et pivot
Les attaquants utilisent le SSRF comme pivot pour analyser les ports internes, déterminer quels services écoutent, puis tenter de les exploiter. - Abus en tant que proxy anonymisant
Des acteurs malveillants peuvent utiliser le point de terminaison vulnérable pour faire office de proxy pour des requêtes (par exemple, envoyer des requêtes à d'autres cibles en utilisant l'IP de votre site comme origine), compliquant l'attribution et permettant d'autres attaques. - Attaques localhost/loopback
De nombreuses plateformes ont des interfaces d'administration liées à localhost. Le SSRF peut y accéder et provoquer des actions privilégiées si l'authentification est faible ou absente.
Étant donné que le plugin est vulnérable dans les versions ≤ 1.3 et que les attaquants n'ont besoin d'aucune identification, ces scénarios peuvent être automatisés et utilisés dans de larges balayages.
Impact et risque réalistes pour votre site et votre infrastructure
Les dommages exacts dépendent de votre environnement d'hébergement et des services exécutés près de votre instance WordPress. Les impacts typiques incluent :
- Exposition des identifiants ou des métadonnées cloud qui permettent un compromis de compte.
- Accès aux tableaux de bord internes, bases de données, API de gestion ou autres services sensibles.
- Mouvement latéral au sein d'un environnement (si l'hôte WordPress partage un réseau avec d'autres services).
- Abus de votre site en tant que proxy pour obscurcir d'autres trafics malveillants.
- Dommages à la réputation et responsabilités potentielles en cas de violation de données.
Même si le site lui-même n'héberge pas de données critiques, SSRF peut fournir aux attaquants une passerelle vers votre environnement d'infrastructure plus large. Prenez les rapports SSRF au sérieux et agissez rapidement.
Détection : signes qu'une personne pourrait exploiter le SSRF
Surveillez les indicateurs suivants dans vos journaux et votre télémétrie :
- Requêtes HTTP(S) sortantes inattendues du serveur web vers des plages d'IP privées : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, et lien-local 169.254.0.0/16.
- Requêtes aux adresses de métadonnées des fournisseurs de cloud (par exemple 169.254.169.254) ou aux noms d'hôtes de services internes qui ne devraient pas être contactés.
- Nombre élevé de requêtes à un seul point de terminaison WordPress avec des paramètres “url” variés ou d'autres entrées similaires à des URL.
- En-têtes HTTP inhabituels dans les réponses ou réponses 200 contenant du contenu provenant de points de terminaison internes.
- Erreurs élevées ou réponses inattendues dans les journaux de plugins indiquant des tentatives de récupération échouées vers des ressources internes.
- Augmentation des connexions sortantes sur des ports peu courants (par exemple, 2375 pour Docker, 5985/5986 pour WinRM).
Surveillez les journaux d'accès du serveur web et tous les journaux de sortie fournis par votre hébergeur. Si vous avez un pare-feu d'application web (WAF) avec journalisation des requêtes sortantes, activez-le.
Étapes d'atténuation immédiates (ordre recommandé)
Lorsqu'une vulnérabilité comme CVE‑2026‑3478 est divulguée et qu'aucun correctif officiel n'est disponible, prenez des mesures d'atténuation en couches. Utilisez les étapes prioritaires suivantes.
- Mettez le site dans une posture protégée (rapide)
- Si possible, désactivez temporairement ou supprimez le plugin Content Syndication Toolkit jusqu'à ce qu'un correctif sûr soit publié et validé.
- Si la désactivation n'est pas immédiatement possible (raisons commerciales), appliquez les atténuations WAF décrites ci-dessous.
- Bloquez ou assainissez le point de terminaison vulnérable dans le routage de l'application (rapide et efficace)
- Identifiez les points de terminaison du plugin qui acceptent le paramètre URL. Mettez en œuvre des règles au niveau du serveur pour retourner 403 pour les requêtes incluant le paramètre jusqu'à ce que le plugin soit corrigé.
- Appliquez des restrictions sur les requêtes sortantes (hôte/réseau)
- Ajoutez des règles de sortie pour empêcher le serveur web d'accéder aux plages IP internes et aux points de terminaison de métadonnées cloud.
- La plupart des fournisseurs de cloud et des plateformes d'hébergement vous permettent de restreindre l'accès réseau sortant via des groupes de sécurité, des règles de pare-feu ou des iptables au niveau de l'hôte. Bloquez l'accès à :
- 127.0.0.0/8
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
- 169.254.0.0/16
- Appliquez des règles WAF pour bloquer les tentatives d'exploitation.
- Utilisez un WAF pour identifier et bloquer les demandes où les paramètres d'URL pointent vers des IP internes, des adresses de boucle locale ou des noms d'hôtes interdits. Consultez la section “ Renforcement et règles WAF ” pour des modèles et une logique concrets.
- Restreignez la fonctionnalité des plugins via la configuration (si disponible).
- Si le plugin propose des paramètres pour restreindre les flux/sources à une liste blanche de domaines, activez cela. Sinon, envisagez d'ajouter du code personnalisé dans mu-plugins pour valider l'URL avant que le plugin n'effectue la récupération.
- Surveillez et collectez des données d'analyse.
- Activez la journalisation détaillée des demandes entrantes contenant des paramètres ressemblant à des URL, et journalisez les demandes sortantes correspondantes. Conservez les journaux pour une analyse et un reporting ultérieurs.
- Informez les parties prenantes et planifiez une remédiation
- Si vous détectez une exploitation, suivez votre plan de réponse aux incidents. Informez le fournisseur d'hébergement, les opérations internes et éventuellement les équipes juridiques/de conformité en fonction de l'exposition des données.
Renforcement et règles WAF (exemples pratiques)
Ci-dessous se trouvent des modèles et des règles robustes et pratiques que vous pouvez appliquer dans un WAF ou sur le serveur web pour prévenir les abus courants de SSRF. Ceux-ci sont écrits de manière conceptuelle et peuvent être mis en œuvre en tant que règles ModSecurity, règles Nginx ou dans votre produit WAF géré.
Important: Testez toute règle dans un environnement de staging avant de l'appliquer en production pour éviter les faux positifs.
A. Bloquez les demandes où l'URL fournie par l'utilisateur résout des adresses internes ou de boucle locale.
- Stratégie : Analysez la valeur du paramètre URL et bloquez si elle contient des IP privées ou des chaînes ressemblant à localhost.
Exemple de logique de pseudo-règle :
- Si la demande contient le nom de paramètre “ url ” (ou d'autres noms de paramètres connus utilisés par le plugin) ET que la valeur du paramètre inclut :
- Des noms d'hôtes comme “ localhost ”, “ 127.0.0.1 ”, “ 0.0.0.0 ”.”
- Des adresses IP dans des plages privées (10., 172.16-31., 192.168., 169.254.).
- Boucle locale IPv6 (::1) ou plages locales de lien (fe80::/10).
- Action de blocage : retourner HTTP 403.
B. Bloquez les tentatives de demande vers des points de terminaison de métadonnées cloud.
- Les IP de métadonnées cloud sont des cibles SSRF courantes. Bloquez toute valeur de paramètre contenant :
- 169.254.169.254
- metadata.google.internal
- 100.100.100.200 (illustratif — vérifiez la documentation de votre fournisseur de cloud)
- Retourner 403 et enregistrer les détails pour l'analyse judiciaire.
C. Bloquer les paramètres d'URL contenant des adresses internes encodées
Les attaquants peuvent fournir des hôtes encodés comme %31%32%37%2E%30%2E%30%2E%31 (127.0.0.1). Normaliser et décoder la valeur du paramètre avant de vérifier.
D. Refuser les demandes qui fournissent une adresse IP au lieu d'un domaine (optionnel mais efficace)
Si la logique commerciale le permet, rejeter les paramètres d'URL qui sont des adresses IP directes (par exemple, http://192.168.1.2/path). Exiger des noms de domaine et les ajouter à la liste blanche si possible.
E. Approche de liste autorisée (recommandée pour les installations sensibles)
Maintenir une liste blanche des noms d'hôtes approuvés que le plugin est autorisé à récupérer (par exemple, des domaines de partenaires vérifiés). Bloquer tout le reste par défaut.
F. Limitation et quotas
Limiter le nombre de requêtes de récupération que le plugin peut déclencher par minute par IP pour réduire l'efficacité des tentatives de scan automatisé.
G. Exemple de règle similaire à ModSecurity (conceptuel)
Remarque : adaptez à votre type de WAF ; ci-dessous est intentionnellement de niveau supérieur et évite la syntaxe spécifique à la plateforme.
- Règle : Si ARGS:url décodé contient une regex pour des plages IP privées OU contient “localhost” OU contient “169.254.169.254” ALORS BLOQUER et ENREGISTRER.
H. Protéger le réseau sortant au niveau de l'hôte
Si vous pouvez appliquer une sortie sortante, bloquer l'utilisateur/processus du serveur web d'initier des connexions vers des plages privées sauf pour les services explicitement nécessaires.
Actions post-incident et surveillance
Si vous soupçonnez une exploitation, suivez cette liste de contrôle :
- Préserver les journaux immédiatement
Enregistrer les journaux d'accès du serveur web, les journaux du plugin, les journaux du WAF et tous les journaux de connexion sortante. - Identifier les données ou services compromis
Recherchez des demandes qui ont renvoyé du contenu pointant vers des métadonnées ou des pages d'administration internes. - Faites tourner les secrets s'ils sont exposés.
Si des points de terminaison de métadonnées ou des API internes ont été interrogés et que des fuites de credentials sont suspectées, faites tourner les credentials, les clés API et les clés de fournisseur de cloud immédiatement. - Reconstruisez les hôtes compromis.
Si vous trouvez des preuves de compromission (téléchargements de webshell, processus suspects, tâches planifiées inconnues), reconstruisez l'instance à partir d'images de confiance. - Examiner les comptes utilisateurs et les rôles
Vérifiez les comptes administratifs WordPress, les utilisateurs récemment ajoutés et l'intégrité de l'installation (détection de changement de fichier). - Signalez et coordonnez
Si l'exposition affecte les clients ou des tiers, suivez les règles de notification requises par les lois locales et vos politiques. - Plan de remédiation permanent
Supprimez ou corrigez le plugin vulnérable. Si l'auteur du plugin ne fournit pas de correctif en temps utile, remplacez le plugin par une alternative sécurisée ou mettez en œuvre une intégration personnalisée plus restrictive.
Exemple pratique : flux d'atténuation sûr pour un administrateur.
- Identifiez si votre site utilise le Content Syndication Toolkit et sa version.
Tableau de bord WordPress → Plugins → localisez le plugin et notez la version. - Si la version ≤ 1.3, désactivez immédiatement le plugin si la fonctionnalité de syndication n'est pas critique.
- Si la désactivation n'est pas possible :
- Ajoutez une règle WAF pour bloquer les demandes contenant le paramètre d'URL du plugin.
- Ajoutez des règles de sortie au niveau de l'hôte restreignant l'accès sortant aux plages privées et link-local.
- Surveillez les journaux pour les tentatives SSRF bloquées et enquêtez sur toute demande sortante précédemment réussie vers des points de terminaison sensibles.
- Prévoyez de supprimer ou de remplacer le plugin après avoir coordonné avec les propriétaires du site.
Foire aux questions
Q : Puis-je corriger le plugin moi-même ?
R : Seulement si vous avez une expertise en développement et comprenez les chemins de code du plugin. Un correctif sûr garantit généralement :
- Validation des entrées (n'autoriser que des noms d'hôtes sûrs),
- Liste blanche de domaine ou liste noire explicite des plages IP privées,
- Vérifications appropriées de la résolution DNS (bloquer lorsque l'IP résolue est privée),
- Délais d'attente et limites de taille de réponse pour les récupérations externes.
Si vous n'êtes pas à l'aise pour modifier le code du plugin, bloquez la fonctionnalité avec des règles WAF et contactez un développeur qualifié.
Q : Qu'en est-il du contenu mis en cache ou des couches CDN ?
R : Les CDN et les caches peuvent masquer les indicateurs SSRF car les récupérations d'origine se produisent sur votre serveur. Appliquez des restrictions de sortie côté serveur et des protections WAF à l'origine et à la périphérie. Assurez-vous que les caches sont invalidés de manière appropriée après remédiation.
Q : Est-il suffisant de compter sur les mises à jour des plugins ?
R : Les mises à jour sont la meilleure solution à long terme, mais lorsqu'aucun correctif n'est disponible, vous devez combiner des atténuations immédiates (désactiver le plugin / règles WAF / restrictions de sortie de l'hôte) avec une surveillance jusqu'à ce qu'un correctif du fournisseur soit émis et vérifié.
Pourquoi un pare-feu d'application Web est essentiel en ce moment
Un WAF géré fournit une protection rapide et centralisée contre les vulnérabilités comme le SSRF :
- Il peut déployer rapidement des règles ciblées pour un paramètre vulnérable connu sans changer le code du site.
- Il peut bloquer les tentatives d'exploitation au niveau du réseau, y compris les entrées codées et les requêtes obscurcies.
- Il enregistre les tentatives pour une analyse judiciaire et des alertes.
- Avec la capacité de patching virtuel, les WAF vous donnent du temps pour tester les correctifs des fournisseurs avant de les appliquer en production.
WP‑Firewall a développé des ensembles de règles d'atténuation spécifiquement pour détecter et bloquer les vecteurs SSRF qui exploitent les entrées de plugins de type URL, y compris des protections contre les charges utiles codées/obscurcies et des vérifications des modèles d'accès aux métadonnées cloud. Cela réduit l'exposition pendant que vous appliquez des corrections permanentes.
WP‑Firewall : protections gérées pendant que vous remédiez
Titre: Protégez votre site maintenant avec la protection gérée gratuite de WP‑Firewall
Si vous avez besoin d'une protection immédiate pendant que vous mettez à jour ou supprimez le plugin vulnérable, le plan de base (gratuit) de WP‑Firewall inclut une couverture de pare-feu géré, des règles WAF, une analyse de logiciels malveillants et une atténuation des risques OWASP Top 10. Notre plan gratuit vous offre une base de protection rapide afin que vous puissiez mettre en œuvre les étapes d'atténuation ci-dessus sans interrompre les services critiques pour l'entreprise.
- Basique (gratuit) : Protection essentielle — pare-feu géré, bande passante illimitée, WAF, scanner de logiciels malveillants et atténuation des risques OWASP Top 10.
- Standard ($50/an) : Tout dans Basic plus suppression automatique de malware et la possibilité de mettre sur liste noire/blanche jusqu'à 20 IP.
- Pro ($299/an) : Tout dans le Standard plus des rapports de sécurité mensuels, un patching virtuel automatique des vulnérabilités et un accès à des modules complémentaires premium comme un Responsable de Compte Dédié, l'Optimisation de la Sécurité, le Jeton de Support WP, le Service WP Géré et le Service de Sécurité Géré.
Inscrivez-vous pour un plan WP‑Firewall Basic gratuit ici : https://my.wp-firewall.com/buy/wp-firewall-free-plan/ — obtenez une protection gérée instantanée pendant que vous corrigez, supprimez ou remplacez le plugin vulnérable.
Liste de contrôle de mise en œuvre (référence rapide)
Immédiat (dans 1 à 2 heures)
- [ ] Identifier la version du plugin ; désactiver si ≤ 1.3 et non critique.
- [ ] Ajouter une règle WAF bloquant les requêtes avec le paramètre vulnérable pointant vers des IP privées ou des adresses de métadonnées.
- [ ] Bloquer l'accès sortant aux plages d'IP privées et link-local au niveau de l'hôte/réseau.
- [ ] Activer la journalisation détaillée pour les requêtes suspectes contenant des paramètres ressemblant à des URL.
À court terme (même jour)
- [ ] Appliquer une liste blanche pour les sources externes si possible.
- [ ] Limiter les requêtes vers les points de terminaison du plugin.
- [ ] Scanner le site à la recherche de signes de compromission (vérifications de l'intégrité des fichiers, scanners de malware).
Moyen terme (jours)
- [ ] Remplacer ou supprimer le plugin si aucun correctif du fournisseur n'est disponible rapidement.
- [ ] Si vous devez garder le plugin, mettre en œuvre des validations au niveau de l'application : liste blanche de domaine, résolution DNS et vérifications d'IP.
- [ ] Faire tourner les identifiants qui ont pu être exposés.
Long terme (semaines à mois)
- [ ] Renforcer l'environnement d'hébergement : privilèges sortants minimaux, segmentation du réseau, moindre privilège.
- [ ] Adopter un WAF géré avec patching virtuel et reporting de sécurité mensuel (si ce n'est pas déjà en place).
- [ ] Établir un processus de gestion des vulnérabilités pour les plugins et thèmes tiers.
Exemples de requêtes de détection et recherches de journaux
Utilisez ces requêtes comme points de départ pour votre analyse de journaux (ajustez la syntaxe pour votre pile de journalisation).
- Recherchez des demandes contenant le paramètre vulnérable (exemple pour les journaux d'accès) :
grep -i "url=" /var/log/nginx/access.log | grep -E "127\.0\.0\.1|169\.254|10\.|192\.168|172\.(1[6-9]|2[0-9]|3[0-1])" - Recherchez des connexions sortantes du serveur web vers des réseaux privés (journaux de pare-feu ou de proxy hôte)
Vérifiez /var/log/messages, les journaux de proxy sortants ou les journaux de flux VPC du fournisseur de cloud pour l'IP source = l'IP de votre serveur web et la destination dans les plages privées. - Journaux WAF
Recherchez des demandes bloquées qui ont déclenché des règles liées à SSRF, en particulier celles avec des séquences encodées ou des tentatives répétées avec différentes adresses cibles.
Remarques de clôture de l'équipe de sécurité de WP‑Firewall
Cette divulgation renforce un thème commun : les plugins qui récupèrent du contenu externe doivent appliquer une validation stricte des entrées et des contraintes sur les demandes sortantes. Lorsqu'un correctif du fournisseur n'est pas encore disponible, la meilleure approche est la défense en couches : désactiver le code vulnérable, appliquer des restrictions de sortie réseau et déployer des règles WAF qui ciblent le vecteur d'exploitation exact.
Si vous gérez un ou plusieurs sites WordPress, prenez cette vulnérabilité au sérieux — le SSRF non authentifié peut être utilisé dans des campagnes de scan automatisées et peut exposer des métadonnées critiques dans des environnements cloud.
Si vous avez besoin d'aide pour déployer rapidement des atténuations, les protections gérées de WP‑Firewall peuvent être activées immédiatement pour réduire les risques pendant que vous remédiez. Notre plan gratuit de base inclut une couverture WAF essentielle et un scan afin que vous puissiez prendre le temps d'appliquer un correctif permanent sûr et testé.
Restez proactif et gardez les plugins minimaux et à jour. Si un plugin n'est plus maintenu ou présente des vulnérabilités répétées, envisagez de le remplacer par une alternative bien maintenue et soucieuse de la sécurité ou d'implémenter un code personnalisé qui suit des modèles de validation stricts.
Si vous avez besoin d'aide avec des règles d'atténuation, la réponse aux incidents ou le renforcement des vulnérabilités, notre équipe de WP‑Firewall peut vous assister — des correctifs virtuels temporaires à la remédiation et à la récupération gérées complètes.
Annexe : Ressources et références
- CVE : CVE-2026-3478 (référencé par la divulgation de vulnérabilité)
- Renforcement général de SSRF : Liste blanche de domaines, vérifications de résolution DNS, contrôles de sortie au niveau de l'hôte, correction virtuelle WAF
- Docs du fournisseur de cloud : Consultez les conseils sur le service de métadonnées de votre fournisseur de cloud et faites tourner les identifiants si l'accès aux métadonnées est suspecté.
(Fin de l'article)
