PHP, LiteLLM y Railway: qué pasó y cómo proteger tus proyectos de IA
En este artículo
Si tu proyecto usa PHP, LiteLLM o Railway, la respuesta no es simplemente «actualizá todo»: primero identificá qué usaste y qué pudo quedar expuesto. Un fallo del servidor requiere un parche; una credencial filtrada requiere revocación; un entorno que ejecutó código malicioso puede necesitar reconstrucción desde una base confiable. Una medida no reemplaza a las otras.
Los avisos de estos días describen problemas distintos. No hay evidencia suficiente para presentarlos como una única campaña coordinada. Esta nota reúne fuentes oficiales consultadas al 26 de octubre de 2026; el informe de Railway sigue siendo preliminar. Es orientación para decidir con tu equipo, no una auditoría de tus sistemas ni una receta de limpieza universal.
Tres incidentes, tres puertas de entrada
Pensalo como un edificio: reparar una cerradura defectuosa, invalidar una llave copiada y revisar una habitación donde entró alguien son trabajos diferentes. En software, esas diferencias cambian qué hacer primero.
| Caso | Qué se informó | Qué decisión exige |
|---|---|---|
| PHP | Vulnerabilidades que permiten ejecución remota de código sin autenticación | Confirmar exposición y aplicar la corrección pertinente |
| LiteLLM | Artefactos de distribución con código malicioso | Identificar lo descargado y ejecutado; contener y evaluar reconstrucción |
| Railway | Acceso a sistemas internos y posible exposición de variables de entorno | Seguir el aviso del proveedor y revocar credenciales sensibles |
Una variable de entorno puede guardar una clave de API, una contraseña de base de datos o un token de despliegue. Por eso el impacto puede alcanzar otros servicios, aunque la aplicación siga funcionando.
PHP: actualizar sí, pero siguiendo el aviso completo
El aviso oficial de PHP del 21 de octubre anunció correcciones en 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para CVE-2026-109618 y CVE-2026-109619. Los problemas involucran corrupción de memoria ante agotamiento de memoria y estado global obsoleto; permiten ejecución remota de código sin autenticación.
PHP considera en riesgo las instalaciones que atienden solicitudes web. El mayor riesgo demostrado corresponde a mod_php, una forma de ejecutar PHP dentro de Apache. Eso no permite descartar otros despliegues sin revisarlos.
El parche del 21 importa, pero no es el último dato disponible. En la misma página, el aviso del 23 describe otro vector poco probable, CVE-2026-115560, bajo una configuración inusual: cambiar durante la ejecución session.serialize_handler de php_binary o php_serialize a php, antes de session_start, con seguimiento de subida habilitado.
Para ese caso, PHP sugiere session.upload_progress.enabled=0 hasta la siguiente versión regular de correcciones. Coordiná la aplicación de esa orientación con quien administra el servidor: no significa que todos los usuarios parcheados estén expuestos de la misma manera ni que las correcciones anteriores no sirvan.
Si tu hosting o distribución mantiene PHP, verificá su aviso específico. Puede haber incorporado el parche a una versión anterior mediante un backport: el número de versión de upstream, por sí solo, no alcanza para juzgar ese paquete.
Actualizar cierra vulnerabilidades conocidas. No demuestra que antes no hubo una intrusión, ni elimina automáticamente accesos o archivos que un atacante pudiera haber dejado.
LiteLLM: el riesgo estaba en lo distribuido, no en el tag oficial
LiteLLM permite conectar aplicaciones con distintos proveedores de modelos y operar un proxy entre ellas y sus APIs. En este caso, el problema no fue una respuesta del modelo: fue código malicioso dentro de artefactos publicados.
Según el aviso de LiteLLM, los paquetes wheel de litellm==1.107.0 estuvieron comprometidos en PyPI el 21 de octubre, entre 11:39 y 13:23 UTC. En Docker Hub, los tags v1.107.0, latest, main-latest y main-stable estuvieron afectados entre 11:46 y 14:20 UTC. GHCR tuvo una ventana diferente; los artefactos afectados quedaron inaccesibles allí antes de las 13:51 UTC.
Los artefactos maliciosos fueron retirados. El tag de código fuente oficial no contenía el malware: las distribuciones se construyeron desde un fork del atacante. Revisar solamente ese tag no permite certificar lo que se instaló.
Las ventanas de publicación ayudan a investigar descargas, pero no son una frontera automática de seguridad. Un paquete o una imagen descargados entonces pueden quedar en caché y ejecutarse después.
Hay una precaución especialmente importante: el incidente incluyó hooks llamados cook.pth y sitecustomize.py, capaces de volver a ejecutar código al iniciar Python, incluso al usar pip. Si sospechás contaminación, no abras ese entorno ni ejecutes Python o pip para «ver qué pasa» o desinstalar por tu cuenta. Podrías reactivar el payload.
La respuesta debe contemplar contención, preservación de evidencia y reconstrucción de imágenes o entornos virtuales desde una base limpia y artefactos verificados. Desinstalar no equivale a limpiar; no encontrar esos nombres tampoco demuestra ausencia de compromiso.
La cadena empezó con una clave que siguió siendo válida
El postmortem canónico de LiteLLM, publicado el 23 de octubre, corrige supuestos iniciales. Describe una clave maestra subida por error a un repositorio público el 27 de mayo. El commit se sobrescribió, pero la clave no se revocó.
Según esa reconstrucción, el atacante la usó el 10 de octubre para acceder a una plataforma experimental de agentes. Desde allí obtuvo un token OAuth de GitHub CLI con privilegios de propietario de organización y extrajo otros dos tokens de mantenedores mediante workflows de integración continua: procesos automatizados que prueban o publican software.
El 21 de octubre, ese acceso permitió eludir protecciones de ramas y cambiar el workflow de publicación para usar el fork Berri-AI/litellm, en lugar de BerriAI/litellm.
No es correcto resumirlo como tres contraseñas de GitHub hackeadas por separado. Tampoco afirmar que activar doble factor habría detenido por sí solo tokens ya autenticados. La lección concreta es otra: borrar un secreto de Git no lo revoca. Hay que invalidarlo en el servicio que lo acepta.
Railway: que tu aplicación siga online no descarta exposición
El informe preliminar de Railway del 22 de octubre sitúa el ataque entre el 20 de octubre a las 13:58 UTC y el 22 a las 03:32 UTC. La investigación seguía abierta al corte de esta nota.
Railway informó acceso a sistemas internos, obtención de algunas variables de entorno cifradas y descifrado de un subconjunto mediante credenciales comprometidas de integración continua. Recomendó a todos sus usuarios revocar y volver a configurar las variables sensibles almacenadas antes del 21 de octubre.
Los despliegues en ejecución siguieron online, mientras hubo interrupciones en builds, despliegues, API y CLI. Según el proveedor, no se inició sesión en cuentas individuales; el acceso a código fuente todavía no estaba descartado. No corresponde convertir esos datos en «todas las cuentas fueron hackeadas» ni en «no pasó nada».
Una clave revocada por precaución no prueba por sí sola que fue robada. Del mismo modo, Railway atribuye al atacante interés en claves de IA para destilación y uso de modelos modificados: son evaluaciones del proveedor, no conclusiones independientes ni prueba de coordinación con los otros casos.
Qué hacer según tu exposición
No necesitás tratar cada aviso como una intrusión confirmada. Sí necesitás distinguir desconocimiento, exposición posible y señales de compromiso.
- Identificá dependencias y responsables. Pedí versiones, origen de paquetes e imágenes, fechas de descarga o despliegue y avisos del hosting. Si no sos quien administra el sistema, trasladá esas preguntas al responsable; no pruebes comandos encontrados en redes.
- Si solo hay una vulnerabilidad aplicable y no hay indicios de intrusión, priorizá el parche o mitigación oficial, con prueba y plan de recuperación acordes al servicio. No borres infraestructura por reflejo.
- Si pudo ejecutarse un artefacto malicioso o aparecen accesos anómalos, coordiná el aislamiento del entorno y la restricción de accesos. Preservá registros, identificadores de artefactos y cronología antes de modificar o reconstruir. No publiques logs que contengan secretos.
- Después de contener, gestioná credenciales desde un entorno limpio y confiable. Revocá las anteriores y generá reemplazos con permisos mínimos. En LiteLLM, considerá todos los secretos alcanzables desde el host, incluidas claves de proveedores guardadas en la base del proxy y credenciales de identidad y acceso —IAM—, no solo una API key visible.
- Revisá alcance y recuperación. Comprobá permisos, sesiones, accesos y consumo de APIs; reconstruí donde corresponda y validá el servicio antes de reconectarlo. Con credenciales administrativas, datos sensibles o alcance incierto, buscá ayuda de respuesta a incidentes.
No cargues claves nuevas en un host que todavía puede estar comprometido. Rotar credenciales y revisar actividad reduce riesgos y aporta evidencia, pero no prueba que no hubo robo de datos.
Node.js, GitLab y eMudhra: contexto, no un mismo diagnóstico
También hubo avisos relevantes fuera de esos tres casos. Node.js publicó correcciones en 26.12.1, 24.22.1 y 22.23.4. El fallo de Brotli en node:zlib puede permitir ejecución de código si la aplicación descomprime entradas maliciosas. No significa que cualquier sitio Node sea explotable remotamente de inmediato.
GitLab corrigió una vulnerabilidad crítica de ejecución remota sin autenticación bajo ciertas condiciones. GitLab.com ya estaba parcheado; las instalaciones autogestionadas afectadas necesitan actualizar por una ruta soportada, contemplando migraciones y posibles interrupciones, no saltando versiones a ciegas.
eMudhra informó claves débiles en ocho autoridades certificadoras intermedias TLS, reportadas el 17 y revocadas el 18 de octubre. La empresa afirma que esas intermedias no emitieron certificados y niega intrusión o robo de datos; la causa exacta no estaba confirmada. El caso incluyó desconfianza de su raíz por programas de navegadores: no demuestra que «todo HTTPS está roto».
La prevención útil empieza antes del próximo aviso
Fijar versiones reduce cambios involuntarios, pero una versión fijada no demuestra que sea segura. Conviene registrar también procedencia, artefactos y cuándo se incorporaron, junto con responsables de actualización y revocación.
Separar credenciales de desarrollo y producción, limitar permisos y observar accesos o consumo ayuda a reducir el alcance de un incidente. La nota sobre límites y permisos para agentes de IA desarrolla esa prevención; acá el foco es qué cambia cuando una dependencia o un proveedor ya reportó un problema.
Como próximo paso, dejá por escrito con tu equipo: qué dependencias están afectadas, qué secretos podrían quedar alcanzados y quién puede contener, revocar y reconstruir. Ese mapa sirve más que una actualización masiva sin saber qué estás intentando resolver.
Especialista en Agentes de IA · Copenhague
Diseño e implemento agentes IA, MCP servers y harnesses en producción: el loop, las herramientas y el contexto que hacen que un modelo pase de contestar a trabajar. Todo lo que ves en este sitio está construido así.
