<\/p>\n
Squidex hizo p\u00fablica el 22 de abril de 2026 la vulnerabilidad SSRF CVE-2026-41172. CVSS 7.3, parche en la versi\u00f3n 7.23.0. Un editor autenticado con permiso de carga de activos puede forzar al servidor Squidex a recuperar cualquier URL interna y guardar la respuesta como un activo. Para las operaciones de seguridad, esto significa: dentro de las pr\u00f3ximas 72 horas, tres componentes deben estar en su lugar. El parche solo cierra la vulnerabilidad. Las debilidades estructurales en las configuraciones de Egress y WAF permanecen abiertas, si los equipos de operaciones no las abordan ahora.<\/strong><\/p>\n Una vulnerabilidad SSRF con CVSS 7.3 parece manejable en el bolet\u00edn de parches. Una actualizaci\u00f3n r\u00e1pida a Squidex 7.23.0, marcada como completada, y el programa contin\u00faa. Exactamente esta reacci\u00f3n es el riesgo en 2026. Las instalaciones de Headless-CMS han aumentado significativamente en los \u00faltimos tres a\u00f1os, a menudo se encuentran en el centro de la arquitectura y en muchos inventarios de activos no se consideran componentes cr\u00edticos para la seguridad. Una vulnerabilidad SSRF en tal instalaci\u00f3n significa que un editor autenticado con permisos de carga de activos puede acceder a puntos de internos y metadatos en la nube. Sin una lista de permitidos de salida (Egress-Allowlist) y sin un perfil WAF, el salto desde la CVE hasta el rol de la nube comprometido es corto.<\/p>\n \u00bfQu\u00e9 es SSRF?<\/strong> Server-Side Request Forgery (Falsificaci\u00f3n de Solicitudes del Lado del Servidor) es una vulnerabilidad en la que un servidor es inducido a recuperar URLs en nombre de un atacante. El atacante no necesita acceso directo a redes internas. Utiliza el servidor vulnerable como proxy. Exactamente este mecanismo est\u00e1 ahora activo en Squidex: el punto de final de carga de activos recupera la URL especificada, persiste la respuesta y la devuelve a trav\u00e9s de la interfaz normal de activos.<\/p>\n Los equipos de operaciones suelen detectar la vulnerabilidad a trav\u00e9s de dos canales. En primer lugar, mediante an\u00e1lisis de vulnerabilidades que detectan CVE-2026-41172 dentro de las primeras 24 horas despu\u00e9s de su publicaci\u00f3n. En segundo lugar, a trav\u00e9s de inventarios internos de activos, siempre que Squidex est\u00e9 correctamente inventariado. Ambos m\u00e9todos indican la vulnerabilidad. Ambos dicen poco sobre la exposici\u00f3n real. La pregunta interesante no es si existe un servidor Squidex, sino qu\u00e9 puede lograr cuando es comprometido.<\/p>\n Quien est\u00e9 de turno el 23 de abril de 2026, deber\u00eda considerar los siguientes pasos como una secuencia, no como una lista de deseos. Las primeras 24 horas pertenecen al inventario m\u00e1s el parche. Las segundas 24 horas pertenecen al endurecimiento de Egress as\u00ed como al bloqueo de IMDS. Las \u00faltimas 24 horas pertenecen al perfil WAF as\u00ed como a la revisi\u00f3n de permisos.<\/p>\n El inventario en las primeras horas es m\u00e1s trivial de lo que parece si existe un inventario de activos. En entornos sin un inventario limpio, vale la pena realizar un escaneo dirigido a rutas t\u00edpicas de Squidex m\u00e1s los puertos por defecto. La respuesta est\u00e1ndar del punto final de activos proporciona suficiente se\u00f1al para una identificaci\u00f3n r\u00e1pida. Quien obtenga Squidex gestionado a trav\u00e9s de un proveedor de plataforma, verificar\u00e1 all\u00ed las versiones desplegadas.<\/p>\n El parche a la versi\u00f3n 7.23.0 es el procedimiento est\u00e1ndar. Quien debido a ventanas de congelamiento, comit\u00e9s de cambios o frontends dependientes no pueda parchear en los pr\u00f3ximos 14 d\u00edas, activa inmediatamente las medidas de endurecimiento. La lista de permitidos de Egress es la medida m\u00e1s importante. Squidex solo necesita alcanzar una peque\u00f1a cantidad de hosts externos, t\u00edpicamente objetivos de CDN m\u00e1s fuentes de activos definidas. Una regla de Egress que bloquee todo lo dem\u00e1s elimina la mayor parte de las variantes de ataque SSRF contra rangos de IP internas.<\/p>\n La suposici\u00f3n de que las aplicaciones en entornos de contenedores hacen solo lo que se supone que deben hacer ya no resistir\u00e1 ninguna discusi\u00f3n sobre SSRF en 2026. Las configuraciones predeterminadas en Kubernetes permiten un Egress ilimitado. Las plataformas de contenedores fuera de Kubernetes se comportan de manera similar. Un Pod de Squidex sin Network Policy puede alcanzar cualquier punto final interno en el mismo cl\u00faster, puede consultar el punto final de metadatos de la nube y contactar hosts externos que nunca ser\u00edan necesarios para el caso de uso real.<\/p>\n Una lista de permitidos de Egress sensata cubre tres \u00e1reas. En primer lugar, las fuentes externas de activos que los equipos editoriales realmente utilizan. Estos suelen ser proveedores de fotos de archivo, propios buckets de CDN y ocasionalmente APIs de socios. En segundo lugar, los servicios internos que Squidex necesita para Identity, Logging y Monitoring. En tercer lugar, bloqueos expl\u00edcitos contra 169.254.169.254 (AWS IMDS), 169.254.170.2 (metadatos de tareas ECS), el punto final de metadatos de GCP y direcciones comparables en Azure. Quien bloquee completamente el rango 169.254.0.0\/16 a nivel de Pod, ha cubierto el mayor palanca con un m\u00ednimo de esfuerzo.<\/p>\n Forzar IMDSv2 es el segundo paso para entornos de AWS. El par\u00e1metro Hop-Limit deber\u00eda estar en 1. As\u00ed, un Pod comprometido no puede alcanzar el punto final de metadatos a trav\u00e9s del enrutamiento normal. Mecanismos comparables existen en Azure con el Instance Metadata Service, que requiere una verificaci\u00f3n de encabezados, y en Google Cloud con la funci\u00f3n Metadata-Concealment. Quien trabaje en entornos Multi-Cloud, verifica la configuraci\u00f3n por proveedor de nube.<\/p>\n\n
Por qu\u00e9 esta vulnerabilidad SSRF no debe desaparecer de la lista CVE<\/h2>\n
El plan de 72 horas para equipos de operaciones<\/h2>\n
Reglas de Egress y perfil WAF como segunda l\u00ednea de defensa<\/h2>\n