Istio corrige un bypass de autorización en HTTP/2 y una caída de istiod

El boletín ISTIO-SECURITY-2026-007, publicado el 15 de octubre, reúne fallos de Envoy y dos correcciones propias de Istio: una regla de autorización que podía eludirse con métodos HTTP escritos con otra capitalización y una caída de istiod bajo una condición concreta del modo ambient. No describe una única vulnerabilidad ni afecta por igual a cada instalación.

Las ramas afectadas son Istio 1.31.0–1.31.1, 1.30.0–1.30.5 y 1.29.0–1.29.8. Las correcciones están en 1.31.2, 1.30.6 y 1.29.9. Esta última es la versión final de la rama 1.29, cuyo soporte terminó el mismo 15 de octubre; quedarse en ella deja de ser una opción con parches futuros.

-InfraCrew dice: el boletín trae cuatro motivos para mirar el inventario; el número de versión sigue siendo el primer filtro, no el último.-

El bypass depende de la regla y del protocolo

El problema de AuthorizationPolicy está en reglas DENY que usan methods o reglas ALLOW que usan notMethods. Istio compilaba esas condiciones como una comparación sensible a mayúsculas del campo :method; por HTTP/2, una petición con post podía no coincidir con una regla escrita para POST y continuar hasta la aplicación. No es un bypass de todas las políticas: las reglas ALLOW con una lista explícita de métodos no están afectadas.

HTTP/1.1 queda fuera de este caso, porque su códec rechaza métodos que no estén en mayúsculas antes de que se evalúe la autorización. El escenario exige una carga afectada, una de esas dos formas de política y un cliente que alcance el servicio mediante HTTP/2. Istio asigna CVSS 7,4 al bypass; la puntuación no sustituye esa comprobación de configuración ni demuestra que una instancia concreta haya recibido solicitudes manipuladas.

-InfraCrew dice: una política puede ser correcta en YAML y no ser la política que ve el protocolo de la petición.-

Una colisión puede tumbar el plano de control

El fallo de disponibilidad se limita al modo ambient con un waypoint identificado por dirección IP. Si un segundo servicio —por ejemplo, un recurso ServiceEntry creado en cualquier namespace— reclama esa misma dirección, istiod puede entrar en pánico y reiniciarse continuamente hasta que se elimine la colisión. El resultado operativo no es solo un pod inquieto: puede detener la distribución de configuración y la rotación de certificados de toda la malla.

La condición de permisos también importa: una persona que pueda crear ServiceEntry en su propio namespace puede activar el problema si coincide con la configuración anterior. Los waypoints cuyo destino se anuncia por nombre de host, que son el valor predeterminado descrito por Istio, no están afectados por este fallo. El boletín le asigna CVSS 7,7.

El aviso incluye además dos fallos en filtros HTTP de Envoy. Un CONNECT sin cabecera :path podía provocar un cierre remoto sin autenticación en el filtro OAuth2 (CVSS 7,5); otro caso causaba un cierre en api_key_auth al ocultar credenciales ante la misma forma de petición (CVSS 6,5). Para estos problemas la exposición depende de usar esos filtros en una de las ramas afectadas; no basta con que el clúster tenga Envoy.

-InfraCrew dice: “tenemos Istio” no es un diagnóstico; versión, modo y filtros hacen la diferencia.-

Qué revisar antes de actualizar

Empieza por separar los tres escenarios. Inventaría la versión exacta y las políticas que combinan HTTP/2 con DENY.methods o ALLOW.notMethods; después identifica los waypoints ambient por IP y quién tiene permisos para crear o actualizar ServiceEntry. Revisa también si los filtros OAuth2 o api_key_auth están configurados. Así se determina qué riesgo aplica a cada clúster y qué prueba de regresión merece prioridad.

La corrección preferente es actualizar a 1.31.2, 1.30.6 o 1.29.9, según la rama. Para el bypass, Istio propone como medida temporal usar reglas ALLOW con una lista explícita de métodos. Para el fallo de ambient, restringir la creación y modificación de ServiceEntry a administradores de confianza o usar waypoints con nombre de host reduce la condición de colisión; esas medidas no corrigen los fallos de Envoy.

La rama 1.29 exige planificar la salida: 1.29.9 corrige el aviso, pero es su versión final y ya está fuera de soporte. Los equipos que la ejecutan deberían incluir el salto a 1.30 o posterior en su ventana de mantenimiento, probar configuración y compatibilidad de extensiones y evitar convertir la mitigación temporal en un estado permanente.

Diccionario de la Crew

Istio — plataforma de malla de servicios que controla comunicación y políticas entre cargas de trabajo.
Envoy — proxy que gestiona el tráfico de red de las cargas dentro de Istio.
AuthorizationPolicy — recurso de Istio que permite o deniega tráfico según identidad, operación y otros atributos.
HTTP/2 — versión del protocolo HTTP con un formato de transporte distinto al de HTTP/1.1.
Modo ambient — arquitectura de Istio que aplica funciones de malla sin inyectar un proxy sidecar en cada carga.
istiod — plano de control de Istio que distribuye configuración y certificados.
ServiceEntry — recurso que incorpora un servicio externo o una dirección a la configuración de la malla.
Waypoint — proxy de capa 7 usado por Istio ambient para aplicar políticas y gestionar tráfico de un servicio.
CVSS — sistema que resume la severidad técnica de una vulnerabilidad mediante una puntuación y métricas.