LLMjacking: te roban las claves de tus modelos de IA y la factura de un millón de dólares la pagas tú

Hay una factura que llega sin aviso. Una empresa que usa modelos de IA en producción revisa el detalle de su consumo y descubre que en un solo día el gasto ha superado los cien mil dólares. No ha lanzado ninguna campaña nueva, no ha renovado ningún contrato y no ha sufrido una fuga de datos. Lo que ha pasado es que alguien ha usado sus claves para consumir sus modelos, y esa factura le toca pagarla a ella.

Google Threat Intelligence y Mandiant publicaron el 2 de noviembre un informe sobre ese fenómeno, al que llaman LLMjacking. El nombre es casi la mitad de la historia: es el criptojacking de siempre, usar recursos ajenos para extraer valor, pero aplicado a los modelos de lenguaje, con una diferencia esencial. El criptojacking consume CPU de forma lenta y constante; el LLMjacking dispara la factura en horas. En los incidentes que investigó Mandiant hubo consumos fraudulentos superiores a 100.000 dólares en un único día, y en algunas organizaciones la factura acumulada llegó al millón antes de que nadie revocara el acceso.

Los afectados están repartidos por varios países y sectores: servicios financieros, comercio minorista, tecnología y transporte, en Norteamérica, Sudamérica y la región Asia-Pacífico. No es un problema de una plataforma concreta, el informe habla de varios proveedores de nube y de varios proveedores de modelos.

El dato más incómodo del informe no es la cantidad de dólares, sino la cadena que hay detrás. Para llegar a tu cuenta no hace falta explotar el modelo ni encontrar una vulnerabilidad en el proveedor: hace falta una credencial, y las credenciales están por todas partes, desde un repositorio público hasta una variable de configuración olvidada en un contenedor. Lo que sigue es el recorrido completo de uno de estos casos: por dónde entraron, cómo se movieron por dentro, cómo lo convirtieron en un negocio y qué queda después de que se apagó la luz.

Qué es el LLMjacking y en qué se diferencia del criptojacking

El LLMjacking es el secuestro del acceso a un modelo de lenguaje. En lugar de minar criptomoneda con la CPU de tu servidor, el atacante consume tokens con tu clave y te pasa la factura.

El informe de Mandiant distingue dos extremos. En el extremo bajo está el robo de recursos mediante la manipulación de los chatbots de atención al cliente: se los usa para que generen código en nombre del cliente. En el otro extremo, que es el que describe el informe, el atacante va directo a los recursos del modelo y se salta los interfaces: busca puntos de acceso publicados a la intemperie o consigue claves de API válidas.

Hay una imagen en el informe que resume ese segundo extremo. Un actor de amenaza prueba endpoints de Ollama publicados accidentalmente en Internet y llama al endpoint `/api/create` para registrar sus propios modelos en la máquina de la víctima. No le pide al modelo que haga nada: directamente monta su servicio sobre una máquina que alguien ha dejado abierta. Dejar sin proteger un servicio de inferencia no solo amplía la superficie de ataque tradicional, dice el informe, también puede disparar los costes de alojamiento de quien lo dejó abierto.

La puerta de entrada ya no es la contraseña, son los tokens

En las investigaciones de LLMjacking, el vector de acceso inicial dominante no es el robo de una contraseña, es la exposición o el robo de un token de identidad en la nube. El informe enumera las credenciales de IAM, las claves de cuentas de servicio, los tokens de acceso personal de GitHub y los tokens de sesión activos. Son credenciales que no caducan, que no se pueden cambiar desde el móvil y que no disparan el aviso de inicio de sesión desde un dispositivo nuevo.

El caso de UNC6993, uno de los grupos más activos del informe, es ilustrativo. A mediados de 2026 el grupo entró en una instancia de nube mediante una clave de cuenta de servicio mal configurada y, con ese acceso, consiguió permisos sobre una API de modelos. Después montó una página de secuestro de sesión que se hacía pasar por un portal de aplicaciones y que invitaba a unirse a un grupo de usuarios de LLM. La página indicaba al visitante que navegara hasta el sitio legítimo del proveedor de modelos y pegara allí su payload JSON en crudo, que contenía un token de sesión activo. Ese payload se enviaba después a la API interna del servicio y con él se pasaban por alto tanto la contraseña como el segundo factor.

