Vulnerabilidad Brotli de Node.js (CVE-2026-111497): usábamos una versión afectada, la corregimos y no hallamos señales de explotación

Esta mañana escribimos que el problema de seguridad de PHP no afectaba a LFW.com, porque en nuestros servidores no se ejecuta PHP.

Este sí nos tocaba: nuestro servidor usaba una versión afectada. LFW.com funciona con Node.js, y el proyecto Node.js publicó correcciones de seguridad hoy a las 6:38 (hora del este de EE. UU.). Actualizamos nuestro servidor a las 13:24 del mismo día.

Qué corrigió Node.js

La versión corrige diez vulnerabilidades en las ramas 26.x, 24.x y 22.x. Cuatro tienen gravedad alta. La que más nos importa:

• CVE-2026-111497, el decodificador Brotli. Brotli es una forma común de comprimir el tráfico web. Un fallo en cómo Node.js lo descomprime puede escribir más allá del final de un bloque de memoria. El proyecto Node.js dice que permite ejecutar código a distancia: hacer correr el código de otra persona en su servidor.

A las 14:00 (hora del este de EE. UU.) del 21 de octubre, ni el proyecto Node.js ni la prensa especializada informan de ataques reales ni de un exploit público.

Actualice a 22.23.4, 24.22.1 o 26.12.1. Node.js dice que las versiones sin soporte siempre quedan afectadas y no reciben corrección, así que páselas a una versión con soporte.

Cómo nos alcanzó

Casi todo LFW.com son páginas generadas de antemano. Pero el servidor también hace trabajos que implican descargar sitios web de otras personas:

• la auditoría gratuita, que carga cualquier sitio que un visitante escriba;
• nuestro monitoreo, que revisa sitios según un calendario.

Cuando Node.js descarga una página, descomprime Brotli automáticamente. Así que un sitio hostil podría responder a una de esas solicitudes con datos comprimidos hechos para corromper la memoria de nuestro servidor. En el peor caso, eso permite al atacante ejecutar sus propios comandos en nuestro servidor: leer lo que guarda, instalar una puerta trasera o usarlo para atacar otros sitios. La auditoría gratuita es la parte más arriesgada, porque la dirección la elige un desconocido.

Qué hicimos, y cuándo

La cronología, en hora del este de EE. UU.:

• 6:38: el proyecto Node.js publicó las versiones corregidas.
• 13:24: actualizamos Node.js en nuestro servidor a 22.23.4 y reiniciamos el sitio.
• Justo después: revisamos el servidor en busca de señales de que alguien hubiera usado el fallo mientras estaba abierto.

Eso dejó unas seis horas y tres cuartos entre la publicación y nuestra actualización. Habríamos preferido que fuera menos.

Cómo comprobamos que nadie lo aprovechó

Empezamos por lo que nuestro servidor descargó realmente en esas horas:

• No se hizo ninguna auditoría gratuita. Nadie pidió al servidor cargar un sitio externo de su elección.
• No se hizo ningún escaneo de sitios.
• El monitoreo revisó solo nuestros propios sitios.

Las huellas que suele dejar un ataque

Después las buscamos en el servidor:

• Ningún fallo del programa. Un intento fallido de corromper la memoria suele hacer caer el programa. Los registros del servidor web de la última semana no muestran caídas, errores de memoria ni reinicios forzados.
• Nada más en ejecución. La cuenta del servicio solo ejecuta el servidor web y el motor de búsqueda, sin programas extra iniciados por ninguno de los dos.
• Nada nuevo en el disco. Ningún script ni programa nuevo en las carpetas temporales, y ningún cambio en tareas programadas ni en la configuración de los servicios aparte de nuestro propio despliegue.
• Ninguna puerta nueva. Los accesos al servidor de los últimos 30 días vinieron solo de nuestras dos claves, y la lista de claves permitidas no cambia desde septiembre.

El tráfico web

Por último, leímos cada solicitud desde la publicación hasta la actualización:

• Menos tráfico que el día anterior, y ningún error del servidor.
• Cada solicitud llegó a través de Cloudflare. Nuestro firewall solo acepta tráfico web de Cloudflare, así que nada llegó al servidor directamente.
• Unos 200 sondeos rutinarios, el ruido de fondo que recibe cualquier sitio público. La mayoría buscaba archivos PHP en un servidor sin PHP. Todos recibieron una respuesta de no encontrado o no permitido.

Estas revisiones encuentran las señales habituales de un ataque. No pueden demostrar que algo no ocurrió, y no lo afirmamos. No encontramos nada.

Dónde ayuda Cloudflare, y dónde no

Nuestro tráfico pasa por el proxy de Cloudflare, que filtra las solicitudes antes de que lleguen a nuestro servidor. Es una protección real para lo que entra.

Pero la vía principal de este fallo iba en sentido contrario: nuestro servidor leyendo respuestas de otros sitios. Cloudflare no está en esa dirección, así que lo que lo corrigió fue la actualización.

Nuestros propios equipos

Nuestras estaciones de trabajo también usan Node.js. No están expuestas a internet, así que el riesgo era menor. Por precaución, también dimos prioridad a actualizarlas a versiones corregidas.

El resto de la versión

Las demás correcciones conviene conocerlas si usa Node.js:

• Dos formas de saltarse la verificación del nombre en certificados TLS (CVE-2026-105483 y CVE-2026-106069), ambas de gravedad alta. La verificación del certificado es cómo un programa sabe que habla con el servidor correcto.
• Un fallo que recorta nombres DNS (CVE-2026-105482), de gravedad alta: los nombres con un carácter NUL oculto quedan cortados.
• Valores aleatorios repetidos en instantáneas (CVE-2026-106074), de gravedad media. Las aplicaciones empaquetadas como un solo ejecutable o una instantánea de arranque podían repetir los mismos identificadores "aleatorios" en cada proceso.
• Certificados raíz actualizados. La versión también actualiza los certificados incluidos en Node.js tras el compromiso de una autoridad de certificación intermedia de eMudhra.

La lista completa está en el aviso de Node.js.

Qué revisar por su cuenta

Si su sitio o sus herramientas funcionan con Node.js:

• Actualice a 22.23.4, 24.22.1 o 26.12.1. Sus herramientas de compilación también cuentan.
• Empiece por todo lo que descarga contenido de fuera: verificadores de enlaces, proxies de imágenes, lectores de feeds, webhooks, scrapers. Eso es lo que alcanza el fallo de Brotli.
• Vuelva a compilar todo lo empaquetado como un solo ejecutable o instantánea. Actualizar Node.js en el servidor no actualiza una copia integrada en un programa.
• ¿Usa hosting administrado? Revise la página de estado de su proveedor. Muchos actualizan Node.js por usted.

Si quiere ayuda

Con gusto le ayudamos con cualquiera de estos pasos, desde encontrar qué funciona con Node.js hasta revisar un servidor después de una actualización. Escríbanos.