PHP2Shell, LiteLLM y Railway: tres alertas para revisar la seguridad hoy

En menos de 24 horas han coincidido tres avisos que afectan a capas muy distintas de la tecnología empresarial. PHP2Shell compromete el motor sobre el que funciona una gran parte de las webs, tiendas y aplicaciones. El incidente de LiteLLM 1.107.0 demuestra que un paquete distribuido por canales oficiales también puede llegar manipulado. Y Railway ha comunicado que, según su investigación, un tercero no autorizado pudo acceder a variables de entorno de clientes y obtener el contenido descifrado de algunas. El mensaje común es incómodo, pero útil: la seguridad no se resuelve con una auditoría anual ni con pulsar «actualizar» cuando salta una alerta.

TL;DR

• Si tu web o aplicación sirve peticiones con PHP, comprueba hoy la versión efectiva del runtime. Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
• Actualizar WordPress, Laravel, Symfony, plugins o paquetes Composer no corrige PHP2Shell si el intérprete PHP continúa sin parchear.
• Si tu organización instaló o ejecutó LiteLLM 1.107.0 desde PyPI o utilizó las imágenes públicas afectadas, no basta con cambiar de versión: hay que tratar el entorno como potencialmente comprometido, reconstruirlo y rotar las credenciales accesibles.
• Si utilizas Railway, rota todas las variables de entorno, claves API y credenciales de registros privados almacenadas allí; crea nuevos tokens de Railway y revisa el uso de GitHub, nube, bases de datos y proveedores de modelos.
• La lección para una empresa es operativa: inventario vivo, alertas, responsables, dependencias fijadas, secretos de mínimo privilegio y un procedimiento de respuesta probado.

Actualización editorial: artículo elaborado el 22 de octubre de 2026 con información disponible hasta las 17:00 UTC. Es contenido informativo y defensivo; no sustituye el análisis de tu proveedor de alojamiento, tu equipo de seguridad ni el asesoramiento jurídico sobre una posible brecha de datos.

Qué ha ocurrido entre el 21 y el 22 de octubre

Incidente	Qué se ha confirmado	Qué debe hacer una empresa
PHP2Shell	Dos vulnerabilidades críticas en el núcleo de PHP, CVE-2026-109618 y CVE-2026-109619, con riesgo de ejecución remota de código sin autenticación.	Localizar todos los runtimes PHP web, parchear, reiniciar o redesplegar y revisar señales de actividad desde al menos el 17 de octubre.
LiteLLM 1.107.0	Una versión maliciosa llegó a PyPI y a imágenes públicas de contenedor mediante una canalización oficial manipulada. Buscaba credenciales de nube, desarrollo, navegadores y proveedores de modelos.	Determinar si el artefacto llegó a instalarse o ejecutarse. Si fue así, aislar, reconstruir desde limpio, rotar secretos y revisar su posible uso.
Railway	Railway confirmó actividad anómala en los sistemas que almacenan variables de entorno. Su investigación indica que un tercero pudo acceder a variables cifradas y descifrar algunas.	Rotar todos los secretos guardados en Railway, crear nuevos tokens, revisar registros externos y reconectar o redesplegar las integraciones afectadas.

No son el mismo tipo de fallo. PHP2Shell es una vulnerabilidad del runtime. LiteLLM es un compromiso de la cadena de suministro. Railway es un incidente en una plataforma de despliegue y gestión de secretos. Juntos enseñan por qué una empresa necesita vigilar el software que ejecuta, la forma en que llega a producción y las credenciales que conectan todos sus servicios.

PHP2Shell: el fallo está debajo de WordPress o Laravel

El proyecto PHP publicó el 21 de octubre las correcciones para CVE-2026-109618 y CVE-2026-109619. Ambas vulnerabilidades tienen una puntuación oficial CVSS v4.0 de 9,2 y afectan al manejo de memoria y del estado interno entre peticiones. En determinadas condiciones, una petición creada por un atacante puede terminar ejecutando código con los permisos del proceso web, sin necesidad de iniciar sesión.

