El 21 de octubre de 2026: cuando la infraestructura que no vemos se hizo notar

Hay días en los que la tecnología se siente como una foto: todo quieto, todo funcionando. Y hay días en los que esa misma foto se mueve por detrás. El 21 de octubre de 2026 fue uno de esos.

Ese día no pasó "una sola cosa mala". Pasaron varias, distintas entre sí, y la mayoría de la gente se enteró por un titular alarmante o por un mensaje de WhatsApp con demasiados signos de exclamación. La realidad, como casi siempre, es más aburrida y más interesante a la vez: hubo una falla crítica en PHP, una biblioteca de Python que se publicó con código malicioso y una tanda de actualizaciones de Node.js. Y, un día antes, un problema de certificados que terminó salpicando a Java.

No fue el fin de internet. Tampoco fue una semana para mirar para otro lado.

Cuatro historias que no son la misma historia

Antes de entrar en detalles, vale ordenar el mapa. Lo que ocurrió esos días se suele mezclar en una sola bolsa, pero son mecanismos diferentes:

La primera historia es un error en un programa. La segunda es un ataque a la cadena de suministro. La tercera es mantenimiento. La cuarta es un problema de identidad en internet. Ninguna se explica por la otra, y mezclarlas hace que tomemos peores decisiones.

PHP: el motor que sostiene media internet

PHP tiene una particularidad incómoda: es tan común que deja de parecer importante. Está en WordPress y en Moodle, en tiendas online, en intranets, en portales de municipios, en sistemas de turnos, en sistemas de gestión hechos a medida hace ocho años y en ese trámite que todavía no se puede hacer por la web. Cloudflare estima que casi el 70% de los sitios web lo usan. No es una exageración: es el lenguaje que hay detrás de muchísima de la infraestructura cotidiana que nadie mira hasta que se rompe.

Por eso lo del 21 de octubre importó tanto.

Ese día el equipo de PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen dos fallas críticas: CVE-2026-109618 y CVE-2026-109619. Esos códigos son la forma en que la industria identifica cada falla públicamente. Las dos permiten que alguien, desde internet, sin usuario ni contraseña, ejecute código en el servidor. En criollo: puede llegar a hacer que la máquina haga cosas que vos no le pediste. Al conjunto se lo conoce como PHP2Shell.

Ambas fueron calificadas con 9.2 sobre 10, o sea, críticas.

Qué fallaba, sin entrar en el laberinto

Imaginá un edificio con un portero que, cada vez que entra un delivery, anota el paquete, lo sube y cierra la puerta. Simple. Ahora imaginá que un día entra una mudanza enorme, el portero se queda sin espacio en el depósito y se va corriendo a pedir ayuda… dejando la puerta abierta y la libreta a medio completar. Cuando vuelve, no recuerda bien qué anotó y termina dejando pasar a cualquiera.

Algo así pasa con las dos fallas:

• CVE-2026-109618 (corrupción al quedarse sin memoria): cuando PHP se queda sin memoria en medio de una visita, puede cortar el procesamiento con datos internos a medio preparar. Después, la limpieza de esa visita trata esos datos incompletos como si fueran válidos. Un atacante puede preparar una solicitud web para provocar justo esa situación.
• CVE-2026-109619 (estado viejo que sobrevive): información de una visita anterior queda viva después de que su memoria se liberó. El mismo proceso atiende una visita nueva y usa esos restos antes de que todo se reinicie. Es una especie de "memoria fantasma" entre un visitante y el siguiente.

La parte más incómoda es dónde ocurre: no en tu aplicación, sino en PHP. Actualizar WordPress, el plugin de turnos o el sistema de gestión no arregla nada por sí solo. Hay que actualizar el motor.

¿A quién le pega?

A todo lo que sirva páginas con PHP, sin importar si corre en un servidor propio, un panel de hosting o la nube. La configuración más riesgosa es la clásica, donde PHP va integrado al servidor web, porque el ataque puede ocurrir antes de que la aplicación haga una sola línea. Otras formas de montarlo también están expuestas, aunque el camino sea más difícil.

