PHP2Shell y LiteLLM: 6 fallos y el parcheo ya no alcanza

Seis incidentes en siete días: qué pasó realmente

Entre el 16 y el 23 de octubre de 2026, seis piezas de infraestructura crítica —PHP, Node.js, GitLab, LiteLLM, OpenCode y la autoridad certificadora eMudhra— publicaron avisos de seguridad. Tres de ellas (PHP, Node.js y GitLab) sacaron sus parches el 21 de octubre, el mismo día en que se publicó la versión maliciosa de LiteLLM.

El caso más grave es PHP2Shell: dos vulnerabilidades de ejecución remota de código sin autenticación, CVE-2026-109618 y CVE-2026-109619, cada una con puntaje 9.2. Afectan al propio motor de PHP, no a una aplicación concreta, así que cualquier sitio sobre WordPress, Drupal o Joomla con una versión vulnerable queda expuesto. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

Incidente	Qué pasó	El parche
PHP2Shell (CVE-2026-109618, CVE-2026-109619)	Dos RCE pre-autenticación en PHP, 9.2 cada una. Hubo intentos de explotación antes de la divulgación.	PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35
Node.js (CVE-2026-111497)	Escritura fuera de límites en el decodificador Brotli incluido, más nueve correcciones.	22.23.4, 24.22.1 o 26.12.1
GitLab (CVE-2026-110264)	RCE sin autenticación, CVSS 10.0, por un desbordamiento de entero en su compilador de expresiones regulares. Alcanza hasta GitLab 7.0, de 2014.	Parches del 21 de octubre, sin workaround para instancias autogestionadas
LiteLLM 1.107.0	Una release maliciosa en PyPI y en las imágenes oficiales ejecutaba un robador de credenciales cada vez que arrancaba Python.	Reconstruir desde una versión verificada y rotar credenciales
OpenCode Console	Un intruso llegó a un sistema legado y pudo exponer claves de proveedores de IA guardadas por usuarios.	Revocar y reemitir las claves
eMudhra	Ocho claves privadas de CA intermedias eran enteros menores a 256. Una era el número 4.	Los navegadores bloquearon los intermedios

Nada de esa lista es exótico. Dos son runtimes sobre los que se apoya buena parte de la web, uno es el servidor de control de versiones que muchas empresas todavía autogestionan, y otro es la pasarela de IA que muchos equipos adoptaron con prisa para enrutar tráfico hacia modelos.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Por qué la ventana de explotación se acortó tanto?

Mandiant mide cuánto tardan los atacantes en explotar una vulnerabilidad después de que se divulga. Su análisis de tiempo-a-explotación situaba el promedio en 63 días en 2018-2019, 44 días en 2020-2021 y 32 días en 2021-2022. En 2023 bajó a cinco días, y el 70% de las vulnerabilidades explotadas que Mandiant rastreó ese año fueron zero-days, atacadas antes de que existiera un parche.

PHP2Shell encaja con ese patrón y lo empuja más lejos. Los fallos se encontraron con ayuda de un modelo de IA: según el relato de OpenAI, la firma de seguridad Calif identificó el problema usando GPT-5.6 Sol dentro de su iniciativa Patch the Planet, y Wiz descubrió y reportó las vulnerabilidades de forma independiente. Wiz sostuvo que "los modelos de frontera han hecho práctico el desarrollo de exploits complejos" y que estas fallas "están entre las más severas descubiertas en PHP, y posiblemente en la historia del software".

El resultado fue un colapso del calendario. Recorded Future documentó que los detalles técnicos se filtraron antes de la divulgación coordinada, que Patchstack recibió reportes de explotación activa a las 07:34 UTC del 21 de octubre —horas antes de que saliera el parche— y que el equipo de PHP adelantó la release. Amazon Threat Intelligence reportó que los atacantes empezaron a apuntar a los fallos cuatro días antes de que se publicaran las correcciones.

El parche es lo fácil; encontrar qué parchear es lo caro