La distinción de capas es clave. Tu web puede usar WordPress, WooCommerce, Drupal o Joomla. Tu aplicación puede estar construida con Laravel o Symfony. Pero todas ellas pueden depender de un intérprete PHP instalado en un servidor, una imagen de contenedor, un servicio gestionado o un appliance. La aplicación puede estar al día y la capa inferior seguir expuesta.

PHP incluye en el alcance general las instalaciones que sirven peticiones web mediante PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo demostrado es especialmente alto con Apache y mod_php, donde una de las vías puede activarse antes de que empiece el código de la aplicación. Eso no significa que PHP-FPM sea seguro: una de las vías de la segunda vulnerabilidad también se validó en ese entorno.

Versiones de PHP que corrigen las dos vulnerabilidades

Rama	Primera versión corregida	Decisión práctica
PHP 8.5	8.5.12	Actualizar y reiniciar o redesplegar.
PHP 8.4	8.4.27	Actualizar y reiniciar o redesplegar.
PHP 8.3	8.3.36	Actualizar y reiniciar o redesplegar.
PHP 8.2	8.2.35	Actualizar y planificar la siguiente migración.
PHP 8.1 o anterior	No hay una nueva versión estable oficial equivalente	Comprobar un backport explícito del proveedor o migrar a una rama mantenida.

PHP publicó backports mínimos de código fuente para 7.4, 8.0 y 8.1 como ayuda excepcional. Algunas distribuciones y proveedores LTS pueden ofrecer paquetes propios. No des por hecho que tu servidor antiguo se ha corregido automáticamente: pide al proveedor confirmación expresa para ambas CVE.

WordPress, Laravel y Symfony: qué actualizar de verdad

• WordPress o WooCommerce: WordPress.org ha aclarado que no hace falta una actualización específica de WordPress para estas CVE. Debes comprobar qué versión de PHP sirve realmente la web y pedir confirmación al hosting.
• Laravel: actualizar Composer o el framework no sustituye el parche del runtime. Laravel ha publicado instrucciones distintas para Cloud, Forge y Vapor; algunos entornos requieren actualizar cada servidor y otros, redesplegar.
• Symfony o aplicaciones a medida: la exposición depende del runtime web subyacente, su interfaz, su versión y la corrección aplicada por el proveedor.
• Contenedores: reconstruye la imagen con una base corregida y redespliega. Cambiar un paquete en un host no modifica una imagen antigua que sigue ejecutándose.

Ejemplo ilustrativo, no un caso real: una tienda actualiza WordPress, WooCommerce y todos sus plugins durante la mañana. Sin embargo, el hosting continúa ejecutando PHP 8.2.34. La aplicación está al día, pero el runtime sigue por debajo de la primera versión corregida, 8.2.35. El trabajo no termina hasta verificar la versión que atiende las peticiones después del reinicio o redespliegue.

Estado de la explotación de PHP2Shell

Conviene ser preciso. CISA indicó el 21 de octubre que todavía no había observado explotación en el momento de publicar su alerta. Ese mismo día, AWS informó de un primer intento contra sus sensores el 17 de octubre y de actividad de varios actores entre las 02:00 y las 08:00 UTC del día 21, antes de la publicación oficial de las correcciones. AWS describe ya explotación amplia en Internet contra sus sensores.

Esto justifica tratar la situación como urgente, pero no permite afirmar que cada intento tuvo éxito ni inventar una cifra de empresas afectadas. La formulación prudente es: hay explotación activa observada contra sensores y herramientas públicas en circulación; no se conoce el número fiable de compromisos reales.

Qué hacer hoy con PHP2Shell

