No solo PHP: Node.js y Java también se parchean esta semana

Esta semana todo el mundo habla de PHP2Shell, y con razón. Pero si te quedas solo con PHP, te dejas cosas. El mismo 21 de octubre, Node.js publicó parches para diez vulnerabilidades, y Oracle había sacado el día antes su actualización trimestral, con decenas de fallos en Java.

Si tu empresa tiene un backend en Node o una aplicación en Java, esto también va contigo. Vamos por partes.

Node.js: diez fallos y uno de ellos permite ejecutar código

El aviso oficial de Node.js corrige diez vulnerabilidades en las tres versiones con soporte. El peor nivel en las tres es alto. Estas son las versiones que necesitas:

Tu versión de Node	Versión con el parche
22.x	22.23.4
24.x (LTS actual)	24.22.1
26.x	26.12.1
20.x o anterior	ninguna: ya no tiene soporte

Los cuatro fallos de severidad alta son:

• CVE-2026-111497, el más gordo: un error en el descompresor Brotli que viene dentro de Node. Si tu aplicación descomprime datos Brotli que le manda alguien de fuera, un archivo preparado puede escribir fuera de la memoria que le toca y, según el propio aviso, permite ejecución remota de código.
• CVE-2026-105483 y CVE-2026-106069: dos formas de saltarse la comprobación del nombre en los certificados TLS, una escribiendo la IP con dígitos de ancho completo y otra con nombres que se resuelven de forma laxa a una IP.
• CVE-2026-105482: dns.resolve corta los nombres que llevan un carácter nulo, lo que permite que una consulta acabe resolviendo un dominio distinto del que pediste.

El resto son de severidad media y baja: sockets keep-alive que procesan una respuesta que llegó antes de la petición, certificados con IPs escritas de forma rara, un problema con los ZIP y varios agujeros en el modelo de permisos.

Ojo: aquí no basta con actualizar

Hay un fallo de severidad media que tiene trampa. CVE-2026-106074 hace que, si generas identificadores con crypto.randomUUID() o números con crypto.randomInt() mientras construyes un snapshot de arranque o un ejecutable único (SEA), esos valores se quedan guardados dentro. Resultado: todos los procesos que arrancan desde ese snapshot generan los mismos “aleatorios”.

Si usas snapshots o empaquetas tu aplicación como ejecutable único, no te vale con instalar la versión nueva de Node: tienes que volver a construir el snapshot o el ejecutable con ella.

Y si sigues en Node 20

El aviso lo deja claro: las versiones sin soporte siempre se consideran afectadas cuando sale un parche de seguridad. Node 20 y anteriores no reciben esta corrección, así que cualquier servicio en Node 20 que descomprima Brotli de fuera es vulnerable y lo va a seguir siendo. Es buen momento para planificar el salto a la 24, que es la LTS.

Java: el parche trimestral de Oracle

El 20 de octubre Oracle publicó su actualización trimestral (Critical Patch Update). Según SecurityWeek, trae 1.295 correcciones para 1.209 vulnerabilidades distintas, 95 de ellas críticas. De esas correcciones, 55 son de Java SE.

Además, al día siguiente Oracle y OpenJDK publicaron un aviso aparte, CVE-2026-91403, que es la respuesta de Java al problema de las claves débiles de la autoridad de certificación eMudhra, la que los navegadores ya habían bloqueado. En la práctica, si mantienes aplicaciones en Java, toca actualizar el JDK o el JRE a la versión de octubre de tu proveedor (Oracle, Temurin, Corretto o el que uses).

Lo bueno de Java es que estas actualizaciones llegan con fecha fija cada trimestre, así que no deberían pillar a nadie por sorpresa. Lo malo es que, precisamente por eso, mucha gente las deja para “el próximo mantenimiento” y el próximo mantenimiento no llega nunca.

Cómo saber qué versiones tienes de verdad

Esto parece trivial y es donde más se falla. La versión que te importa no es la de tu portátil, es la que corre en producción, y suele haber más de una:

• Node en el servidor: node -v te dice la del sistema, pero si usas nvm, Volta o similar, cada proyecto puede tener la suya. Mira el .nvmrc o el campo engines del package.json.
• Node en contenedores: la versión la marca la imagen base del Dockerfile (FROM node:22-...). Actualizar el servidor no cambia nada si la imagen sigue siendo la vieja: hay que reconstruirla y volver a desplegar. Si fijas una etiqueta exacta, súbela tú; si usas una genérica como node:22, reconstruye para que coja la nueva.
• Node en CI y funciones serverless: el runtime lo decide el proveedor o la configuración del pipeline. Revisa qué versión declara cada uno, porque es fácil tener producción al día y un job de CI con una versión de hace un año.
• Java: java -version en cada máquina y, en contenedores, otra vez la imagen base. Si usas un servidor de aplicaciones, ojo, que a veces trae su propio JRE empaquetado y no usa el del sistema.

Si tienes que hacer este repaso a mano en cada aviso, ya sabes por dónde empezar a automatizar.

Cómo encaja todo esto

Lo que me llama la atención de esta semana no es un fallo concreto, es la coincidencia. PHP, Node y Java, tres de los lenguajes que sostienen buena parte de los servidores del mundo, con parches serios en 48 horas. Y en el caso de PHP, con los fallos encontrados con ayuda de Inteligencia Artificial.

Siendo realistas, esto va a ser lo normal a partir de ahora: más fallos encontrados más deprisa. La única defensa que escala es tener las actualizaciones automatizadas o, como mínimo, saber exactamente qué versiones tienes desplegadas, porque el día que salga el aviso no hay tiempo de empezar a buscar.

Si tu equipo no tiene claro qué corre en cada servidor, cuéntame tu situación.

Preguntas frecuentes

¿Qué versión de Node.js necesito?

La 22.23.4, la 24.22.1 o la 26.12.1, según la rama que uses. Node 20 y anteriores ya no tienen soporte y no reciben la corrección.

¿Me afecta el fallo de Brotli si no comprimo nada?

El riesgo está en descomprimir datos Brotli que vienen de fuera con el módulo zlib de Node. Si tu aplicación no lo hace, ese fallo concreto no te expone, pero el resto de la actualización sigue siendo necesario.

¿Por qué hay que reconstruir los snapshots?

Porque uno de los fallos guarda la caché de números aleatorios dentro del snapshot o del ejecutable único. Actualizar Node no cambia lo que ya está guardado ahí: hay que volver a generarlos con la versión nueva.

¿Cuántos fallos de Java corrige Oracle en octubre?

La actualización trimestral de octubre trae 55 correcciones para Java SE, dentro de un total de 1.295 para todos los productos de Oracle.

Fuentes

• Node.js: October 2026 Security Releases
• Qualys: Node.js patches Brotli remote code execution flaw
• SecurityWeek: Oracle patches over 1,200 vulnerabilities with October 2026 CPU
• OpenJDK: aviso de vulnerabilidad del 21 de octubre de 2026

Compártelo si te ha resultado útil, sobre todo con quien despliega en tu equipo.

¿Sabes qué versión de Node o de Java corre ahora mismo en tus servidores? Cuéntame.

Y… a revisar versiones, que esta semana no se libra nadie.