El detalle técnico de ese caso merece atención, porque explica por qué el segundo factor no sirve de nada en este escenario. El atacante no necesita tu contraseña: necesita el token de portador que tu navegador ya tenía en la sesión. El MFA protege el proceso de autenticación, pero una sesión ya autenticada lleva consigo una credencial que el MFA no puede revocar.

En otras intrusiones del informe el camino es distinto pero llega al mismo sitio. Un actor combinó un token de acceso personal de GitHub robado para entrar en repositorios privados con la explotación de una vulnerabilidad de aplicación web sospechada en un paquete que corría dentro de un entorno de nube contenedorizado. Otro usó credenciales de IAM de empleados de la empresa, con tokens de federación de nube, para generar de forma programática claves de acceso nuevas y esquivar el MFA. Un tercero entró con una clave de cuenta de servicio con permisos amplios sobre el proyecto.

La validación silenciosa: por qué no viste nada

El detalle más útil para un equipo de detección está en una frase del informe. Un grupo que cosechó claves de API corporativas expuestas en repositorios públicos de GitHub ejecutó barridos automatizados de validación de credenciales usando peticiones mínimas de un solo token, con `max_tokens=1`. Eso, según Google, permitió confirmar la viabilidad de las claves robadas sin ser detectado por las alertas de anomalía de volumen del EDR ni del SIEM de la víctima.

Es decir: el atacante no atacó el sistema de monitorización, lo esquivó por el tamaño de la petición. Una llamada de un token no genera volumen, no consume cuota de forma apreciable y no se parece en nada a la avalancha de peticiones que dispara un fraude de inferencia a gran escala. Quien vigila el consumo mirando el pico no ve nada, porque el pico todavía no ha llegado.

Ese mismo grupo, una vez dentro, amplió el trabajo con dos técnicas adicionales. Uno se suscribió a las cuentas de las víctimas a acuerdos de pago por uso, eligiendo modelos fundacionales de gama alta y lanzando flujos de inferencia de alto volumen. Otro aplicó una estrategia de quemar y rotar, creando y eliminando continuamente cuentas de servicio de vida corta para saltarse los límites de tasa, mientras revisaba la interfaz de facturación del proveedor de nube para medir el impacto financiero de lo que estaba haciendo. Es un detalle revelador: el atacante controla la cuenta de facturación de la víctima y la usa como su propio panel de control.

De una clave robada a un parque de máquinas

Conseguir una clave de modelo es el principio. Lo que viene después es un trabajo de catálogo, y el informe lo describe con detalle.

Los actores enumeraron servicios de nube, repositorios de código y almacenes de datos en busca de credenciales sensibles. En una intrusión hicieron reconocimiento interno a través de varias regiones de nube para mapear los servicios disponibles y las políticas de identidad. En otra, una vez dentro de un entorno contenedorizado, clonaron repositorios sensibles para buscar secretos escritos a mano, variables de configuración y credenciales de desarrollador. También escanearon registros de acceso para encontrar credenciales de entornos secundarios y ejecutaron consultas dirigidas contra bases de datos: en un caso consultaron las tablas de metadatos de un almacén de datos de nube en busca de credenciales, contraseñas de administrador y columnas sensibles, además de realizar operaciones de almacenamiento de objetos vinculadas al robo de datos.

La escalada se apoyó en los permisos de identidad. Un actor usó los privilegios de creación de tokens asociados a cuentas de servicio comprometidas para generar credenciales temporales de cuentas de servicio de alto privilegio, lo que permitió exfiltrar credenciales de infraestructura, contraseñas internas de base de datos y claves de API de terceros desde el gestor de secretos de la nube. La persistencia se instaló por vías discretas: crear cuentas de IAM no autorizadas, asociar políticas administrativas a roles de servicio, abrir sesiones de gestión interactivas en máquinas virtuales en marcha para inyectar claves públicas SSH en los ficheros de configuración del host y crear cuentas de servicio encubiertas como supuestas utilidades internas de optimización de la facturación. También se inyectaron claves SSH de ámbito de proyecto en los metadatos de las instancias.

Ese último detalle merece una línea aparte, porque es el tipo de nombre que aparece en inventarios de cuentas de servicio y en facturas de proveedor y que nadie cuestiona. Una cuenta de servicio que se llama como una utilidad interna de optimización de la facturación no es una cuenta de servicio: es una puerta trasera con nombre de empresa.

La infraestructura de la monetización: los LLM Mixers