1. Haz inventario. Busca PHP en webs públicas, intranets, paneles, contenedores, funciones, herramientas antiguas, appliances y entornos de pruebas expuestos.
2. Prioriza lo accesible desde Internet. Confirma rama, versión, interfaz de servidor y responsable del activo.
3. Actualiza a una versión corregida o al paquete con backport que tu proveedor identifique para las dos CVE.
4. Reinicia todos los trabajadores PHP o reconstruye y redespliega la carga. Instalar el paquete sin sustituir los procesos antiguos no cierra el trabajo.
5. Verifica desde el entorno web. El binario de consola puede no ser el mismo que atiende la web. En WordPress, la ruta habitual es Herramientas › Salud del sitio › Información › Servidor.
6. Revisa actividad histórica desde al menos el 17 de octubre: peticiones multipart anómalas, errores de memoria, reinicios inesperados, trabajadores PHP que lanzan procesos o descargan herramientas y modificaciones de archivos.
7. Si no puedes parchear, aísla. CISA y otros organismos recomiendan desconectar temporalmente los sistemas que no puedan actualizarse, especialmente si usan ramas sin soporte.

Un WAF y los cambios de configuración que recoge el aviso oficial pueden reducir vías concretas durante la ventana de parcheo. No sustituyen la actualización. PHP afirma que la única solución completa es ejecutar una versión que contenga el parche.

LiteLLM: cuando el paquete oficial es el problema

El segundo incidente no nace de un error accidental en una función. El 21 de octubre, atacantes manipularon la canalización de publicación de LiteLLM y distribuyeron la versión 1.107.0 mediante PyPI y varias imágenes públicas de contenedor. Según el informe oficial de LiteLLM, se utilizaron credenciales GitHub CLI OAuth vinculadas a tres cuentas para modificar el flujo, aprobar la publicación y borrar registros.

La versión maliciosa dejaba tres ficheros en la raíz de site-packages. Python puede procesar ese tipo de ficheros automáticamente al arrancar. El resultado es importante: el código podía ejecutarse aunque la aplicación no importase LiteLLM. Quitar únicamente el directorio normal del paquete tampoco garantizaba eliminar esos ficheros.

Los análisis de Datadog Security Labs y Wiz describen un recolector orientado a credenciales de:

• AWS, Azure y Google Cloud.
• Kubernetes, Docker, Vault y Terraform.
• Git, npm, PyPI, SSH, GPG, TLS, ficheros .env e historial de shell.
• Navegadores y sesiones guardadas.
• Proveedores y herramientas de inteligencia artificial, entre ellos claves o sesiones asociadas a OpenAI, Anthropic, Claude, Codex, Gemini, Cursor y Copilot.
• El propio proxy LiteLLM, incluida la base de datos donde podía haber credenciales de proveedores.

El paquete también incluía una capacidad preparada para descargar y ejecutar una segunda fase. Los investigadores consultados no observaron esa segunda carga activa, así que no debe presentarse como ejecutada en todas las víctimas. El robo de credenciales, sin embargo, funcionaba de forma independiente. Wiz observó uso exploratorio de algunas credenciales AWS en entornos concretos, pero esa evidencia no puede generalizarse a todas las instalaciones.

Qué artefactos estuvieron afectados

Canal	Afectado	Ventana comunicada el 21 de octubre
PyPI	litellm==1.107.0	De 11:39 a 13:23 UTC.
Docker Hub público	v1.107.0 y etiquetas móviles latest, main-latest y main-stable	Desde las 11:46 hasta las 14:20 UTC.
GHCR público	Variantes litellm, litellm-database y litellm-non_root	Desde las 11:46 hasta su retirada, verificada a las 13:51 UTC.
Versiones anteriores	El informe oficial no las incluye en este incidente	1.106.2 fue la referencia segura indicada durante la respuesta.
Registro privado Enterprise	No afectado según LiteLLM	Hay que comprobar de qué registro procedía cada despliegue real.

Indicadores defensivos: la presencia de litellm-1.107.0.dist-info, cook.pth, cook.py o sitecustomize.py confirma exposición. En contenedores, LiteLLM identificó como afectado el digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. No encontrar estos indicadores no demuestra que el equipo esté limpio: un contenedor puede haber desaparecido y los registros pueden estar incompletos.

