PHP, Node.js y LiteLLM: día negro de ciberseguridad

Cuatro incidentes de seguridad en un solo día

El miércoles se acumularon cuatro frentes abiertos a la vez: dos vulnerabilidades críticas en PHP, cuatro fallos de alta severidad en Node.js, un ataque a la cadena de suministro de LiteLLM —el proxy open source que enruta pedidos a distintos proveedores de modelos de IA— y la filtración de claves privadas de eMudhra, una autoridad certificadora india. Ninguno está relacionado con el otro, pero llegaron con horas de diferencia, y eso es justamente lo que preocupa a los equipos de seguridad.

¿Qué pasó con PHP y por qué la NSA pidió apagar servidores?

El miércoles, la PHP Foundation publicó parches de emergencia para dos fallos —CVE-2026-109618 y CVE-2026-109619— que afectan a todas las instalaciones de PHP que sirven peticiones web desde la versión 5, publicada en julio de 2004, según Wired. Ambos tienen un puntaje de 9.2 sobre 10 en el sistema CVSS, y solo PHP 8.2 y versiones posteriores reciben parches.

La NSA recomendó a las organizaciones actualizar de inmediato o sacar sus sistemas de línea hasta poder hacerlo, según TechCrunch. La británica NCSC publicó una alerta en el mismo sentido. Sitios del gobierno finlandés —incluido el National Land Survey—, webs del gobierno francés y el sitio del puerto de Rotterdam quedaron inaccesibles, según reportó Reuters.

La escala del problema tiene que ver con dónde vive PHP: WordPress, Drupal y Magento están construidos sobre este lenguaje. Wiz, la firma de seguridad propiedad de Google, asegura que sus investigadores encontraron las vulnerabilidades en parte usando herramientas de IA, y que OpenAI y la firma Calif también las hallaron de forma independiente. Cloudflare reportó ataques tempranos antes de que existieran los parches, y la firma Sansec anticipó ataques masivos dentro de los 15 minutos posteriores a la publicación de las correcciones.

Node.js: cuatro vulnerabilidades de alta severidad

El runtime de JavaScript Node.js también publicó su propio paquete de problemas: cuatro vulnerabilidades de alta severidad parcheadas en su última release, según TechCrunch. Una permitía ejecución remota de código y otras dos habilitaban un bypass de validación TLS, lo que en la práctica dejaría a un atacante saltearse los controles que verifican la identidad de un servidor.

Para una startup que corre su backend en Node.js, el riesgo no es teórico: un bypass de TLS abre la puerta a ataques de intermediario (man-in-the-middle) sobre tráfico que el equipo cree cifrado y verificado.

LiteLLM: cuando el ataque llega por tu capa de IA

LiteLLM es una pieza de infraestructura cada vez más común en stacks de IA: un proxy que centraliza las llamadas a OpenAI, Anthropic, Google y otros proveedores. La compañía informó que un atacante inyectó código malicioso y publicó artefactos comprometidos en PyPI, Docker Hub y GHCR.

El código incluía un stealer de información que apuntaba a credenciales de nube, contraseñas y claves de servicios de IA, además de un troyano de acceso remoto capaz de ejecutar comandos en los sistemas afectados. LiteLLM dijo que ya removió las versiones e imágenes maliciosas y pidió a quienes las instalaron seguir su guía de remediación.

No es la primera vez que este proyecto queda en el medio. Según el análisis de incidentes publicado por la firma de seguridad Mintive, en marzo de 2026 dos versiones maliciosas de LiteLLM se distribuyeron por PyPI tras el compromiso de credenciales de publicación en su pipeline de CI/CD, y esas versiones se descargaron más de 119.000 veces antes de ser puestas en cuarentena. El detalle más incómodo de ese episodio: una de las versiones usaba un archivo .pth que se ejecutaba al iniciar Python, incluso en proyectos que no importaban LiteLLM.

eMudhra: la autoridad certificadora que rompió la confianza de la web

