OpenShift 4.14.77 corrige siete CVE y registra un riesgo CNI

Red Hat publicó el 27 de octubre RHSA-2026:89838, una actualización de seguridad Critical para OpenShift Container Platform 4.14.77. La errata cubre imágenes de contenedor e incluye siete CVE: cambios en la confianza de certificados, fallos de red del kernel y problemas en PCRE2. No es una única vulnerabilidad repetida siete veces, y el nivel “Critical” es la valoración del aviso de seguridad para la actualización, no una prueba de explotación activa en clústeres.

La versión 4.14.77 es un z-stream de la rama 4.14: un paquete de mantenimiento dentro de la misma versión menor de OpenShift. Red Hat aconseja que las instalaciones 4.14 actualicen cuando las imágenes estén disponibles en su canal apropiado y remite a la CLI de OpenShift o a la consola para comprobarlo. La errata 89838 contiene las imágenes; su propia ficha enlaza otra errata para los RPM del release, una distinción útil al planificar el cambio en clústeres con nodos y repositorios gestionados de forma distinta.

-InfraCrew dice: En OpenShift, “llegó una errata” y “mi canal ya puede consumirla” son dos estados diferentes.-

El cambio de confianza no es cosmético

El ajuste más visible para las aplicaciones está en ca-certificates: OpenShift deja de confiar en certificados intermedios de eMudhra por motivos de seguridad. Si un servicio o integración depende de una cadena que termina en esos certificados, la validación TLS puede empezar a fallar tras actualizar. El aviso identifica CVE-2026-114406, pero no detalla en esa página todos los certificados ni cada dependencia afectada; conviene contrastar las cadenas que usan los servicios propios en vez de asumir que cualquier certificado eMudhra quedará invalidado.

Tres correcciones afectan a PCRE2, una biblioteca para expresiones regulares. Red Hat atribuye dos escrituras fuera de límites a expresiones regulares preparadas (CVE-2026-86145 y CVE-2026-103111) y otra corrupción de memoria a pcre2_jit_match (CVE-2026-89161). Para CVE-2026-86145, el fabricante describe ejecución de código mediante una expresión diseñada. La exposición práctica depende de qué componentes consuman expresiones controladas por terceros y de cómo las validen: la errata por sí sola no demuestra que exista una ruta remota explotable en cada clúster.

-InfraCrew dice: Una expresión regular no debería convertirse en una política de ejecución de código, pero conviene parchear antes de que alguien lo demuestre con una.-

Kernel, SCTP y una nota de cualificación

El lote también arregla defectos del kernel en netfilter, SCTP e IPv4. Entre ellos, CVE-2026-43114 afecta nft_set_pipapo_avx2, que podía devolver una entrada no coincidente al expirar; CVE-2026-64564 corrige el ciclo de vida del transporte ASCONF en SCTP; y CVE-2026-99999 valida checksum_start antes de completar una suma IPv4. La ficha asigna sus propios CVE a estos cambios; no atribuye a todos el mismo impacto ni describe una explotación observada. El alcance es transversal a la plataforma, pero cada pieza afecta rutas distintas de procesamiento de paquetes.

La ficha de versión para 4.14.77 añade una consideración separada de las siete CVE: registra una aceptación manual para publicar la versión pese a un riesgo recurrente de fallo al crear el sandbox de pods en CNI. La nota dice que la misma firma aparece en la nightly de origen y en 4.16.74; añade que no se ha establecido un deterioro respecto a compilaciones históricas, pero tampoco que el impacto sea equivalente o inocuo. Es una señal de cualificación de esta versión, no evidencia de que el fallo ocurra en todos los clústeres.

-InfraCrew dice: Un verde en el catálogo no borra la nota que explica por qué hubo que forzarlo.-

Cómo preparar la actualización

Para una instalación 4.14, la secuencia operativa empieza por confirmar la disponibilidad en el canal de actualización de ese clúster y revisar la ruta soportada desde su versión menor actual. Antes de promover la versión, los equipos pueden comprobar si usan cadenas de certificados eMudhra y validar el comportamiento de sus cargas con TLS, expresiones regulares y las rutas de red afectadas. Después, una prueba controlada de la actualización permite observar la salud de los pods y del sandbox CNI en el entorno real.

Red Hat recomienda actualizar los paquetes e imágenes cuando aparezcan en el canal adecuado, y enlaza las instrucciones de actualización del clúster. La página del flujo público de publicación también lista trabajos de actualización con resultados dispares, así que el dato no debe leerse como una predicción binaria de éxito o fallo para todos: sirve para revisar la ruta concreta y mantener una ventana de observación, especialmente si el clúster depende de OVN/CNI o está cerca de cambiar de versión menor.

Diccionario de la Crew

CVE — Identificador público asignado a una vulnerabilidad de seguridad.

z-stream — Actualización de mantenimiento de OpenShift que conserva la misma versión menor, como 4.14.

TLS — Protocolo que cifra conexiones y autentica sistemas mediante certificados.

CNI — Container Network Interface; interfaz mediante la que OpenShift conecta pods a la red del clúster.

PCRE2 — Biblioteca que implementa expresiones regulares compatibles con Perl.

SCTP — Protocolo de transporte que ofrece asociaciones de red y se usa, entre otros, en señalización de telecomunicaciones.

sandbox de pods — Entorno de red y ejecución que el runtime crea para cada pod antes de iniciar sus contenedores.