Una cifra de descargas no equivale a víctimas: puede incluir cachés, automatizaciones y descargas que nunca llegaron a instalarse o ejecutarse. La pregunta operativa no es «¿cuántas descargas hubo?», sino «¿algún host nuestro instaló la rueda o arrancó una imagen afectada durante la ventana?».

Actualizar y responder a un compromiso no son lo mismo

Este es el error más peligroso del incidente. Cambiar a una versión segura evita seguir usando la entrega maliciosa, pero no revoca lo que ya pudo copiarse y no garantiza que hayan desaparecido los ficheros añadidos fuera del directorio del paquete.

Actualizar	Responder a un posible compromiso
Fijar una versión limpia y evitar etiquetas móviles.	Aislar los sistemas sospechosos y preservar registros.
Reconstruir la imagen con un artefacto verificado.	Desechar entornos, contenedores o runners potencialmente contaminados.
Bloquear la versión y los artefactos afectados.	Rotar desde un equipo limpio todas las credenciales accesibles.
Comprobar el origen y el digest del nuevo artefacto.	Revisar actividad en nube, identidad, red, CI/CD y repositorios.

Ejemplo ilustrativo, no un caso real: un runner de integración continua utilizaba una etiqueta latest y descargó una imagen afectada. Cambiar después la etiqueta no invalida el token del repositorio, las credenciales cloud o las claves de proveedores que el contenedor pudo leer. La recuperación exige reconstruir el runner, revocar esas credenciales y revisar su uso desde el momento de exposición.

Qué hacer si usaste LiteLLM 1.107.0

1. No empieces ejecutando Python o pip dentro del entorno sospechoso. El mecanismo malicioso podía activarse con el arranque del intérprete. Eso incluye pip show y pip uninstall.
2. Localiza desde fuera los hosts, entornos virtuales, contenedores, nodos y ejecutores de CI que descargaron o ejecutaron el artefacto. Lee como texto los lockfiles y requisitos del repositorio, revisa los logs de CI y del registro y consulta en el orquestador el digest de las imágenes, sin arrancar Python dentro del entorno.
3. Separa descarga de ejecución. Haber descargado un paquete no prueba exfiltración. Si se instaló o se arrancó el contenedor dentro de la ventana y el sistema tenía salida a Internet, sigue la recomendación oficial: da por robadas las credenciales accesibles.
4. Aísla y conserva evidencias. Corta la salida de red, guarda logs, metadatos, snapshots y la cronología antes de limpiar. Puede quedar un proceso Python residente que comprueba cada hora si existe una segunda fase; el cerrojo /tmp/remote_code_loader.lock es un indicador adicional, no una prueba de que el sistema esté limpio si falta.
5. Reconstruye desde cero. Es más fiable que confiar únicamente en borrar tres ficheros.
6. Rota secretos desde una máquina limpia. Incluye identidades cloud, tokens de CI/CD, repositorios, registros, claves de proveedores de modelos, secretos del proxy, SSH y sesiones relevantes.
7. Revisa el uso posterior. Comprueba registros de identidad, nube, facturación de modelos, repositorios y conexiones salientes desde el momento de la instalación.
8. Valora una brecha de datos. Si hubo acceso no autorizado a datos personales, la organización debe evaluar el riesgo y sus obligaciones de documentación, notificación y comunicación.

Railway: las variables de entorno también son un almacén de secretos

El 21 de octubre, Railway comunicó que había detectado actividad anómala en los sistemas que almacenan variables de entorno de clientes. Su investigación indicaba que un tercero no autorizado podía haber accedido a variables cifradas y obtenido el contenido descifrado de algunas. Esas variables suelen contener claves API, contraseñas de bases de datos, credenciales de registros privados, tokens de nube y accesos a proveedores de modelos.

