Node.js corrige diez fallos, uno con riesgo de ejecución remota de código. Qué pasa en VTEX y Shopify, cómo comprobar tus versiones y qué hacer hoy.
El 21 de octubre de 2026, Node.js publicó actualizaciones de seguridad para sus tres ramas con soporte: 22.x, 24.x y 26.x. Corrigen diez vulnerabilidades, cuatro de ellas de severidad alta. La más grave, CVE-2026-111497, está en el descompresor Brotli y puede permitir ejecutar código en el servidor.
En resumen: si ejecutas Node.js en tus servidores, contenedores o CI, actualiza hoy a 22.23.4, 24.22.1 o 26.12.1. Node.js 20 y anteriores ya no reciben parches. Si tu tienda está en VTEX o Shopify, el runtime de la plataforma lo gestiona el proveedor, pero lo que ejecutas tú sigue siendo responsabilidad tuya.
¿Y si mi tienda está en VTEX o Shopify?
VTEX
En VTEX IO no gestionamos Node.js: lo elige y lo ejecuta VTEX en su infraestructura. Cada app indica en su manifest.json qué versión del node builder usa. El builder 6.x funciona sobre Node.js 16 y el 7.x, el más reciente, sobre Node.js 20.
Estas versiones no aparecen en el boletín de Node.js: su actualización depende de VTEX, que es quien gestiona el runtime. No hay nada que podamos parchear nosotros. A 23 de octubre no hemos encontrado ningún comunicado de VTEX sobre estos fallos.
Lo que sí está en tu mano:
- Migrar al builder 7.x las apps que sigan en el 6.x, cuya etapa estable terminó en junio de 2025.
- Pedir a VTEX Support que confirme si ha aplicado mitigaciones para estos CVE en el runtime del builder 7.x.
- Revisar qué apps descomprimen contenido de fuentes externas o hacen llamadas HTTPS a direcciones IP, que son las más expuestas.
Shopify
Shopify no ha publicado ningún comunicado sobre estos fallos, y para la mayoría de las tiendas no hay nada que hacer. La plataforma la gestiona Shopify y los temas Liquid no ejecutan Node.js. Las tiendas Hydrogen alojadas en Oxygen tampoco, porque Oxygen ejecuta el código sobre workerd, el runtime de Cloudflare, en lugar de Node.js.
La excepción es lo que ejecutas tú. Si alojas el backend de una app propia en tu infraestructura, actualizar su Node.js te corresponde a ti. Lo mismo ocurre con las máquinas de desarrollo y el CI donde compilas Hydrogen o usas Shopify CLI.
Aparte de Node.js, este mes se han reportado redirecciones maliciosas en el checkout de tiendas Shopify a través de apps de terceros como Swym Wishlist Plus y Selleasy. Merece la pena revisar qué apps tienes instaladas.
A partir de aquí entramos en el detalle técnico, pensado para equipos de desarrollo y de sistemas.
Qué ha pasado
Las cuatro vulnerabilidades de severidad alta son estas:
- CVE-2026-111497: escritura fuera de límites en el descompresor Brotli que puede permitir ejecución remota de código. Se activa al descomprimir datos Brotli con el módulo zlib o cuando fetch() recibe una respuesta comprimida con Brotli.
- CVE-2026-105483 y CVE-2026-106069: dos formas de saltarse la comprobación del hostname en certificados TLS al conectar con direcciones IP.
- CVE-2026-105482: dns.resolve trunca los nombres que contienen un carácter NUL.
El 22 de octubre ya circulaban pruebas de concepto del fallo de Brotli, aunque no se había reportado explotación real. El boletín también corrige tres fallos de severidad media y tres de severidad baja, y actualiza dependencias como OpenSSL, Undici y los certificados raíz.
¿Qué fácil es aprovechar el fallo?
La buena noticia es que tomar el control de un servidor con este fallo no es trivial. Solo afecta a aplicaciones que descomprimen datos Brotli que puede controlar un atacante. Las pruebas de concepto publicadas hasta ahora funcionan en condiciones de laboratorio y no en todos los intentos, y a 22 de octubre no se había detectado ningún ataque real. El efecto más probable a corto plazo es la caída del servicio, no su control.
Eso no es motivo para esperar. En un solo día, la investigación pasó de un entorno preparado a propósito a la imagen oficial de Node.js. Además, los ataques actuales rara vez dependen de un único fallo: encadenan varios problemas pequeños hasta conseguir el control total de la máquina, y las herramientas de IA hacen que ese trabajo sea cada vez más rápido. Un fallo difícil de explotar por sí solo puede ser la pieza que falta en una cadena.
La actualización es un cambio de versión menor y sin riesgo para tu aplicación. Lo sensato es hacerla ahora, empezando por los servicios que aceptan peticiones comprimidas o llaman a servidores externos.
Cómo comprobar si tus versiones están afectadas
Lo que cuenta es el Node.js que ejecuta realmente cada aplicación, no lo que diga el package.json. Revisa cada entorno:
- Servidores: ejecuta node -v con el mismo usuario que arranca la aplicación.
- Contenedores Docker: comprueba la imagen desplegada, no solo el Dockerfile. Una etiqueta como node:22 no garantiza nada si la imagen se construyó hace meses.
- CI/CD: busca node-version en la configuración de los pipelines y revisa las imágenes de los runners.
- Repositorios: revisa .nvmrc, .node-version y el campo engines del package.json.
- VTEX IO: revisa la versión del builder en el manifest.json de cada app.
# Versión real en un servidor o dentro de un contenedor
node -v
# Versión de una imagen Docker desplegada
docker run --rm tu-imagen:tag node -v
# Buscar referencias a Node.js en los repositorios
grep -rn --include=Dockerfile* "FROM node" .
grep -rn "node-version" .github/ .gitlab-ci.yml 2>/dev/null
cat .nvmrc .node-version 2>/dev/null
# VTEX IO: versión del builder de una app
grep -A5 '"builders"' manifest.jsonDespués, compara el resultado con la versión segura mínima de cada rama:
- 22.x: 22.23.4 o superior.
- 24.x: 24.22.1 o superior.
- 26.x: 26.12.1 o superior.
- 20.x o anterior: sin parche, tratar como vulnerable. Hay que migrar a una rama con soporte.
Acciones rápidas
- Actualiza a 22.23.4, 24.22.1 o 26.12.1 sin cambiar de rama. Es un cambio de parche y no debería romper nada.
- En Docker, fija la versión exacta en el FROM (por ejemplo node:22.23.4-alpine), reconstruye la imagen y redespliega.
- Reinicia los procesos de larga duración (PM2, systemd, workers): siguen usando el binario antiguo hasta que se reinician.
- Verifica con node -v en el entorno real después del despliegue.
- Actualiza también las máquinas de desarrollo y los runners de CI.
- Si usas Node.js 20 o anterior en entornos propios, planifica ya la migración a una rama con soporte.