El cambio más interesante del informe no está en el ataque, sino en el negocio. A medida que el ecosistema LLMjacking madura, Google ha observado una división del trabajo entre los que establecen el acceso inicial y los que gestionan la infraestructura de monetización. Estos últimos son los LLM Mixers: pasarelas de enrutamiento ilegales que hacen de proxy, agregan y revenden acceso no autorizado a modelos para suscriptores del mercado clandestino.

Las herramientas que usan son de código abierto y bien conocidas. El grupo UNC6993 empleó new-api, un concentrador centralizado de modelos y pasarela, y gcli2api, un proxy que convierte herramientas de línea de comandos en endpoints estándar de modelos frontera. La función de esas dos piezas es evidente: reunir las claves robadas en un fondo común y repartir la carga entre cuentas para que ninguna salte y para que el consumo parezca repartido.

Otros actores montaron infraestructura propia de retransmisión, con dominios que imitan al host interno legítimo de la víctima, para derivar el acceso comercial de alto valor hacia el ecosistema de reventa newapi.pro. Y otro levantó pasarelas LiteLLM en servidores externos para gestionar y enrutar el tráfico de las API.

El nivel de sofisticación sube en un caso concreto. Un actor habilitó agentes, desplegó proxies inversos accesibles públicamente y construyó conjuntos de proxy en Node.js que exponían endpoints compatibles con varios modelos frontera, todo rebrandeado bajo una persona ficticia llamada D1337-KAIROS. Instaló en el entorno de nube comprometido una puerta trasera contenedorizada construida sobre el marco de agentes Manus, que consultaba a un modelo en la nube para razonar sobre las instrucciones y ejecutar localmente los comandos resultantes, apoyándose en el metabuscador SearXNG y en entornos de ejecución de agent-infra/sandbox. Para escalar, aprovisionó instancias con GPU potente, intentó levantar hardware de gama alta en varias regiones y pidió aumentos de cuota a través de la API del proveedor de nube.

Conviene ver este nivel de detalle en su contexto. Nada de eso es una automatización de IA que decida atacar por su cuenta: es una persona, o un equipo pequeño, usando software publicado en GitHub para montar una operación de infraestructura. La IA aparece en el centro como el recurso que se monetiza y como la herramienta que ejecuta comandos, no como el atacante.

Jet Night: sesenta dólares al mes y un millón de tu bolsillo

La parte del informe que mejor ilustra la economía del LLMjacking es la de un servicio concreto con nombre propio: Jet Night.

Google describe un actor que ejecutó más de 500.000 llamadas a la API de modelos en menos de ocho horas, usando claves de API de terceros robadas para alimentar un servicio de enrutamiento de tokens en el dominio jet-night.com. El coste de tokens que el servicio llegó a pasarle a la organización víctima se acercaba al millón de dólares.

La estructura de precios del servicio es lo que lo delata. Jet Night ofrecía un plan de tokens ilimitados por unos 60 dólares al mes con acceso alegado a modelos frontera, mientras que un servicio de ese nivel de consumo en el mercado se movería entre 100 y 250 dólares mensuales. Google razona que un servicio que vende por debajo del mercado solo es rentable si el coste lo está pagando otro, y ese otro es la víctima a la que le robaron las claves.

Hay más detalles que encajan. El servicio había anunciado en su canal público de Telegram varias interrupciones, y la explicación más probable es que las claves robadas se estaban revocando a medida que las víctimas descubrían el compromiso. Los indicadores de compromiso que publica el propio informe son escuetos: dos dominios, jet-night.com y newapi.pro, catalogados como indicadores de red de un LLM Mixer.

El puente: de una clave virtual a PROXY_ADMIN

Dentro de la cadena hay un eslabón que merece un apartado propio, porque muestra cómo una operación de robo de recursos se convierte en un control total del entorno.

Tras obtener las claves virtuales, un grupo distinto del que estableciera el acceso inicial ejecutó explotación dirigida contra la pasarela de enrutamiento de modelos de la víctima. El informe de Google describe el fallo como una vulnerabilidad de reasignación de identificador de usuario en el endpoint `/key/regenerate` de LiteLLM, que permitió elevar claves virtuales normales a credenciales administrativas maestras PROXY_ADMIN.

