etcd publica tres parches para v3.7, v3.6 y v3.5 con correcciones de seguridad y fiabilidad

23 oct 2026, 10:00·2 fuentes

Por InfraCrew Editorial · Criterios editoriales y correcciones

SIG-etcd publicó v3.7.3, v3.6.16 y v3.5.35. Las releases corrigen vulnerabilidades de Go y dependencias, carreras de datos y regresiones en etcd; qué versión corresponde a cada rama y qué validar antes de actualizar.

$Dos manos enguantadas colocan tres placas con las versiones etcd v3.7.3, v3.6.16 y v3.5.35 en una mesa de servicio junto a una bandeja de servidor; el bolsillo del técnico lleva una etiqueta Infracrew.$

SIG-etcd publicó el 22 de octubre tres parches para las ramas mantenidas de etcd: v3.7.3, v3.6.16 y v3.5.35. La recomendación oficial es actualizar pronto, pero la versión que corresponde depende de la rama ya desplegada. No es una invitación a saltar de serie: la release correcta es la última de la línea que el entorno mantiene y cuya ruta de actualización ya se ha validado.

La primera novedad es seguridad en la cadena de compilación. Los binarios incorporan Go 1.26.10, que corrige problemas en la biblioteca estándar y deja de confiar en certificados eMudhra comprometidos. El anuncio de etcd también enumera correcciones en golang.org/x/net, OpenTelemetry, klauspost/compress y golang.org/x/crypto. En la práctica, esto reúne arreglos del runtime y de dependencias que forman parte del mismo ejecutable; no basta con comprobar la versión de Go instalada en una máquina si etcd se distribuye como binario o imagen.

Entre los identificadores que SIG-etcd menciona está CVE-2026-97032, un fallo de Go relacionado con servidores HTTP/2: un cliente malicioso podía provocar una caída al modificar de forma concurrente la tabla HPACK mientras el servidor respondía. El registro de Go sitúa la corrección de esa vulnerabilidad en las versiones a partir de 1.26.9; etcd construye estas releases con 1.26.10. Es una condición de denegación de servicio, no una prueba de acceso a los datos del clúster ni de ejecución de código. Conviene separar el defecto de una dependencia de lo que el advisory demuestra sobre el producto que la incorpora.

La lista no termina en la biblioteca estándar. etcd actualiza x/net a v0.61.0, componentes de OpenTelemetry a v1.45.0, x/crypto a v0.57.0 y la biblioteca de compresión klauspost/compress. El proyecto también deja de confiar en certificados eMudhra comprometidos. La combinación importa más que cada número aislado: aunque una CVE concreta no aplique a la configuración local, el parche recoge varias correcciones públicas en piezas que el servidor usa directamente.

-InfraCrew dice: Cuando el changelog menciona cinco dependencias y una carrera de datos, “solo un bump de versión” deja de ser un resumen útil.-

También hay arreglos de fiabilidad

En v3.7 se corrige el envío de mensajes MsgApp en orden inverso y una carrera de datos en RangeStream cuando se solicitan claves sin valores. Otro arreglo reduce una carrera potencial en todas las versiones; en v3.6, además, se evita un pánico provocado por un Lease ID mal escrito. No son detalles cosméticos: etcd coordina escrituras replicadas mediante Raft, así que fallos en el flujo de mensajes o en una lectura concurrente pueden terminar en errores de servicio difíciles de diagnosticar desde la aplicación que depende del clúster.

Los mantenedores también marcan como obsoleto logutil.NewJournalWriter, con la vista puesta en retirarlo en v3.8. Ese aviso no obliga a cambiar configuración hoy, pero sí conviene buscar usos propios de esa API en herramientas que compilan contra los paquetes de etcd. La versión 3.8 es el horizonte de retirada, no una razón para apresurar una migración de rama antes de tener una ruta soportada.

etcd suele vivir detrás del plano de control de Kubernetes, ya sea como parte de la distribución o en un clúster externo. Una parada de etcd puede impedir que el API server lea y escriba estado aunque los contenedores ya arrancados sigan ejecutándose. Por eso, el alcance de este parche no se mide solo por el número de servidores etcd: también cuenta qué clústeres dependen de ellos y quién gestiona la base de datos en cada plataforma.

-InfraCrew dice: El clúster puede seguir sirviendo pods mientras su memoria central está en mantenimiento; el síntoma tarda a veces más que el postmortem.-

Qué revisar antes de actualizar

Inventaría la versión exacta de cada miembro y elegiría la release de la misma rama: 3.7.3, 3.6.16 o 3.5.35. En Kubernetes gestionado, comprueba primero la matriz y la secuencia recomendada por el proveedor; en instalaciones propias, revisa la guía de upgrade de etcd y prueba el cambio con una copia representativa antes de tocar el quórum de producción. No conviertas un parche de seguridad en una actualización de arquitectura: mezclar saltos de rama, cambios de certificados y mantenimiento del clúster en una sola ventana hace más difícil atribuir un fallo.

SIG-etcd avisa de que ha recibido otros informes de problemas que no entraron en este lote y anticipa que harán falta más releases. Así que v3.7.3 y sus equivalentes corrigen lo publicado hasta este corte, pero no cierran la cola de trabajo del proyecto. Mantén seguimiento del changelog y valida salud, replicación y latencia después de cada actualización; si los síntomas aparecen, registra qué rama y dependencias quedaron realmente instaladas antes de atribuirlos al cambio.

Diccionario de la Crew

CVE — identificador público asignado a una vulnerabilidad divulgada.
HPACK — formato de compresión de cabeceras usado por HTTP/2.
Raft — protocolo de consenso que permite a varios nodos mantener un estado replicado.
RangeStream — API de etcd para leer rangos de claves como un flujo.
Plano de control — componentes que guardan el estado y coordinan cambios en una plataforma.