- security
- node.js
- php
- patching
- dependencies
Vulnerabilidades PHP y Node.js: parches del 21 de octubre
PHP y Node.js publicaron parches urgentes el 21 de octubre de 2026: dos fallos de 9,2 en el intérprete de PHP y diez CVE en Node.js. El reto real es localizar cada entorno afectado.
6 min de lectura

El miércoles 21 de octubre de 2026, los proyectos PHP y Node.js publicaron actualizaciones de seguridad urgentes el mismo día. Ambos avisos corrigen fallos que pueden desembocar en ejecución remota de código: un atacante sin credenciales consigue que el servidor ejecute instrucciones propias. Las vulnerabilidades PHP y Node.js coinciden en la fecha y en el tipo de riesgo, y la coincidencia importa porque ambos entornos de ejecución —el programa que interpreta y ejecuta el código de la aplicación— se despliegan ampliamente en servicios web y suelen viajar escondidos dentro de imágenes de contenedor, paquetes del sistema y tuberías de integración continua.
El alcance, sin embargo, no es simétrico. Node.js publicó versiones nuevas para sus tres ramas con soporte —26.x, 24.x y 22.x— que corrigen diez vulnerabilidades, cuatro de ellas con gravedad «Alta» (aviso oficial de Node.js). PHP publicó parches de emergencia para dos fallos del intérprete central, CVE-2026-109618 y CVE-2026-109619, ambos con 9,2 sobre 10 en CVSS v4.0 (aviso del servicio de TI de la Universidad de Washington). Un CVE es el identificador público y único de una vulnerabilidad conocida; CVSS, la escala que resume su gravedad.
Dos avisos el mismo día, con rastros documentales muy distintos
Las dos vulnerabilidades de PHP viven en el núcleo del intérprete y, según el aviso universitario, permiten que un atacante no autenticado ejecute código de forma remota en un servidor web afectado. La cobertura en español de los avisos coincide en la fecha y en los identificadores (Irontec).
La asimetría está en la documentación disponible. Node.js cuenta con un aviso primario que nombra a quienes reportaron y corrigieron cada fallo. Para PHP, en el material consultado, la descripción detallada procede de una página de estado de un servicio universitario y de coberturas secundarias; el mecanismo concreto de los dos fallos no se describe, y tampoco el rango exacto de versiones afectadas ni los números de versión que contienen la corrección. Es una diferencia relevante para quien debe evaluar el riesgo: se conocen la puntuación y el impacto potencial, no la ruta de explotación.
Un dato adicional, reportado y no confirmado de forma independiente: los detalles de los dos fallos de PHP se hicieron públicos antes de que existieran los parches, y eso es lo que lleva al aviso a calificar la actualización como urgente (UW IT). Si esa cronología se sostiene, la ventana entre la publicación del detalle y la disponibilidad del parche es exactamente el periodo en que un atacante con recursos puede construir un exploit.
Un resumen en español de la misma fecha titula con vulnerabilidades críticas en PHP, GitLab, Node.js y Linux (CDMon), aunque no aporta detalle sobre los dos últimos, de modo que el material consultado no permite relacionarlos con estos parches.
Una escritura fuera de límites en el decodificador Brotli
El fallo más grave de Node.js es CVE-2026-111497: una escritura fuera de límites en el decodificador Brotli que la propia alerta vincula con ejecución remota de código. Una escritura fuera de límites ocurre cuando el programa escribe datos más allá del espacio de memoria reservado para ellos; si el atacante controla esos datos, puede alterar estructuras internas y redirigir la ejecución. Afecta a 26.x, 24.x y 22.x, y según el análisis de TuxCare no hace falta que el código de la aplicación llame directamente a Brotli para quedar expuesto: basta con que un proceso sin parche descomprima datos Brotli controlados por un atacante (TuxCare).
El aviso de Node.js atribuye el reporte a OpenAI Codex Security (Khai Tran y Sylvie Mayer) y la corrección a los colaboradores mcollina y aduh95. TuxCare, en un análisis que no aparece replicado en el resto del material consultado, sitúa la corrección de Brotli en el repositorio google/brotli en febrero de 2026, sin versión de seguridad asociada, y una prealerta de gravedad «Alta» enviada por Antoine du Hamel a la lista oss-security el 14 de octubre, una semana antes de las versiones corregidas. Son datos de una sola fuente y conviene tratarlos como tales.
El resto del paquete de Node.js incluye un fallo de gravedad media en el manejo de sockets keep-alive, que procesa una respuesta escrita antes de que se enviara la petición (CVE-2026-105481), y otro también medio en la validación de certificados para nombres de host IPv4 no canónicos (CVE-2026-106072). Este último merece atención pese a su calificación: el fallo afecta la comprobación de identidad del extremo y permite que un nombre DNS incluido en el certificado autentique un extremo identificado por IP (nodejs.org). Se suman dos fallos de gravedad baja en el modelo de permisos, CVE-2026-106071 —solo en 26.x— y CVE-2026-106073, presente en las tres ramas.
Versiones corregidas y las ramas que ya no reciben parches
Las compilaciones que contienen las correcciones son Node.js v22.23.4, v24.22.1 y v26.12.1 (nodejs.org). Las ramas que ya alcanzaron el final de su vida útil no reciben parches del proyecto y siguen afectadas por estas vulnerabilidades, según el aviso al cliente de easyDNS (easyDNS). En la práctica eso deja dos caminos: migrar a una rama soportada o recurrir a un proveedor de soporte extendido; el material consultado no detalla qué compilaciones corregidas existen para esas ramas ni con qué calendario.
Hay un detalle operativo que se repite en cada ola de parches. El aviso de mitigación de PHP indica reiniciar todos los workers después de cambiar la configuración del pool (Devin). Como consecuencia razonable del modo en que operan estos procesos —y no como un dato que los avisos desarrollen—, sustituir el binario sin reiniciar los procesos en marcha deja el código vulnerable cargado en memoria hasta que esos procesos se reinician.