Railway afirmó que el análisis inicial apuntaba a un subconjunto de usuarios, pero recomendó a todos rotar inmediatamente todas las variables de entorno y revisar los registros de los servicios conectados. La empresa relacionó el incidente, todavía bajo investigación, con una serie de ataques dirigidos contra plataformas para llegar a proveedores de inferencia de inteligencia artificial. Esa es una valoración de Railway, no una atribución pública definitiva del atacante ni una cifra confirmada de cuentas afectadas.

Qué hizo Railway durante la respuesta

• Pausó builds y despliegues mientras investigaba, incluidos los entornos Enterprise.
• Invalidó todos los Railway API tokens y los Project Tokens creados antes del incidente. Las integraciones con la API pública o la CLI necesitan tokens nuevos.
• Regeneró las credenciales S3 de los buckets en todos los entornos. Los servicios deben redesplegarse para recoger los nuevos valores.
• Invalidó los tokens de conexión con GitHub que Railway almacenaba y retiró de sus servicios las credenciales de registros de GitHub. El usuario debe reconectar GitHub; además, los tokens de registro antiguos pueden seguir siendo válidos en GitHub hasta que su propietario los revoque.
• Notificó a proveedores externos para que revocasen claves de forma preventiva y anunció que contactaría directamente con las cuentas cuyo alcance pudiera confirmar.

Según la página oficial de estado, a las 17:00 UTC del 22 de octubre la API estaba restaurada y los despliegues Pro y Enterprise funcionaban a velocidad normal. Railway seguía habilitando Hobby, Free y Trial por etapas y todavía no había publicado el informe final del incidente. Si tu plan aún no permite redesplegar, no esperes para contener el riesgo: revoca primero los secretos más sensibles o suspende temporalmente la integración afectada, conserva evidencias y completa la sustitución cuando el despliegue vuelva a estar disponible. Recuperar el servicio no convierte automáticamente en seguras las credenciales antiguas.

Qué debe hacer una empresa que utiliza Railway

1. Haz inventario de todas las variables almacenadas. Incluye variables compartidas, credenciales de registros privados, bases de datos, almacenamiento, correo, GitHub, nube y proveedores de modelos.
2. Rota en el proveedor de origen, no solo en Railway. Crea una clave nueva, actualiza la variable, redespliega y revoca la anterior. Si todavía no puedes redesplegar, prioriza revocar o desactivar el secreto expuesto aunque provoque una interrupción controlada. Cambiar el texto en Railway sin invalidar el secreto antiguo no cierra el acceso.
3. Crea nuevos tokens de Railway. Los tokens anteriores al incidente fueron invalidados; revisa automatizaciones, CLI, CI/CD y webhooks que dependan de ellos.
4. Reconecta GitHub y revisa su seguridad. Railway recomienda comprobar el registro personal, que GitHub conserva durante 90 días, y el registro de auditoría de organizaciones, con 180 días de retención. Revisa también OAuth Apps, GitHub Apps, claves SSH, tokens personales, deploy keys, webhooks y colaboradores. Si descargas imágenes privadas de GitHub Container Registry, revoca además allí el token de registro antiguo.
5. Revisa el uso de cada secreto fuera de Railway. Busca accesos anómalos, consumos inesperados, consultas de base de datos, cambios de infraestructura, descargas de imágenes privadas y gasto irregular en proveedores de modelos. Revisa también el registro de auditoría de Railway y cambios inesperados en variables, servicios o despliegues.
6. Interpreta correctamente los cambios de respuesta. Los reseteos oficiales de buckets y conexiones pueden aparecer en el registro con el actor Railway Staff; contrasta su hora con el aviso antes de confundirlos con acciones del atacante.
7. Conserva evidencias antes de borrar. Exporta los registros disponibles y anota qué clave se sustituyó, cuándo, qué permisos tenía y qué sistemas podían usarla.
8. Reduce el daño futuro. Usa tokens por proyecto y entorno, mínimo privilegio, variables selladas cuando proceda, servicios internos sin dominio público y MFA obligatorio para el equipo.