El cuarto frente es, probablemente, el más difícil de limpiar. eMudhra, una autoridad certificadora india, revocó ocho certificados intermedios comprometidos después de que investigadores descubrieran que sus claves privadas eran tan débiles que cualquiera podía recuperarlas casi al instante, según BleepingComputer.

Los ocho certificados usaban claves P-384 generadas en abril de 2025 con valores menores a 256, lo que permitía recuperarlas probando apenas 256 números posibles. Para demostrarlo, el investigador Flüpke publicó una de las claves en GitHub: la del certificado EM OV TLS CA - G3C tenía un valor de 4. eMudhra atribuyó el problema a un error en el script que generó los certificados.

Mozilla bloqueó los certificados vía OneCRL, Chrome bloqueó los seis intermedios autorizados a emitir certificados TLS y Apple sumó protecciones. Pero el trabajo de limpieza sigue: según la tabla de seguimiento de BleepingComputer, Debian, FreeBSD, Node.js y Bun seguían con actualizaciones pendientes. Y el curl integrado en macOS podría seguir confiando en los certificados comprometidos porque su bundle no verifica revocaciones.

¿Por qué todo esto importa más en la era de la IA?

El hilo que conecta los cuatro incidentes es la velocidad. Wiz encontró los fallos de PHP en parte con IA, y los atacantes pueden usar las mismas herramientas para explotarlos. El consultor de seguridad Lukasz Olejnik resume en Wired que la IA hace que explotar este tipo de vulnerabilidades sea de importancia inmediata, del orden de un minuto.

Para un equipo de seguridad chico —el de la mayoría de las startups— eso significa que la ventana entre que aparece un parche y empiezan los ataques masivos se mide en minutos, no en días. La defensa ya no puede depender de que alguien lea el boletín el lunes.

¿Qué significa esto para tu startup?

Cuatro acciones concretas, en orden de urgencia:

• Inventario de PHP, hoy. Lista cada servicio que sirva tráfico web y corra PHP. Si está en 8.2 o superior, actualiza ya. Si es anterior, no hay mitigación completa: la propia PHP Foundation dice que actualizar es la única opción segura, y la NCSC recomienda sacar el sistema de línea si no puedes parchear. Presta atención especial a plugins y CMS de terceros que arrastran su propia versión de PHP.
• Rota credenciales de IA, no solo las de nube. Si usas LiteLLM —o cualquier gateway de modelos—, asume que las claves que vivían en variables de entorno de esa máquina están expuestas. Rota las API keys de OpenAI, Anthropic y Google, las credenciales de AWS, GCP y Azure, y las claves SSH. El detalle del archivo .pth en el incidente de marzo de 2026 muestra que el código malicioso puede ejecutarse aunque tu app no importe la librería.
• Fija versiones y bloquea la salida de red. Usa lockfiles con versiones exactas y hashes en lugar de rangos, y aplica filtrado de egreso a nivel de workload. En el caso de LiteLLM, el malware exfiltraba datos a un dominio que imitaba la infraestructura legítima del proyecto; sin filtrado de salida, ese tráfico se ve como normal.
• Revisa tus trust stores. Actualiza los paquetes de certificados (ca-certificates, certifi, NSS, Go) y los navegadores de tus equipos. Si tu producto corre en dispositivos o contenedores que no se actualizan solos, ahí es donde el problema de eMudhra va a vivir más tiempo.

Conclusión

Ninguno de estos cuatro incidentes es culpa de una startup. Todos son consecuencia de depender de infraestructura compartida: un lenguaje que sostiene buena parte de la web, un runtime, un proxy de IA y una autoridad certificadora. La lección práctica no es solo parchear más rápido, sino saber qué corre en tu stack y qué credenciales toca. La mayoría de los equipos no puede responder esa pregunta en menos de una hora, y ese es el verdadero riesgo.

Fuentes

• TechCrunch: The internet is having a very bad cybersecurity day (fuente original)
• Wired: Critical PHP Vulnerabilities Are Setting the Internet on Fire
• BleepingComputer: Mozilla, Google, Apple block compromised eMudhra CA certificates
• Mintive: What Happened in the LiteLLM Supply Chain Attack