También alcanza a versiones que ya no reciben soporte. La rama 8.2 sigue recibiendo actualizaciones hasta el 31 de diciembre de 2026; de ahí para abajo, la solución pasa por el paquete del sistema operativo, un proveedor con soporte extendido o directamente por mudarse a una versión viva.

Lo que se vio en la cancha

Acá conviene ser cuidadosos, porque hubo mucha información cruzada.

• El aviso de PHP se adelantó un día porque el contenido se filtró. En lugar del 22, la divulgación fue el 21.
• Cloudflare contó que activó protecciones desde las 3:02 UTC del 21, unas nueve horas antes del anuncio, y que observó tráfico de ataque contra sus clientes.
• Amazon informó que detectó un intento de explotación contra su red de señuelos el 17 de octubre, cuatro días antes de que todo se hiciera público.
• Sophos dijo haber visto varios intentos y al menos una explotación exitosa, con la descarga de un programa malicioso conocido.
• Rapid7, en cambio, aclaró que las pruebas públicas no lograban ejecutar código de forma confiable en cualquier configuración y que no había observado explotación en el mundo real. WatchTowr describió lo mismo: mucho intento, mucha prueba floja, muchos servidores que se caían.

Traducido: no fue un apocalipsis instantáneo, pero tampoco un susto teórico. Hubo intentos reales, algunos exitosos, y una carrera por actualizar antes de que aparecieran ataques más estables.

Cuando la biblioteca de confianza trae un polizón

La segunda historia es distinta y, para mí, más incómoda. No es un error dentro de un programa: es un ataque a la cadena de suministro. Esa cadena larga de personas, cuentas y procesos que hay entre el código que alguien escribe y el programa que finalmente instalás. Cuando se rompe, no hace falta que tu aplicación tenga una falla: el problema entra por una pieza en la que confiaste.

La protagonista es LiteLLM, una biblioteca de Python muy usada para conectar aplicaciones con distintos proveedores de modelos de lenguaje. Datadog estima que tiene alrededor de 23 millones de descargas semanales. No es un paquete raro: aparece en tutoriales, en proyectos internos y en herramientas de IA que se arman un viernes.

El 21 de octubre, durante unas dos horas, la versión 1.107.0 estuvo disponible con código malicioso en el repositorio oficial de paquetes de Python y en las imágenes de contenedor del proyecto. LiteLLM confirmó el incidente, retiró esos archivos y aclaró que las versiones anteriores están sanas.

Cómo se cuela un intruso en un proyecto serio

La historia tiene ritmo de película chica. Según la investigación de LiteLLM, el atacante consiguió credenciales de tres desarrolladores. Con una logró saltarse una protección del repositorio; con otra aprobó la publicación. Después usó el proceso normal de publicación, pero apuntando a una copia del proyecto con un nombre casi idéntico: un solo guion de diferencia.

El resultado fue una versión que funcionaba como siempre, pero que además traía código extra que se activaba solo. No hacía falta que la aplicación usara la biblioteca: alcanzaba con que estuviera instalada en la máquina para que el código corriera cada vez que alguien abría una terminal o ejecutaba una herramienta de Python.

¿Qué buscaba? De todo: claves de servicios en la nube, credenciales de acceso, claves de servidores, contraseñas guardadas en el navegador, variables de entorno y credenciales de proveedores de IA. También dejaba una puerta trasera para descargar y ejecutar más código más adelante.

La lección: lo que leés no siempre es lo que corre

Acá está el detalle que más me gusta rescatar. El código fuente público del proyecto, en la versión oficial, no tenía el código malicioso. El intruso estaba en el paquete compilado que efectivamente se instala.