Conviene detenerse aquí, porque hay una discrepancia entre fuentes que conviene señalar en lugar de propagar. La investigación primaria de Obsidian Security sobre LiteLLM, publicada meses antes y con el código a la vista, numera el conjunto de fallos de otra manera. Su análisis, con una puntuación CVSS de 9,9 para la cadena completa, identifica tres identificadores: CVE-2026-47101, un bypass de autorización por un campo de rutas permitidas que el proxy guarda tal cual, de modo que un usuario con el rol mínimo puede acuñar una clave con acceso a rutas que su rol nunca debería alcanzar; CVE-2026-47102, una escalada de privilegios por una autorización de campo ausente en los endpoints de actualización de usuario, que permite promoverse a `proxy_admin`; y CVE-2026-40217, una evasión del aislamiento en el guardarraíl de código personalizado, donde los endpoints ejecutan código de usuario con exec() y dejan disponibles los objetos predefinidos de Python.

Es decir, el comportamiento que Google describe como CVE-2026-40217 se corresponde, en la numeración de Obsidian, con los dos primeros fallos de la cadena, mientras que ese identificador corresponde allí a la fuga del aislamiento del guardarraíl. El mecanismo que se describe, elevar una clave virtual normal hasta PROXY_ADMIN, es el mismo en ambas fuentes; la etiqueta no. Lo que no cambia en ninguna de las dos lecturas es el consejo: hay que actualizar la pasarela.

La investigación de Obsidian también explica por qué una pasarela de modelos es un objetivo mucho más interesante de lo que parece. Si LiteLLM está desplegado, el alcance de un compromiso no es el modelo: es la clave maestra del proxy, la clave de sal que permite descifrar las credenciales guardadas en la base de datos, la cadena de conexión a esa base de datos, todas las claves de cada proveedor configurado, las credenciales de MCP y de los agentes que pasan por ahí, y el contenido de las conversaciones. Y hay algo peor que leer: la pasarela está entre el agente y el modelo, de modo que quien la controla puede alterar las respuestas en tránsito, reescribir lo que el agente ve y desviar su ejecución hacia las herramientas que ese agente tiene permitidas. Como resume el informe, la pasarela deja de ser fontanería y pasa a ser el volante del agente.

Obsidian comunicó los hallazgos a BerriAI en febrero de 2026 y la casa publicó las correcciones en varias versiones consecutivas, con el conjunto completo en LiteLLM v1.83.14-stable, publicada el 25 de abril de 2026. Actualizar a esa versión o posterior cierra la cadena entera. Hay un matiz que el informe recoge: antes de la 1.82.0-stable, encadenar el bypass de rutas con la fuga del guardarraíl bastaba para que un usuario interno alcanzara ejecución de código en el host sin necesidad de nada más. A partir de esa versión había que ganar primero el rol de administrador.

La otra puerta: el CLI legítimo reconvertido en conducto

La historia del LLMjacking no termina en el robo de claves. En paralelo, Broadcom, a través de Symantec, publicó un informe sobre un servicio de retransmisión no autorizado que reparte acceso a los asistentes de programación de OpenAI y Anthropic de una forma que merece atención.

El método es limpio. El servicio instala el cliente legítimo: npm install -g @openai/codex o npm install -g @anthropic-ai/claude-code, la instalación oficial, la de verdad. Poco después, el usuario ejecuta una línea que el servicio le ha dado, del tipo iwr -useb más una tubería hacia iex en PowerShell, o un curl con tubería hacia bash en Linux. Ese comando descarga un script de configuración sin archivo desde un dominio que imita al oficial, y el script comprueba si Node.js y el cliente están instalados, los instala en silencio si no lo están y aplica su propia configuración.

La reescritura de la configuración es el corazón del asunto. El script modifica el fichero de configuración de Codex o el de Claude Code, sustituye la URL base por un dominio que controla el servicio, cambia la clave real del usuario por una clave emitida por el retransmisor y fija ambas como variables de entorno de ámbito de usuario para que el cambio sobreviva a un reinicio. Después desactiva el aislamiento de ejecución, con el modo sandbox puesto en danger-full-access, habilita el acceso a la red en el modo de escritura y desactiva la telemetría y el informe de errores, lo que además silencia cualquier señal de uso que pudiera llegar a OpenAI o a Anthropic.

