Entre el 19 y el 21 de octubre de 2026, tres lenguajes que sostienen buena parte de los sistemas web publicaron actualizaciones de seguridad. Si tu sistema corre PHP, Node.js o Go, la respuesta corta es: actualizá hoy, y empezá por PHP.

Se habló de "hackeo", pero lo que pasó es más concreto: se publicaron fallas críticas y, en el caso de PHP, hubo intentos de ataque antes de que existiera el parche. Hasta donde llegan los avisos oficiales, hay intentos documentados, pero ningún compromiso confirmado. Conviene no esperar a que eso cambie.

El resumen en una tabla

	PHP	Node.js	Go
Qué pasó	Dos fallas de ejecución remota de código (CVE-2026-109618 y CVE-2026-109619), con gravedad 9,2 sobre 10	Diez vulnerabilidades; la más seria permite ejecución remota desde el decodificador Brotli (CVE-2026-111497)	Una lista de rechazo en `crypto/x509` para certificados intermedios que dejaron de ser confiables (CVE-2026-111943)
Fecha	21 de octubre	21 de octubre	19 de octubre
Versiones corregidas	8.5.12, 8.4.27, 8.3.36 y 8.2.35	22.23.4, 24.22.1 y 26.12.1	1.26.10 y 1.27.3
¿Hay ataques?	Intentos documentados desde el 17 de octubre	No figuran en los avisos oficiales	No figuran en los avisos oficiales
Qué hacer	Actualizar ya: es la única solución completa	Actualizar el runtime y reconstruir las imágenes	Recompilar con la versión corregida y volver a desplegar

PHP: la que no admite demora

Las dos fallas tienen el mismo efecto, ejecución remota de código, y distinto origen:

CVE-2026-109618: si una petición agota memory_limit en el momento justo, PHP puede quedarse con datos internos a medio inicializar y tratarlos después como válidos.
CVE-2026-109619: un error fatal puede dejar estado interno apuntando a memoria que ya se liberó, y la siguiente petición del mismo proceso lo usa.

Alcanzan a todo PHP que atienda peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo más alto está en mod_php, donde el propio proyecto demostró un exploit en el que una petición sin autenticar dispara el ataque antes de que corra el código de la aplicación. El aviso de php.net es explícito: no hay mitigaciones completas, actualizar es la única opción segura.

La cronología explica por qué el apuro:

17 de octubre: Amazon detecta en un honeypot el primer intento de explotación, cuatro días antes del parche.
21 de octubre, 14:00 UTC: se levanta el embargo. Ese mismo día aparecen varias pruebas de concepto y Amazon registra intentos desde infraestructura distinta, lo que sugiere más de un actor.
23 de octubre: PHP publica un aviso informativo (CVE-2026-115560) y recomienda desactivar session.upload_progress.enabled hasta el próximo release.

Dos detalles que se suelen pasar por alto. PHP 8.1 y anteriores ya no reciben actualizaciones, y PHP 8.2 llega a su fin de vida el 31 de diciembre de 2026: si estás ahí, es el momento de planificar la migración. Y el 26 de octubre salieron builds de Windows reconstruidos con Brotli 1.2.1, por una falla que vamos a ver enseguida.

Node.js: diez fallas en una sola publicación

El 21 de octubre Node.js corrigió diez vulnerabilidades en las ramas 22, 24 y 26. Cuatro son de severidad alta: el decodificador Brotli de node:zlib (escritura fuera de límites que permite ejecución remota), dos verificaciones de nombre de host en TLS que se pueden eludir y una resolución DNS que trunca nombres con caracteres NUL. El resto son de severidad media o baja.

También actualizaron el bundle de certificados por el compromiso de una CA intermedia de eMudhra, y varias dependencias: c-ares, OpenSSL, SQLite y Undici.

Una trampa frecuente: npm update no actualiza Node.js. Lo que hay que cambiar es el runtime o la imagen del contenedor. Y las ramas sin soporte se consideran afectadas en cada publicación de seguridad.

Go: la discreta, pero no menor