Eso rompe una intuición muy extendida: "si revisé el repositorio, está todo bien". No necesariamente. Lo que corre en tu servidor es el paquete instalado, no el repositorio. Y si ese paquete se armó en otro lado, el código fuente puede verse impecable mientras el programa hace otra cosa.

Las recomendaciones oficiales fueron claras: dejar de usar ese entorno, reconstruirlo desde cero con una versión anterior segura y rotar todas las credenciales a las que esa máquina pudiera acceder. Si la versión estuvo instalada en un equipo con salida a internet, hay que asumir que la información pudo haber salido.

Node.js: mantenimiento, no incendio

El mismo 21 de octubre, Node.js publicó sus actualizaciones de seguridad: 22.23.4, 24.22.1 y 26.12.1. Corrigieron 10 fallas: cuatro altas, tres medias y tres bajas. La más grave fue clasificada como alta, no crítica. Vale la pena decirlo porque en redes sociales todo tiende a convertirse en "crítico".

Entre los arreglos hay temas para prestar atención:

• Un problema al interpretar nombres de dominio, que podía hacer que se leyera mal una dirección.
• Varias fallas en la validación de certificados, que podían permitir que un sitio se hiciera pasar por otro.
• Una falla en el componente que descomprime datos, que podía habilitar la ejecución de código.
• Problemas menores en los permisos y en el manejo de archivos comprimidos.

Además, la actualización renovó varias piezas internas y sumó el bloqueo de los certificados de eMudhra. Ese último punto nos lleva a la cuarta historia.

Java y los certificados: un problema de identidad

El 17 de octubre, un investigador reportó que las claves privadas de ocho certificados de eMudhra, una autoridad que emite credenciales para sitios web, eran débiles. Tan débiles que se podían reconstruir a partir del certificado público. El 18 fueron revocados y el 19 y 20 se divulgó el incidente.

¿Por qué importa? Porque un certificado de seguridad es la credencial que usa un sitio para demostrar que es quien dice ser. Si alguien tiene la clave de una autoridad que emite certificados, puede crear credenciales válidas para cualquier dominio y, en el medio de una conexión, hacerse pasar por tu banco, tu correo o tu proveedor. Es como tener la máquina de hacer documentos de identidad.

La aclaración importante: no se comprometió la infraestructura de eMudhra ni se emitió un certificado fraudulento que se haya usado. Los ocho certificados revocados no habían emitido credenciales para ningún cliente. El riesgo era la posibilidad, no un hecho consumado.

Java entró en esta historia porque su lista de certificados confiables incluía la cadena afectada. El 21 de octubre publicó un aviso de seguridad para bloquear esos certificados en sus versiones 8, 11, 17, 21, 25 y 27. Oracle, por su parte, había publicado su ronda habitual de actualizaciones de octubre un día antes, con 55 correcciones para Java, pero eso es mantenimiento y no la respuesta a este incidente.

O sea: Java no sufrió el mismo tipo de ataque que PHP ni el de LiteLLM. Recibió el impacto de un problema de certificados que venía de otro lado.

Por qué esto nos importa aunque no programemos

Hay dos formas de que un sistema termine en malas manos, y conviene distinguirlas.

La primera es una vulnerabilidad: el software tiene un error y alguien lo aprovecha. Es lo de PHP. El sistema es legítimo, el código es legítimo, pero hay una grieta. Se arregla actualizando.

La segunda es un ataque a la cadena de suministro: el software que instalás es legítimo de nombre, pero alguien metió algo en el camino. Es lo de la biblioteca de IA. No hay grieta en tu código: hay un intruso en el paquete. Se arregla revisando, borrando, reconstruyendo y rotando credenciales.

La diferencia no es académica. Si te equivocás de diagnóstico, aplicás la solución equivocada. Actualizar los plugins del sitio no arregla un motor vulnerable. Revisar el repositorio no garantiza que el paquete instalado sea el que viste. Y rotar contraseñas no sirve si el programa malicioso sigue ahí, esperando que alguien vuelva a usar la máquina.