En una de las máquinas, el script fue más allá: cerró la sesión legítima de Anthropic con claude /logout, borró las variables de autenticación y volvió a iniciar sesión con claude /login, de modo que la sesión real del usuario no pudiera validar las credenciales del retransmisor. En varios equipos, el script consultaba la configuración regional de Windows nada más instalarse, lo que encaja con un servicio que quiere confirmar que se está ejecutando en la región a la que da servicio.

El alcance que describe Symantec es concreto: alrededor de una docena de organizaciones, en su mayoría en China continental y también en filiales de multinacionales con base en Corea del Sur, Taiwan y Malasia, en sectores como automatización industrial, fabricación de electrónica, semiconductores, farmacéutica, transporte, fabricación de neumáticos, petroquímica y servicios de centro de datos. La infraestructura del servicio giró entre al menos ocho dominios, todos imitando servicios de chat de OpenAI o Anthropic.

Dos matices. El primero: no se ha observado que el operador esté explotando su posición. No hay evidencia de que robe los prompts, de que fabrique respuestas o de que redirija el código de los usuarios. El segundo: las claves que emite el servicio tienen el prefijo sk-ant-oat01-, el que Anthropic usa para tokens OAuth de suscripción, y no sk-ant-api03-, el de las claves de pago por uso. Symantec lo señala como consistente, sin prueba concluyente, con que el servicio esté reuniendo suscripciones de tarifa plana y repartiendo la capacidad entre muchos clientes.

El informe de Symantec es explícito en un punto que conviene no suavizar: esto no es una vulnerabilidad de Codex ni de Claude Code. Las herramientas se comportan como fueron diseñadas una vez que su configuración ha cambiado. El peligro no está en el binario que el usuario instala, sino en el fichero de configuración que alguien modifica después.

La ausencia de evidencia de abuso, además, no es evidencia de ausencia de riesgo. En esa posición, el retransmisor ve cada prompt, cada fichero y cada secreto que el empleado envía al agente, y puede alterar o fabricar cualquier respuesta que devuelve. Con el aislamiento desactivado y el acceso a la red habilitado, una respuesta manipulada se ejecutaría con todos los privilegios de la cuenta del usuario. Y las credenciales que el servicio instala como variables de entorno de ámbito de usuario no se quedan dentro del asistente: cualquier otra herramienta de esa máquina que lea esas variables las recoge.

Qué hay que hacer mañana

Las recomendaciones del informe de Google son concretas y varias de ellas no figuraban antes en las guías de seguridad de la nube. Las ordeno por lo que probablemente evita una factura de seis cifras.

• Cuotas por modelo y topes de gasto. Activa límites de peticiones por modelo y presupuestos con corte. No son solo una medida de costes: son una medida de detección.
• Alerta cuando se habilite un servicio de IA. En varios de los incidentes que investigó Mandiant, los servicios de LLM no estaban habilitados cuando se produjo el compromiso; el atacante usó las claves para habilitarlos y modificar sus ajustes. La habilitación de un servicio que no usas es un evento crítico.
• Segmenta las claves por alcance. Restringe y separa las claves de API por endpoint de modelo, por entorno, con desarrollo y producción, y por límite de uso, de manera que un token robado de una utilidad barata no pueda invocar un modelo frontera caro.
• Vigila los barridos de validación. Busca en los registros de la pasarela y de la API peticiones sospechosamente pequeñas, con `max_tokens` igual a 1 o con temperatura cero. Los atacantes usan esas microtransacciones para confirmar credenciales antes de lanzar el abuso a gran escala.
• Muros de error. Atiende los picos de errores ThrottlingException, ValidationException o ResourceNotFoundException: son la firma de un rociado automatizado contra la infraestructura.
• Higiene de credenciales. Gestor de secretos centralizado, rotación automática, escaneo de secretos en el código de GitHub y GitLab, mínimo privilegio y denegar el acceso a los servicios de LLM que no uses.
• MFA resistente al phishing, en todos los proveedores de identidad, en las consolas de administración y en las plataformas de desarrollo. Pero no te fíes solo del MFA: los tokens de federación permiten generar claves nuevas de forma programática y saltárselo.
• Audita las cuentas de servicio. Busca nombres que suenen a utilidad interna, sobre todo los que nada que ver con la optimización de la facturación.
• Cierra los endpoints publicados. Haz un barrido de tu nube buscando instancias de Ollama, gateways y pasarelas accesibles desde Internet, y ciérralas.
• Parchea las pasarelas de enrutamiento. Extiende la gestión de vulnerabilidades a LiteLLM y a sus equivalentes. La versión mínima es la 1.83.14-stable.
• Enciende la luz del plano de datos. En Azure hay que activar los registros de diagnóstico de Cognitive Services, y en Gemini Agent Platform los registros de acceso a datos están desactivados por defecto por volumen y coste. Si el registro no existe, no hay detección posible.
• Restringe las salidas. Limita las conexiones salientes de tus servicios de nube a las direcciones que deban usar, mediante reglas de cortafuegos de la red privada, y pon límites de tasa por cliente en la capa de aplicación.
• En los puestos con Codex o Claude Code, vigila los cambios en la URL base, un modo sandbox en danger-full-access, variables de entorno de ámbito de usuario con credenciales de modelos y cualquier iwr con iex o curl con bash ejecutado justo después de un npm install -g.

