El 21 de octubre de 2026, Node.js publicó versiones nuevas para corregir varios fallos de seguridad. Uno de ellos es grave: afecta a la forma en que Node.js descomprime datos en formato Brotli y, en el peor caso, podría permitir que alguien ejecute código en el servidor. Si tu web, tu tienda o tus automatizaciones funcionan con Node.js, te conviene comprobar qué versión está corriendo de verdad.
Si no sabes qué es Node.js, no pasa nada: este artículo no pide que lo sepas. Te explicamos qué se corrigió, cuándo te afecta y cuándo no, y qué preguntas hacerle a quien te mantiene la web para quedarte tranquilo con una respuesta concreta, no con un «ya está».
- El fallo está en la descompresión de datos Brotli dentro de Node.js. El riesgo existe si una aplicación descomprime datos que puede enviar alguien de fuera.
- Está corregido en Node.js 22.23.4, 24.22.1 y 26.12.1. Lo que cuenta es la versión que corre en el servidor, no la que figura en el código del proyecto.
- Una web en WordPress no usa Node.js para funcionar. Las que sí lo usan son muchas tiendas y aplicaciones modernas, y herramientas de automatización como n8n.
Qué se corrigió y cuándo
Node.js es el programa que hace funcionar muchas aplicaciones web escritas en JavaScript: el «motor» que corre en el servidor. Brotli es un formato de compresión, como un ZIP, que se usa mucho en internet para que las páginas pesen menos al viajar.
Según el aviso de seguridad de Node.js de octubre de 2026, el decodificador de Brotli que viene dentro de Node.js podía escribir fuera de la zona de memoria que tiene reservada cuando recibía datos comprimidos mal formados a propósito. El aviso lo califica de gravedad alta y le asigna el identificador CVE-2026-111497. Las consecuencias posibles que describe son tres: que la aplicación se caiga, que deje ver datos de su memoria o que alguien ejecute código en el servidor.
El fallo venía de la biblioteca Brotli de Google, que también publicó su corrección. Estas son las fechas, todas de fuentes oficiales consultadas el 25 de octubre de 2026:
- 21 oct 2026Node.js publica las versiones corregidas de sus líneas 22, 24 y 26.
- 21 oct 2026Google publica Brotli 1.0.10, 1.1.1 y 1.2.1 con la misma corrección.
- 22 oct 2026El registro de avisos de seguridad de GitHub publica la ficha del fallo.
La ficha del registro de GitHub indica que el problema estaba en las versiones de Brotli de la 1.0.3 a la 1.2.0, y las notas de publicación de Brotli recogen la corrección en las tres versiones nuevas. Ninguna de las fuentes oficiales habla de ataques ya ocurridos. Describen un riesgo que conviene cerrar, no un incidente.
Cuándo te afecta y cuándo no
Aquí está la diferencia que más confunde. Que tu web sirva archivos comprimidos con Brotli es normal y no es el problema. Muchos servidores comprimen las páginas antes de enviarlas a los visitantes, y eso no tiene que ver con este fallo.
El riesgo aparece cuando una aplicación hecha con Node.js descomprime datos Brotli que puede mandar otra persona. El aviso lo dice así: un atacante tiene que poder enviar datos Brotli que la aplicación descomprima con el módulo de compresión de Node.js (node:zlib). Saber si tu aplicación hace eso en algún punto es trabajo de quien la programó. Por eso la respuesta segura no es averiguarlo, sino actualizar.
Como orientación, así queda cada tipo de web:
Un ejemplo propio: esta web se genera con Node.js, pero lo que recibe cada visita son archivos ya preparados, sin Node.js atendiendo en ese momento. En cambio, la automatización que recibe nuestro formulario corre en n8n, que sí funciona con Node.js. Es la parte que entra en el inventario.
El código del proyecto no es el servidor
Este es el error más frecuente al revisar un fallo así. En el código de una aplicación suele haber un archivo que dice qué versión de Node.js se espera. Cambiar ese número no actualiza nada en el servidor. Lo que importa es la versión que está corriendo en producción, la que atiende a tus clientes.
Tres situaciones en las que la versión real puede no ser la que crees:
- El hosting elige la versión. En muchos alojamientos con Node.js, la versión se selecciona en el panel del proveedor. Hay que mirarla ahí, o pedírsela.
- La aplicación corre en un contenedor. Si se usa Docker u otro sistema parecido, el contenedor trae su propia versión de Node.js dentro. No basta con actualizar el servidor: hay que reconstruir el contenedor con la versión nueva y volver a desplegarlo.
- Node.js viene del sistema operativo. Algunas distribuciones de Linux aplican la corrección sin cambiar el número de versión. En ese caso, el número no sirve como prueba: hay que pedir la referencia del aviso de seguridad del proveedor del sistema que incluye este arreglo.
Qué pedirle a tu equipo técnico o a tu proveedor
No hace falta que lo hagas tú. Lo que sí conviene es pedir respuestas que se puedan comprobar. Estas son las que pediríamos:
Si te mantiene la web una persona de confianza, estas preguntas no son una auditoría: son una forma de dejar por escrito qué se revisó. Si un proveedor responde «está todo bien» sin versión ni fecha, vuelve a preguntar.
Después de actualizar: comprobar que todo sigue funcionando
Actualizar Node.js es un cambio en el servidor, y como cualquier cambio puede tener efectos. El aviso de octubre incluye además otras correcciones, entre ellas de conexiones seguras y de búsqueda de direcciones de internet. Después de actualizar, conviene probar lo que cobra o lo que trae clientes:
- Los formularios. Un envío de prueba que llegue de verdad a quien tiene que llegar. Si usas WordPress para otras partes del sitio, el recorrido para encontrar dónde se corta un formulario está en el formulario de WordPress dice «enviado», pero el correo no llega.
- Las conexiones con otros sistemas. Si la aplicación envía datos a tu CRM, a tu sistema de facturación o a una pasarela de pago, una prueba de cada conexión.
- Los procesos automáticos. Las automatizaciones que corren solas cada día. Que la siguiente ejecución termine bien, y no solo que el servidor arranque.
Y antes de tocar nada, una copia de seguridad que se pueda restaurar. La lógica es la misma que explicamos para WordPress en probar una copia de seguridad: una copia que nunca se restauró es una suposición.
Lo que no conviene hacer
- Dar por hecho que estás a salvo porque tu web «comprime» con Brotli o porque no lo hace. El fallo está en descomprimir datos que llegan de fuera, no en servir páginas comprimidas.
- Suponer que te atacaron. Ninguna fuente oficial informa de ataques. Si notas algo raro en el servidor, es otro tema y merece su propia revisión, pero este aviso no lo demuestra.
- Actualizar solo el número del código. Sin cambiar el Node.js de producción, o sin reconstruir el contenedor, la corrección no llega a ningún lado.
- Actualizar sin probar. Una actualización de seguridad que rompe el formulario de contacto te deja sin consultas, aunque el servidor esté protegido.
Si tu web está hecha con WordPress, este fallo no te toca, pero las actualizaciones de plugins sí. Lo explicamos en actualizaciones automáticas en WordPress. Y si estás por encargar una tienda o una aplicación a medida, la pregunta de quién la mantiene actualizada conviene hacerla antes de empezar, en desarrollo web.