Ejemplo ilustrativo, no un caso real: una aplicación alojada en Railway guardaba una clave de OpenAI, una URL de PostgreSQL y un token de GitHub en sus variables. Rotar solo la clave de OpenAI deja dos caminos potenciales abiertos. La respuesta completa consiste en cambiar los tres secretos en sus proveedores, redesplegar la aplicación, revocar los valores antiguos y revisar actividad y facturación desde el comienzo de la ventana investigada.

La lección empresarial: seguridad continua, no seguridad de campaña

Estos tres avisos muestran fallos distintos del mismo modelo operativo: no saber con precisión qué se ejecuta, de dónde viene, qué secretos puede leer, quién debe actuar y qué ocurre después de instalar un parche. Una empresa no necesita convertirse en un centro de operaciones de seguridad para mejorar, pero sí necesita un circuito básico que funcione cada semana.

El mínimo viable de seguridad para una pyme

Control	Pregunta que debe poder responder	Evidencia mínima
Inventario	¿Qué software y runtimes tenemos en producción?	Activo, versión, exposición, proveedor y responsable.
Alertas	¿Quién recibe avisos de PHP, hosting, paquetes, nube y herramientas de IA?	Canales oficiales, boletines y una bandeja con propietario.
Priorización	¿Qué parcheamos primero?	Exposición a Internet, impacto, explotación observada y criticidad del servicio.
Cadena de suministro	¿Podemos saber qué artefacto exacto se desplegó?	Versiones fijadas, lockfiles, digest de imágenes y registro de despliegues.
Secretos	¿Qué puede leer cada proceso si cae?	Mínimo privilegio, gestor de secretos, caducidad y rotación ensayada.
Respuesta	¿Actualizar basta o debemos investigar?	Guía de contención, preservación, reconstrucción y notificación.

INCIBE recomienda mantener un inventario de software y firmware y seguir los avisos de fabricantes y organismos. Es un consejo sencillo que suele fallar en los detalles: webs antiguas sin propietario, contenedores que no se reconstruyen, etiquetas latest, servidores gestionados que nadie verifica y claves con más permisos de los necesarios.

El origen inicial del incidente de LiteLLM seguía en investigación al cierre de este artículo, pero la organización describió una cadena probable especialmente relevante para cualquier empresa que use herramientas de inteligencia artificial: un despliegue interno de LiteLLM expuesto a Internet, respuestas registradas que podían contener tokens OAuth de GitHub CLI y el salto posterior desde esos secretos al flujo de publicación. La lección no es culpar a una herramienta concreta, sino tratar las pasarelas de modelos, sus registros y los tokens de desarrollo como activos de alto riesgo: no deben estar abiertos a Internet sin necesidad, deben aplicar mínimo privilegio y sus logs no deben conservar secretos.

Si necesitas ordenar ese mapa antes de automatizar más procesos, una consultoría de inteligencia artificial para empresas debe empezar precisamente por arquitectura, datos, permisos, proveedores y responsables. Y si estás conectando CRM, correo, modelos y herramientas internas, el diseño de las automatizaciones con inteligencia artificial tiene que incluir trazabilidad, gestión de secretos, límites de acceso y un plan de mantenimiento. Este enfoque conecta con nuestro análisis sobre gobierno y seguridad de la inteligencia artificial en empresas: tener un panel de control no equivale a controlar la arquitectura real.

Plan de acción para las próximas 24 horas

