01 · Contexto
Qué está ocurriendo
AWS publicó el 29 de octubre el boletín CVE-2026-119115 sobre AWS Private CA Connector for Kubernetes. Bajo determinadas condiciones, un usuario autenticado autorizado solo para un emisor de namespace podía obtener certificados firmados por un emisor de alcance de clúster no autorizado, incluidos certificados de CA subordinada.
La corrección está en aws-privateca-issuer 1.10.1 y en el complemento EKS 1.10.1-eksbuild.1. Antes de actualizar, AWS pide revisar CertificateRequest, Certificate e Ingress y declarar issuerRef.kind como AWSPCAIssuer o AWSPCAClusterIssuer, según corresponda. Referencias antes toleradas pueden dejar de renovarse; el efecto sobre servicios aparecería al vencer los certificados. Si la actualización debe esperar, el fabricante indica limitar las políticas de aprobación y RBAC por nombre y tipo de emisor.
02 · Impacto
Por qué importa
Análisis: aquí coinciden dos riesgos que conviene administrar juntos: una autorización demasiado amplia y una interrupción diferida. Que el servicio siga respondiendo inmediatamente después de un cambio no demuestra que su siguiente renovación funcionará. Además, un nombre de recurso no expresa necesariamente su alcance: la identidad completa del emisor debe incluir el contexto en que puede utilizarse. Esta es una razón para que seguridad y plataforma compartan criterios de aceptación, en vez de tratar el parche y la continuidad como trámites separados. El boletín no permite concluir que un entorno específico fue comprometido ni que todos los certificados emitidos sean ilegítimos.
03 · Recomendaciones
Qué conviene hacer
- Como recomendación, identifique instalaciones y versiones efectivas, sus responsables y las aplicaciones que dependen de ellas. Prepare una relación entre solicitudes, emisores y fechas de vencimiento, usando metadatos y evitando exportar claves privadas. Priorice las dependencias próximas a renovar y acuerde una ventana que permita observar el comportamiento corregido. No amplíe permisos para ocultar errores de configuración; registre cada excepción temporal con responsable y condición de retiro.
- En un entorno autorizado, pruebe una emisión y una renovación con cada alcance legítimo y compruebe que una identidad sin permiso no puede cruzar ese límite. Registre versión, configuración y resultados sin incluir material criptográfico sensible. Después del despliegue, observe solicitudes fallidas o pendientes y confirme una renovación real antes de cerrar la intervención. Mantenga un procedimiento de contingencia que preserve los límites de autorización, porque recuperar disponibilidad reintroduciendo el comportamiento vulnerable no constituye una corrección satisfactoria.