Por qué «actualizar la dependencia» subestima el trabajo
Los entornos PHP y Node.js afectados aparecen en imágenes de contenedor, paquetes del sistema operativo, tuberías de CI y configuraciones de infraestructura repartidas por muchos repositorios; por eso la remediación exige identificar, actualizar, probar y desplegar cada despliegue afectado, no solo editar una cadena de versión (Devin).
El cuello de botella es el inventario, no la descarga. La pregunta que decide el calendario de la semana no es qué versión hay que instalar, sino dónde vive un binario de PHP o de Node.js en la infraestructura propia. Las imágenes base y los ejecutores de CI con versiones fijadas son los puntos ciegos habituales: son justamente los lugares donde un entorno de ejecución no aparece en ningún manifiesto de dependencias y, por tanto, ningún escaneo de librerías lo detecta. Esa observación es una inferencia editorial a partir de cómo se distribuyen estos componentes, no un dato de los avisos.
Estado de la explotación: una demo débil y ningún ataque confirmado
TuxCare reporta que el 22 de octubre una prueba de concepto pública solo logró ejecutar código en una compilación debilitada a propósito, lo que no demuestra explotabilidad sobre el software tal como se distribuye. El mismo análisis recoge que Brotli publicó las versiones 1.2.1, 1.1.1 y 1.0.10 el 21 de octubre y que Vercel desplegó reglas de WAF para el tráfico entrante. Esos datos descansan en una sola fuente y no aparecen replicados en el material disponible.
Ninguna fuente confirma explotación activa en entornos reales. La ausencia de reportes no equivale a ausencia de ataques: significa que, hasta hoy, no hay evidencia pública.
Si la actualización de PHP no puede hacerse hoy
Las medidas provisionales documentadas son concretas: desactivar session.upload_progress.enabled en php.ini o en el pool de FPM y reiniciar todos los workers, y limitar en el proxy el tamaño del cuerpo de las peticiones y el número de partes multipart. Hay una advertencia contraintuitiva que conviene subrayar: no deben usarse RLIMIT_AS ni RLIMIT_DATA como paliativo, porque activan la ruta de código vulnerable (Devin).
Se trata de contención, no de remediación: reducen la exposición mientras la compilación corregida atraviesa las pruebas. En Node.js no se documenta un equivalente tan accesible, y la prioridad declarada por el aviso son los servicios expuestos a internet que descomprimen Brotli, incluidos clientes HTTP, servidores y proxies.
La prioridad entre las vulnerabilidades PHP y Node.js la marca la diferencia de documentación y de puntuación: dos fallos de 9,2 cuyos detalles se conocieron antes del parche, frente a diez CVE con un aviso primario completo. Queda abierta una pregunta que el material no resuelve: si aparece una prueba de explotación que funcione sobre las compilaciones tal como se distribuyen, la evaluación de urgencia de CVE-2026-111497 tendrá que subir un escalón. Mientras tanto, el indicador que conviene vigilar no es la gravedad del CVE, sino el inventario: qué servicios siguen ejecutando una versión sin parchear.
Preguntas frecuentes
+¿Qué versiones de Node.js corrigen las vulnerabilidades de octubre de 2026?
Las versiones publicadas el 21 de octubre de 2026 son Node.js 22.23.4, 24.22.1 y 26.12.1, correspondientes a las ramas 22.x, 24.x y 26.x. Corrigen diez vulnerabilidades, cuatro de gravedad alta, entre ellas CVE-2026-111497, una escritura fuera de límites en el decodificador Brotli que permite ejecución remota de código.
+¿Qué ramas de Node.js ya no reciben parches de seguridad?
El aviso al cliente de easyDNS indica que las ramas que alcanzaron el final de su vida útil no reciben parches del proyecto Node.js y siguen afectadas por estas vulnerabilidades. Las ramas corregidas son 22.x, 24.x y 26.x. Para las demás, el material consultado no detalla qué compilaciones corregidas existen ni con qué calendario se publicarían.
+¿Qué es CVE-2026-111497 y por qué se considera grave?
Es una escritura fuera de límites en el decodificador Brotli incluido en Node.js: el programa escribe datos más allá del espacio de memoria reservado y, si el atacante controla esos datos, puede desviar la ejecución. Afecta a las ramas 26.x, 24.x y 22.x y no requiere que el código llame directamente a Brotli, solo que un proceso sin parche descomprima datos controlados por un atacante.
+¿Qué se puede hacer si no es posible actualizar PHP de inmediato?
Los avisos documentan medidas de contención: desactivar session.upload_progress.enabled en php.ini o en el pool de FPM y reiniciar todos los workers, además de limitar en el proxy el tamaño del cuerpo de las peticiones y el número de partes multipart. No deben usarse RLIMIT_AS ni RLIMIT_DATA, porque activan la ruta de código vulnerable. Son paliativos, no sustituyen al parche.
Fuentes
Las afirmaciones de este artículo se apoyan en estas fuentes:
- Vulnerabilidades críticas en PHP, Node.js y Fortinet · irontec.com
- Correcciones de seguridad de Node.js de octubre de 2026 y RCE de Brotli · tuxcare.com
- Node.js — Wednesday, October 21, 2026 Security Releases · nodejs.org
- Fixing Critical Node & PHP Flaws | Devin · devin.ai
- Customer Security Advisory – Critical Updates for PHP, Node.js, and Certificate Trust - easyDNS · easydns.com
- Critical PHP vulnerabilities (Oct 2026) · it.uw.edu
- Vulnerabilidades críticas en PHP, GitLab, Node.js y Linux · cdmon.com
- La vulnerabilidad no estaba en tu web - ITDO · itdo.com