Y un apunte que resume lo anterior: el atacante esquivó las alertas de volumen porque su señal era mínima. Eso significa que la detección no se juega en el pico de consumo, sino en lo anómalo de lo pequeño. Una petición de un token no es ruido estadístico, es la firma de un barrido de credenciales.

Lo que deja el caso

La primera lección es que la credencial de modelo es la nueva credencial de servidor. Ya no se trata de proteger una máquina, se trata de proteger una línea de la factura. Una clave de API colada en un repositorio público no es un secreto mal guardado: es una cuenta corriente en un banco, y además sin ventanilla y sin aviso.

La segunda es que el hueco de detección no es técnico, es estadístico. Todo el sistema de alertas está diseñado para detectar picos, y el atacante se limitó a pedir un token por llamada. Eso obliga a cambiar la pregunta: no qué volumen tengo, sino qué peticiones tan pequeñas me están haciendo y por qué.

La tercera es que la monetización ya es un mercado. Los LLM Mixers no son atacantes sueltos: son una cadena de especialización donde unos entran, otros montan la infraestructura de reventa y un tercero se lleva el margen. El plan de sesenta dólares al mes es la prueba material del robo, porque ese precio solo es posible si alguien está pagando el consumo.

La cuarta es que la pasarela de modelos no está en el inventario de vulnerabilidades. En casi ningún equipo hay una persona encargada de parchear LiteLLM, de vigilar sus registros o de rotar sus credenciales, y esa pieza contiene las llaves de todos los proveedores a la vez. Mientras la pasarela exista fuera del programa de gestión de vulnerabilidades, el LLMjacking tiene un punto de apoyo permanente.

La quinta es que la ausencia de evidencia de abuso no es una garantía. El informe de Symantec lo dice con todas las letras: no hay pruebas de que el operador del retransmisor esté explotando su posición. La arquitectura que ha instalado permite leer cada prompt y ejecutar con los privilegios del usuario. Que no lo haya hecho hasta ahora es un dato del momento, no una propiedad del sistema.

Y la sexta es que el segundo factor ya no es la última puerta. El MFA protege el inicio de sesión, pero un token de sesión robado, un token de federación o una clave de cuenta de servicio no pasan por ninguna pantalla de verificación. En un mundo donde la autenticación se delega en tokens de larga duración, la pregunta relevante ya no es quién sabe tu contraseña, sino dónde está guardada cada credencial que puede hablar con tu cuenta.

Queda una última cosa, y es la más mundana de todas: la factura. En este esquema, el primer indicador de que algo va mal no es una alerta, es un correo de la plataforma de nube preguntando por tu consumo. Configurar presupuestos y alertas de gasto como mecanismo de detección, y no como recorte de costes, es la diferencia entre enterarte en el primer día o en el primer mes.

Fuentes

• Google Cloud Threat Intelligence: The Rise of LLMJacking, how threat actors monetize compromised cloud and model resources (2 de noviembre de 2026)
• The Hacker News: Google Warns LLMjacking Attacks Are Costing Some Enterprises Up to $1 Million in Cloud Charges (3 de noviembre de 2026)
• BleepingComputer: Google: LLMjacking attacks rack up $1 million in cloud AI charges (3 de noviembre de 2026)
• Obsidian Security: Breaking LiteLLM, from low-privilege user to admin and RCE (CVE-2026-47101, CVE-2026-47102, CVE-2026-40217)
• Symantec: Sandbox Flipped to Danger-Full-Access, unauthorized AI relays create risk for organizations
• LiteLLM: versiones publicadas del proyecto (BerriAI)