Una semana, tres eslabones rotos: lo que LiteLLM, eMudhra y Node.js enseñan sobre la cadena de suministro digital
En una sola semana, una librería de IA, una autoridad certificadora y Node.js mostraron que el riesgo está en lo que su empresa usa, no solo en lo que construye.
.png)
En la tercera semana de octubre de 2026, LiteLLM publicó una versión infectada, eMudhra expuso las llaves de ocho certificados intermedios y Node.js corrigió cuatro fallas de severidad alta. Los tres casos son ataques o fallas en la cadena de suministro de software, y la IA está acortando a horas el tiempo entre que una falla se publica y se explota. La respuesta: inventario de dependencias, parcheo continuo y monitoreo de certificados.
En la tercera semana de octubre de 2026, tres incidentes en software del que dependen miles de empresas dejaron clara una idea: hoy el riesgo está en lo que su organización usa, no solo en lo que construye.
El 21 de octubre, casi toda la atención se la llevó "Black October": dos fallas críticas en PHP, encontradas con ayuda de inteligencia artificial, que provocaron caídas o servicio limitado en sitios de gobierno de Reino Unido, Finlandia y Japón mientras se aplicaban los parches. Cloudflare registró decenas de miles de intentos de explotación en los primeros 45 minutos.
Esa misma semana ocurrieron otros tres incidentes que merecen la misma atención. Ninguno atacó directamente a las empresas afectadas: todos golpearon piezas en las que todos confiamos.
1. LiteLLM: cuando la herramienta de IA es la puerta de entrada
LiteLLM es una librería de código abierto muy popular para conectar aplicaciones con varios proveedores de modelos de lenguaje desde un solo punto. El 21 de octubre, un atacante usó credenciales robadas de un desarrollador para tomar el control del proceso de publicación y distribuir una versión infectada (1.107.0) en PyPI, Docker Hub y GitHub Container Registry. Estuvo disponible entre una y tres horas, según el registro.
El paquete comprometido incluía dos componentes:
- Un ladrón de información que buscaba credenciales de nube, contraseñas y llaves de servicios de IA.
- Un troyano de acceso remoto que le daba al atacante control del equipo infectado.
Los mantenedores retiraron la versión maliciosa y publicaron una guía de remediación. El problema es que cualquier empresa que instaló esas versiones pudo haber entregado, sin saberlo, las llaves de su nube y de sus servicios de IA.
La lección: las herramientas de IA que se adoptan a toda velocidad también forman parte de la superficie de ataque, y con frecuencia nadie las tiene inventariadas.
2. eMudhra: cuando el candado de "sitio seguro" se pone en duda
eMudhra es una autoridad certificadora de India, una de las entidades que emiten los certificados digitales que hacen aparecer el candado en el navegador. Investigadores descubrieron que las llaves privadas de ocho de sus certificados intermedios (seis para sitios web y dos para firma de código) se generaron con tan poca aleatoriedad que podían calcularse en menos de un segundo.
Con esas llaves, un atacante podría emitir certificados falsos y hacerse pasar por sitios legítimos sin que el navegador muestre ninguna alerta: la página falsa se vería igual de "segura" que la real. Google y Mozilla ya bloquearon esos certificados en Chrome y Firefox, y eMudhra afirma que no se emitieron certificados con ellos. Aun así, especialistas en seguridad describieron la limpieza que viene como "más grande que Heartbleed".
La lección: la confianza en los certificados es un supuesto, no una garantía. Es necesario monitorear qué certificados se emiten para sus dominios y estar listos para reemplazarlos.
3. Node.js: cuatro fallas en el motor de millones de aplicaciones
La actualización de seguridad de Node.js del 21 de octubre corrigió diez vulnerabilidades, cuatro de ellas de severidad alta. Dos tipos de falla son especialmente delicados:
- Ejecución remota de código: una de las fallas permitía a un atacante ejecutar su propio código en el servidor.
- Evasión de la validación TLS: otras dos permitían saltarse la verificación que confirma que la conexión es con el servidor correcto, lo que abre la puerta a interceptar comunicaciones.
Node.js está detrás de una enorme cantidad de sitios, APIs y herramientas internas. Cada servidor sin actualizar queda expuesto.
La lección: aplicar parches una vez al mes ya no es suficiente cuando la pieza vulnerable está en el corazón de sus aplicaciones.
El patrón común: atacar la cadena de suministro, ahora a velocidad de IA
Los tres casos son ataques o fallas en la cadena de suministro de software: una librería, una autoridad certificadora y un entorno de ejecución. Ninguna empresa puede revisar a mano todo lo que usa, y por eso estos eslabones se vuelven el punto más rentable para un atacante.
La inteligencia artificial está acelerando ambos lados:
- Para encontrar fallas: las vulnerabilidades de PHP se descubrieron con ayuda de inteligencia artificial, y al menos una llevaba más de una década oculta. Modelos especializados como Mythos de Anthropic y GPT-Cyber de OpenAI anticipan una ola de nuevas vulnerabilidades y parches.
- Para explotarlas: CrowdStrike reportó que las intrusiones probablemente ejecutadas con agentes de IA se triplicaron en lo que va del segundo semestre de 2026, frente al primero. En Latinoamérica ya hubo campañas contra organizaciones de salud en Argentina y dependencias de gobierno en Brasil y Colombia.
El resultado es que el tiempo entre que una falla se hace pública y alguien la explota se mide en horas. Expertos citados por Infosecurity Magazine hablan de menos de 24 horas.
Qué hacer hoy
- Revise si su organización usa LiteLLM. Si se instaló la versión 1.107.0, considere esos equipos comprometidos: reconstrúyalos desde cero con una versión anterior (como la 1.106.2), siga la guía de remediación del proyecto y rote todas las credenciales de nube y llaves de IA a las que tenían acceso.
- Actualice Node.js (versiones 22.23.4, 24.22.1 o 26.12.1) y PHP a sus versiones más recientes. Si no puede aplicar el parche a un servidor expuesto, desconéctelo hasta hacerlo, como recomendaron la NSA, el FBI y CISA.
- Monitoree los certificados de sus dominios con registros de transparencia de certificados, para detectar emisiones que no autorizó.
- Mantenga un inventario real de sus dependencias (SBOM): qué librerías, versiones y servicios usa cada aplicación.
- Pase de un parcheo mensual a uno continuo, priorizando lo que está expuesto a Internet.
- Refuerce la identidad: MFA, rotación de llaves y vigilancia de tokens de sesión, porque hoy los atacantes prefieren iniciar sesión que forzar la entrada.
La pregunta ya no es si, sino cuándo
La pregunta ya no es si alguno de sus proveedores será vulnerado, sino qué tan rápido se va a enterar y qué tan rápido va a reaccionar. Las empresas que conocen su cadena de suministro y aplican parches de forma continua son las que mejor van a salir libradas de esta nueva etapa.
¿Su organización sabe hoy qué dependencias usa y cuáles están expuestas?
En ISA podemos ayudarle a averiguarlo con un ISA Security Check, un diagnóstico de 2 horas sin costo.
Referencias
- LiteLLM: Security incident, Oct 21, 2026
- CSO Online: Google y Mozilla revocan los intermedios de eMudhra
- SecurityOnline: Node.js October 2026 security release
- TechCrunch: The internet is having a very bad cybersecurity day
- Axios: Black October
- TechBriefly: PHP2Shell, guía del FBI y parches
- Cybersecurity Dive: CrowdStrike y ataques con agentes de IA
- Infosecurity Magazine: Mythos y GPT-Cyber
¿Qué tan expuesta está tu empresa?
El ISA Security Check evalúa tu postura de ciberseguridad con NIST CSF 2.0 e ISO/IEC 27001. Sin agentes, sin impacto a producción. Reporte y plan priorizado en 5 días hábiles.
Agendar diagnóstico.png)
.png)
.png)
.png)