Go 1.26.10 y 1.27.3 salieron el 19 de octubre con correcciones de seguridad en crypto/x509. El detalle: la biblioteca estándar agrega una lista de rechazo para que Certificate.Verify devuelva error con ciertos certificados intermedios conocidos que ya no son confiables. Afecta a las versiones anteriores a 1.26.10 y a las 1.27.x anteriores a 1.27.3. Todo indica que es el mismo episodio de la CA intermedia que mencionó Node.js.

Dos cosas para tener presentes. Once días antes, el 8 de octubre, ya habían salido otras correcciones de seguridad (en el comando go y en crypto/tls, net/http, html/template y otros paquetes), así que no es un evento aislado. Y Go compila binarios estáticos: actualizar el compilador en tu máquina no cambia lo que corre en producción. Hay que recompilar y volver a desplegar.

Un mismo componente, dos ecosistemas

El identificador CVE-2026-111497 aparece en los avisos de Node.js y de PHP. Es una falla de escritura fuera de límites en la descompresión Brotli. En Node.js vive en el decodificador de node:zlib; en los builds de PHP para Windows se alcanza a través de la extensión cURL cuando la descompresión automática de respuestas está activada, algo que cURL trae desactivado por defecto pero que las aplicaciones y las librerías HTTP pueden encender.

La lección es incómoda: las vulnerabilidades viajan por las dependencias. Mirar solo el lenguaje no alcanza.

¿Nos afecta a nosotros?

Lo primero que hicimos fue lo mismo que te proponemos a vos: preguntar qué corre, dónde y en qué versión. Para el sitio y su formulario de contacto, la respuesta es esta:

El sitio que estás leyendo son páginas estáticas que sirve nginx. No hay PHP ni Node.js ejecutándose para mostrarlas.
Node.js se usa solo para construir el sitio. No queda corriendo en producción.
El backend del formulario de contacto usa PHP y ya está en una versión corregida: verificamos la versión que informa el servidor.
Go: el sitio no tiene componentes en Go.

Aprovechamos para cerrar dos puertas. Dejamos de informar la versión de PHP en las respuestas, porque quien ataca busca versiones concretas, y apagamos session.upload_progress, que no usamos y que es la función que menciona el aviso del 23 de octubre.

Cómo se previene con un servicio constante

Un parche no es un evento: si depende de que alguien se acuerde, llega tarde. Lo que funciona es una rutina con responsables, y es lo que entendemos por un servicio constante:

Un inventario vivo. Qué lenguaje, qué versión y qué dependencias corre cada servicio, en un solo lugar. La pregunta de la semana fue "¿qué versión corre dónde?". Si responderla toma días, ya perdiste ventaja.
Avisos oficiales, no titulares. Seguimos php.net, el blog de seguridad de Node.js y go.dev, y no esperamos a que la noticia llegue por redes.
Dos velocidades. Horas para una crítica con ataques en curso, como esta; una ventana semanal para el resto. Amazon recomienda medir los plazos de parcheo en horas, no en días, cuando el sistema está expuesto a internet.
Reconstruir, no solo actualizar. Los contenedores y los binarios no se actualizan solos: hay que reconstruir la imagen y volver a desplegar.
Menos superficie. No exponer versiones, apagar lo que no se usa y, delante de todo, un firewall de aplicaciones que gane tiempo. Pero PHP lo dice sin vueltas: ganar tiempo no es lo mismo que estar corregido.
Un calendario de fin de vida. Que PHP 8.2 venza el 31 de diciembre ya está anunciado. Planificarlo evita tener que migrar con urgencia.
Revisar hacia atrás. Amazon recomienda empezar a mirar los registros desde el 17 de octubre, no desde el 21, y buscar la cadena PHP_SESSION_UPLOAD_PROGRESS en las peticiones de formularios con subida de archivos.

Nada de esto es sofisticado. Lo difícil es sostenerlo semana tras semana, con alguien que tenga el tema asignado, un calendario y un registro de lo que se hizo.

Si querés saber qué versiones tenés corriendo y qué te falta, contanos qué sistemas usás y lo revisamos juntos. Para ver cómo trabajamos la operación del día a día, mirá nuestra solución de infraestructura cloud y DevOps.

PHP, Node.js y Go parchearon fallas críticas en la misma semana: qué pasó y cómo no quedarte atrás