<\/p>\n
Squidex a rendu publique la faille SSRF CVE-2026-41172 le 22 avril 2026. CVSS 7.3, correctif dans la version 7.23.0. Un \u00e9diteur authentifi\u00e9 avec des droits de t\u00e9l\u00e9chargement d’actifs peut forcer le serveur Squidex \u00e0 r\u00e9cup\u00e9rer n’importe quelle URL interne et \u00e0 stocker la r\u00e9ponse comme un actif. Pour les \u00e9quipes de s\u00e9curit\u00e9, cela signifie : dans les 72 heures \u00e0 venir, trois \u00e9l\u00e9ments essentiels doivent \u00eatre en place. Le correctif seul ne suffit pas. Les faiblesses structurelles dans les configurations Egress et WAF restent ouvertes, si les \u00e9quipes d’exploitation ne les traitent pas maintenant.<\/strong><\/p>\n Une SSRF avec un score CVSS 7.3 semble g\u00e9rable dans le bulletin de correctif. Une mise \u00e0 jour rapide vers Squidex 7.23.0, coche dans la case, et on continue. C’est pr\u00e9cis\u00e9ment cette r\u00e9action qui constitue le risque en 2026. Les installations de headless-CMS ont fortement augment\u00e9 ces trois derni\u00e8res ann\u00e9es, se situant souvent au c\u0153ur de l’architecture et n’\u00e9tant pas r\u00e9pertori\u00e9es comme composante critique de la s\u00e9curit\u00e9 dans de nombreux inventaires d’actifs. Une vuln\u00e9rabilit\u00e9 SSRF dans une telle installation signifie qu’un \u00e9diteur authentifi\u00e9 avec des droits de t\u00e9l\u00e9chargement d’actifs obtient un acc\u00e8s aux points de terminaison internes et aux m\u00e9tadonn\u00e9es cloud. Sans liste d’autorisation Egress et sans profil WAF, le passage de la CVE au r\u00f4le cloud compromis est court.<\/p>\n Qu’est-ce que la SSRF ?<\/strong> La Server-Side Request Forgery (SSRF) est une vuln\u00e9rabilit\u00e9 qui pousse un serveur \u00e0 r\u00e9cup\u00e9rer des URLs au nom d’un attaquant. L’attaquant n’a pas besoin d’un acc\u00e8s direct aux r\u00e9seaux internes. Il utilise le serveur vuln\u00e9rable comme proxy. C’est pr\u00e9cis\u00e9ment ce levier qui est maintenant activ\u00e9 dans Squidex : le point de terminaison de t\u00e9l\u00e9chargement d’actifs r\u00e9cup\u00e8re l’URL sp\u00e9cifi\u00e9e, conserve la r\u00e9ponse et la restitue via l’interface d’actifs normale.<\/p>\n Les \u00e9quipes d’exploitation d\u00e9couvrent g\u00e9n\u00e9ralement la vuln\u00e9rabilit\u00e9 par deux canaux. Premi\u00e8rement, via des analyses de vuln\u00e9rabilit\u00e9s qui d\u00e9tectent CVE-2026-41172 dans les 24 heures suivant sa publication. Deuxi\u00e8mement, via les inventaires internes d’actifs, \u00e0 condition que Squidex y soit correctement r\u00e9pertori\u00e9. Les deux m\u00e9thodes indiquent la pr\u00e9sence de la vuln\u00e9rabilit\u00e9, mais peu sur l’exposition r\u00e9elle. La question int\u00e9ressante n’est pas si un serveur Squidex existe, mais ce qu’il peut accomplir lorsqu’il est compromis.<\/p>\n Qui sera de service le 23 avril 2026 devrait consid\u00e9rer les \u00e9tapes suivantes comme une s\u00e9quence, et non comme une liste de souhaits. Les premi\u00e8res 24 heures sont consacr\u00e9es \u00e0 l’inventaire et au correctif. Les secondes 24 heures sont d\u00e9di\u00e9es au durcissement de l’\u00e9gress ainsi qu’au verrouillage IMDS. Les derni\u00e8res 24 heures concernent le profil WAF et la r\u00e9vision des autorisations.<\/p>\n L’inventaire pendant les premi\u00e8res heures est plus simple qu’il n’y para\u00eet, si un inventaire d’actifs existe. Dans les environnements sans inventaire propre, un scan cibl\u00e9 sur les chemins Squidex typiques plus les ports par d\u00e9faut est utile. La r\u00e9ponse standard du point de terminaison d’actif fournit suffisamment de signaux pour une identification rapide. Ceux qui obtiennent Squidex via un fournisseur de plateforme doivent v\u00e9rifier les versions d\u00e9ploy\u00e9es.<\/p>\n Le correctif vers la version 7.23.0 est une proc\u00e9dure standard. Ceux qui, en raison de fen\u00eatres de gel, de comit\u00e9s de changements ou d’interfaces d\u00e9pendantes, ne peuvent pas appliquer le correctif pendant les 14 prochains jours doivent activer imm\u00e9diatement les mesures de durcissement. La liste d’autorisation egress est la mesure la plus importante. Squidex n’a besoin d’atteindre qu’un petit nombre d’h\u00f4tes externes, g\u00e9n\u00e9ralement des destinations CDN plus des sources d’actifs d\u00e9finies. Une r\u00e8gle egress qui bloque tout le reste \u00e9limine la majeure partie des variantes d’attaque SSRF contre les plages d’IP internes.<\/p>\n L’hypoth\u00e8se selon laquelle les applications dans les environnements de conteneurs ne font que ce qu’elles sont cens\u00e9es faire ne tiendra plus en 2026 \u00e0 aucune discussion sur les SSRF. Les configurations par d\u00e9faut dans Kubernetes permettent un egress illimit\u00e9. Les plateformes de conteneurs en dehors de Kubernetes se comportent de mani\u00e8re similaire. Un pod Squidex sans strat\u00e9gie r\u00e9seau peut atteindre chaque point de terminaison interne du m\u00eame cluster, peut interroger le point de terminaison des m\u00e9tadonn\u00e9es cloud ainsi que contacter des h\u00f4tes externes qui ne seraient jamais n\u00e9cessaires pour le cas d’usage r\u00e9el.<\/p>\n Une liste d’autorisation d’egress (Egress-Allowlist) pertinente couvre trois domaines. Premi\u00e8rement, les sources d’actifs externes que les \u00e9quipes \u00e9ditoriales utilisent r\u00e9ellement. Ce sont g\u00e9n\u00e9ralement des fournisseurs de photos de stock, des propres buckets CDN ainsi que occasionnellement des API partenaires. Deuxi\u00e8mement, les services internes dont Squidex a besoin pour l’identit\u00e9, la journalisation et le monitoring. Troisi\u00e8mement, des blocages explicites contre 169.254.169.254 (AWS IMDS), 169.254.170.2 (m\u00e9tadonn\u00e9es de t\u00e2che ECS), le point de terminaison des m\u00e9tadonn\u00e9es GCP ainsi que des adresses similaires chez Azure. Celui qui bloque compl\u00e8tement la plage 169.254.0.0\/16 au niveau du pod obtient le plus grand levier avec un effort minimal.<\/p>\n L’application d’IMDSv2 est la deuxi\u00e8me \u00e9tape pour les environnements AWS. Le param\u00e8tre de limite de sauts devrait \u00eatre positionn\u00e9 \u00e0 1. Ainsi, un pod compromis ne peut pas atteindre le point de terminaison des m\u00e9tadonn\u00e9es via le routage normal. Des m\u00e9canismes similaires existent dans Azure avec le service de m\u00e9tadonn\u00e9es d’instance qui exige une v\u00e9rification d’en-t\u00eate, ainsi que dans Google Cloud avec la fonction de masquage des m\u00e9tadonn\u00e9es. Celui qui travaille dans des environnements multi-cloud v\u00e9rifie la configuration pour chaque fournisseur cloud.<\/p>\n\n
Pourquoi cette vuln\u00e9rabilit\u00e9 SSRF ne doit pas dispara\u00eetre de la liste CVE<\/h2>\n
Le plan de 72 heures pour les \u00e9quipes d’exploitation<\/h2>\n
R\u00e8gles d’egress et profil WAF comme deuxi\u00e8me ligne de d\u00e9fense<\/h2>\n