El 21 de octubre de 2026 las tres ramas soportadas de Node.js estrenaron versiones de seguridad. En total son diez fallos corregidos, cuatro de severidad alta y uno con ejecución remota de código. Si tienes servicios en producción con la 22, la 24 o la 26, esta es de las actualizaciones que conviene hacer el mismo día.
Resumen rápido: 22.x → 22.23.4 · 24.x → 24.22.1 · 26.x → 26.12.1. La severidad máxima corregida en las tres ramas es alta.
Lo esencial en una tabla
| Rama | Versión con parches | Severidad máxima | Qué trae además |
|---|---|---|---|
| 22.x | 22.23.4 | Alta | OpenSSL y SQLite |
| 24.x | 24.22.1 | Alta | OpenSSL |
| 26.x | 26.12.1 | Alta | Rama más reciente, con cambios internos |
Las tres incluyen actualizaciones de dependencias: c-ares, undici y el almacén de autoridades de certificación. Las ramas 22 y 24 también recibieron OpenSSL; la 22, además, SQLite.
Los cuatro fallos que justifican actualizar ya
1. Ejecución remota en el decodificador Brotli
Una escritura fuera de los límites del buffer al procesar datos Brotli malformados permite ejecución remota de código (CVE-2026-111497). El riesgo real depende del diseño: un servicio que solo comprime sus propias respuestas no está tan expuesto, pero uno que descomprime cargas de usuarios —un proxy, una API que acepta contenido comprimido, un gateway— sí. Si tu arquitectura descomprime entrada de terceros, trátalo como prioridad máxima.
2. DNS que trunca nombres con byte nulo
dns.resolve podía devolver un nombre truncado cuando la consulta contenía un byte nulo (CVE-2026-105482). El problema no es el error en sí, sino la diferencia entre lo que tu aplicación valida y lo que realmente resuelve: comparaciones de dominios, listas de permitidos o reglas de negocio pueden evaluar un valor distinto al que luego se usa.
3. Dos formas de saltarse la validación de certificados TLS
La primera usa direcciones IP escritas con dígitos de ancho completo (CVE-2026-105483). La segunda aprovecha hosts que resuelven de forma laxa a una IP (CVE-2026-106069). En ambos casos, un certificado emitido para un nombre DNS podía autenticar un endpoint identificado por IP. Para un cliente que valida certificados, esto abre la puerta a un ataque de intermediario si hay control del tráfico o de la resolución.
Severidad media: lo que también conviene atender
- Sockets keep-alive: un socket podía procesar una respuesta que se había escrito antes de enviar la petición (CVE-2026-105481). Útil para mezclar respuestas entre contextos si hay reutilización de conexiones.
- Certificados para IPv4 no canónicas: un SAN de tipo DNS podía validar un endpoint IP (CVE-2026-106072). Misma familia que los fallos altos, menor alcance.
- Entropía repetida en snapshots y SEAs: la caché de
crypto.randomUUID()yrandomInt()podía terminar guardada dentro de la instantánea de arranque, haciendo que todos los procesos generen los mismos valores (CVE-2026-106074). Esto es serio si distribuyes binarios con snapshot o Single Executable Applications: los identificadores dejan de ser impredecibles.
Bajos, pero relevantes si usas funciones nuevas
- ZipFile: tras una validación fallida de cabecera, el lector podía devolver bytes de prefijo controlados por el atacante (CVE-2026-106070, solo 26.x).
- Permission Model: sobreconcesión de permisos de filesystem por búsqueda con comodines (CVE-2026-106071, 26.x) y bypass usando
fs.realpathSync(CVE-2026-106073, todas las ramas). Si no usas el modelo de permisos, el impacto es bajo; si lo usas como sandbox, conviene revisar la configuración después de actualizar.
Las dependencias también importan
Además de los fallos propios, el parche actualiza el almacén de autoridades de certificación por el compromiso de una CA intermedia. Eso no es un detalle cosmético: si tu aplicación habla con servicios externos por HTTPS, seguir confiando en una autoridad comprometida debilita toda la cadena. Aprovecha la actualización para revisar de dónde vienen tus certificados y cuánto tiempo conservas los antiguos.
Cómo actualizar sin romper el proyecto
- Fija la versión exacta en CI y en la imagen base (22.23.4, 24.22.1 o 26.12.1). No dejes rangos abiertos si necesitas estabilidad.
- Recompila módulos nativos: un salto de parche puede requerir recompilar dependencias con node-gyp o cambiar la ABI.
- Revisa Docker y serverless: actualizar tu máquina no sirve de nada si la imagen sigue con la versión anterior.
- Prueba contenido comprimido: si aceptas Brotli de terceros, envía cargas malformadas en staging y verifica que fallan de forma controlada.
- Rota procesos con keep-alive para no arrastrar sockets abiertos con el binario viejo.
- Regenera binarios con snapshot o SEA si usas randomUUID/randomInt en ellos.
- Monitorea 48 horas después del despliegue antes de dar el cambio por cerrado.
Checklist para hoy
- ☐ Producción está en 22.23.4+, 24.22.1+ o 26.12.1+.
- ☐ Imágenes Docker y runners de CI actualizados.
- ☐ Servicios que descomprimen Brotli revisados.
- ☐ Clientes TLS que validan certificados revisados.
- ☐ Binarios con snapshot/SEA regenerados (si aplica).
- ☐ Permission Model revisado (si lo usas).
- ☐ Dependencias y lockfiles revisados.
Por qué conviene no esperar
La mitigación más barata ante cuatro fallos altos —uno con ejecución remota— es actualizar. El costo de un incidente, en cambio, incluye datos expuestos, tiempo de respuesta, reputación y clientes que se enteran por terceros. Y ojo: las versiones fuera de soporte no reciben estos parches, así que si sigues en una rama antigua, la discusión no es “cuándo actualizo”, sino “a qué rama migro”.
Conversación 3
Anónimo por defecto. Sin enlaces ni HTML: solo texto plano.