Lo que hace especial a PHP es la escala y la memoria. Es un lenguaje que sostiene portales de gobierno, sistemas de salud, gestores de contenido, sistemas de gestión y aplicaciones que nadie tocó desde 2019. Según Censys y VulnCheck, en esos días había más de un millón de servidores PHP con versiones sin actualizar, y una buena parte corría versiones fuera de soporte. No es un problema de desarrolladores descuidados: es un problema de inventario. Muchas organizaciones no saben qué tienen.

Qué revisar ahora

Si tenés un sitio, una plataforma o un servidor, esta es la lista corta y concreta:

1. Buscá todos los PHP que tengas. No solo el de producción: entornos de prueba, subdominios viejos, paneles de hosting, servidores en la nube y sistemas que traen PHP adentro.
2. Actualizá el motor, no solo la aplicación. PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o el paquete actualizado de tu sistema operativo.
3. Reiniciá el servicio después de actualizar. Una actualización nueva no hace nada si el proceso viejo sigue corriendo; verificá que la versión activa sea la nueva.
4. Si no podés actualizar ya, reducí la exposición. Limitar la memoria y el tamaño de las solicitudes, y desactivar funciones que no uses, sirve para ganar tiempo, no para quedarse tranquilo.
5. Si tu equipo instaló la versión afectada de esa biblioteca, no la sigas usando. Reconstruí el entorno desde cero con una versión anterior segura y revisá que no queden restos.
6. Rotá credenciales. Todas las que esa máquina pudiera alcanzar: nube, base de datos, credenciales de acceso, claves de proveedores de IA, contraseñas del navegador.
7. Actualizá Node.js a 22.23.4, 24.22.1 o 26.12.1 si te corresponde. No es una emergencia del tamaño de PHP, pero es parte del mismo mantenimiento.
8. Actualizá los certificados del sistema y el Java que uses. En muchos Linux alcanza con actualizar el sistema; si tenés un Java instalado aparte, actualizalo también.
9. Fijá versiones y revisá de dónde baja cada dependencia. Instalar siempre "lo último" sin fijar una versión es una ruleta.
10. Cuidá las credenciales de tus herramientas. El incidente de la biblioteca de IA empezó con accesos de desarrollo. Esas credenciales valen tanto como una llave de producción.

Fuentes

• PHP.net — Security advisory: Critical remote code execution vulnerabilities
• PHP.net — Aviso previo del 20 de octubre de 2026
• CERT-EU — Critical Vulnerabilities in PHP (2026-018)
• Cloudflare — Deploying protections against php2shell
• Rapid7 — CVE-2026-109618 y CVE-2026-109619
• Amazon Security — PHP2Shell exploitation prior to public disclosure
• Sophos — Proof-of-concept exploit released for PHP vulnerabilities
• Node.js — October 21, 2026 Security Releases
• LiteLLM — Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised
• Datadog Security Labs — LiteLLM supply chain compromise
• JFrog Security Research — LiteLLM Hijacked Again
• OpenJDK — Vulnerability Advisory 2026/10/21 (CVE-2026-91403)
• Oracle — Critical Patch Update October 2026
• eMudhra — Statement on the certificate security incident
• Mozilla — Protecting Firefox users after the eMudhra compromise

Reflexión

Venimos de semanas en las que los avances de la IA en materia de ciberseguridad nos exponen una realidad: desplegamos código más rápido, creamos proyectos y MVP en cuestión de semanas, pero ¿realmente está todo bajo control?

Sin duda, la IA ha ayudado a localizar y corregir estos problemas en tiempo récord. Además, el fácil acceso a herramientas y agentes permite migrar sistemas, aplicar fixes y actualizar dependencias antes de que un atacante intente explotarlos.

En Althera hicimos nuestra parte: nos pusimos al día con nuestros servicios, actualizamos las versiones de nuestras dependencias y entornos, y nos aseguramos de que la información de nuestros clientes esté bajo llave.