• Dirección: nombra una persona responsable, evita mensajes ambiguos y autoriza la interrupción temporal de un servicio si no puede parchearse con seguridad.
• Equipo técnico: inventaría, parchea, reinicia o redespliega, verifica la versión efectiva y conserva pruebas.
• Equipos de IA y desarrollo: comprueba si LiteLLM 1.107.0 o sus imágenes públicas afectadas entraron en portátiles, CI/CD, Kubernetes o producción.
• Usuarios de Railway: inventaría y rota todos los secretos almacenados en variables, crea nuevos tokens de la plataforma, redespliega con las credenciales nuevas y revisa la actividad de cada servicio externo conectado.
• Responsable de protección de datos: participa si hay indicios de acceso a datos personales. La AEPD recuerda que las brechas deben documentarse y que el RGPD fija, cuando sea probable un riesgo para las personas, la notificación sin dilación indebida y dentro de las 72 horas desde que se tiene constancia. La herramienta Asesora Brecha ayuda a valorar esa obligación, pero no sustituye la decisión del responsable.
• Proveedores: pide respuestas concretas: versión anterior, versión actual, momento del cambio, necesidad de reinicio o redespliegue y revisión de actividad previa.
• Si no tienes equipo especializado: la Línea de Ayuda en Ciberseguridad 017 de INCIBE ofrece orientación a empresas y ciudadanía.

Preguntas frecuentes

¿Mi web WordPress está afectada por PHP2Shell?

Puede estar expuesta si las peticiones se sirven con una versión PHP sin corregir. No basta con mirar la versión de WordPress o de sus plugins. Comprueba el runtime PHP efectivo en la salud del sitio o con tu proveedor de alojamiento y confirma que incorpora el parche para las dos CVE.

¿Actualizar Laravel o Symfony corrige PHP2Shell?

No. Estas vulnerabilidades están en el motor PHP. Mantener el framework y sus dependencias al día sigue siendo necesario, pero la corrección urgente consiste en actualizar el runtime, reiniciar los trabajadores o reconstruir y redesplegar la carga.

¿Un WAF me protege sin actualizar PHP?

Puede reducir algunas vías de ataque durante una ventana corta de mantenimiento, pero no elimina el defecto de memoria del runtime. PHP, CISA y los proveedores citados recomiendan parchear; si no es posible, aislar o detener temporalmente el sistema es más prudente que tratar el WAF como solución definitiva.

¿Basta con desinstalar LiteLLM 1.107.0?

No, si llegó a instalarse y ejecutarse. No uses pip uninstall, pip show ni Python dentro del entorno sospechoso: arrancar el intérprete podía volver a ejecutar el código. El paquete añadía ficheros fuera de su directorio normal y podía haber copiado credenciales. La respuesta prudente es aislar, inspeccionar desde fuera, reconstruir desde limpio, rotar secretos y revisar su utilización posterior.

¿Qué tengo que cambiar si uso Railway?

Rota todos los secretos almacenados en variables de entorno, no solo los tokens de Railway. Crea las credenciales nuevas en cada proveedor, actualízalas en Railway, redespliega y revoca las antiguas. También debes crear nuevos tokens de Railway, reconectar GitHub cuando proceda y revisar los registros de los servicios conectados.

¿Tengo que notificar a la AEPD?

No toda vulnerabilidad es automáticamente una brecha de datos personales. Si existen indicios de acceso, pérdida, alteración o divulgación no autorizada de datos, el responsable debe evaluar el riesgo, documentar el incidente y aplicar las obligaciones del RGPD. Cuando sea probable un riesgo para las personas, el RGPD fija un plazo de 72 horas desde que la organización tiene constancia.

Fuentes: PHP Security Advisory; GHSA de CVE-2026-109618; GHSA de CVE-2026-109619; CISA; AWS Threat Intelligence; WordPress.org; Laravel; LiteLLM; Datadog Security Labs; Wiz Research; Railway: aviso inicial; Railway: estado del incidente; Railway: credenciales y GitHub; Railway: revisión de GitHub; INCIBE; AEPD.

Nota de autoría: artículo preparado por Lia, sistema de inteligencia artificial de Aimoova, con investigación de fuentes primarias, verificación técnica y supervisión humana antes de su publicación.

Si tu empresa está conectando modelos, datos y procesos sin un mapa claro de permisos y riesgos, empieza por el Diagnóstico de IA gratuito (2-3 min).