Aquí está el punto que casi nadie discute: la parte difícil no es aplicar la actualización, sino saber dónde corre la cosa afectada, quién es su dueño y a qué puede llegar. Si tienes un inventario confiable, es una tarde. Si no lo tienes, es una semana de hilos de Slack.

El tamaño del problema es enorme. Según Hackread, PHP corre cerca del 70% de todos los sitios web y, según estimaciones de Censys, más de 32,5 millones de instalaciones activas de PHP ejecutan versiones vulnerables. Recorded Future recoge dos escaneos independientes: Modat contó 4.384.302 servicios PHP en 1.886.612 hosts únicos, con cerca del 79% de los servicios con versión legible corriendo una rama que PHP ya no soporta. VirusTotal identificó unos 5,1 millones de direcciones IP con PHP, de las cuales solo cerca de 1,1 millón revelan su versión.

La lección operativa: la mayoría del PHP expuesto corre en ramas al final de su vida que no recibirán un parche oficial. Y correr la última release tampoco te salva: VirusTotal contó unas 85.000 IP en las versiones del 24 de septiembre, las más nuevas antes de la corrección.

¿Qué significa esto para tu startup?

Si tu equipo tiene menos de 50 personas, probablemente no tengas un equipo de seguridad dedicado. Eso no te exime: te obliga a ser más ordenado. Los frameworks lo dicen desde hace años. Los CIS Controls ponen el inventario de activos y el inventario de software como Controles 1 y 2; la gestión de vulnerabilidades no aparece hasta el Control 7. La directiva BOD 23-01 de CISA exige a las agencias federales de EE. UU. descubrimiento automatizado de activos cada siete días y enumeración de vulnerabilidades cada 14. Si no sabes que un servidor existe, no lo vas a parchear.

Tres acciones concretas para esta semana:

Haz la lista de runtimes al final de su vida. Node.js 20 llegó a fin de vida en abril de 2026 y las funciones Lambda en nodejs20.x dejaron de recibir parches de seguridad. Revisa también qué PHP corre por debajo de tus sitios, incluidos los que están dentro de contenedores o de plataformas gestionadas. La versión no siempre está a la vista.
Fija dependencias por digest, no por tag. El ataque a LiteLLM se sirvió a través de tags flotantes como latest y main-stable. Socket estima que LiteLLM tiene unas 23 millones de descargas semanales, así que un solo pip install sin fijar versión puede meterte el problema. La última versión segura es la 1.106.2.
Rota credenciales asumiendo compromiso. Si LiteLLM 1.107.0 corrió en un host con salida a internet, trata todo lo que ese host podía alcanzar como expuesto. Wiz observó uso de credenciales robadas apenas 4,5 horas después de la exfiltración, validando roles de AWS y consultando modelos en Amazon Bedrock, un patrón asociado al LLMjacking.

Y un detalle que se repite: este fue el segundo incidente de cadena de suministro de LiteLLM en 2026. En marzo se publicaron las versiones maliciosas 1.82.7 y 1.82.8, y Hudson Rock vinculó un archivo de 153 GB robado en ese ataque con 2.488 dominios corporativos. Revisar el código en GitHub no habría revelado nada: el ataque vive en el empaquetado, no en el código de la aplicación.

Un ejercicio de una hora para tu equipo

Toma uno de los avisos de esta semana y cronometra cuánto tarda tu equipo en responder: listar cada lugar donde corren Node.js y PHP, incluidos runtimes de Lambda, stacks de App Service, imágenes de contenedor y VMs; encontrar cada GitLab autogestionado y comprobar si internet puede alcanzarlo; poner un nombre de dueño junto a cada uno; y anotar dónde están guardadas tus claves de proveedores de IA y qué cargas de trabajo las usan.

Si eso te llevó más de una hora, el próximo aviso te va a llevar lo mismo. Y el próximo aviso, si el patrón se sostiene, no va a dar una semana de margen.