Brecha de Fireworks AI: lista de control de riesgos para proveedores de inferencia tras el LLMjacking

La brecha de Fireworks AI es uno de los casos recientes más claros de cómo el riesgo atraviesa a un proveedor de inferencia alojada y termina recayendo en sus clientes. En octubre de 2026, Fireworks AI divulgó un incidente de seguridad. Una actualización posterior describió una segunda intrusión y un impacto más amplio.

A continuación se expone lo que Fireworks ha publicado realmente, seguido de un plan de respuesta al que llamamos playbook Secretos, Datos, Gasto. Después viene una lista de control de diligencia debida para futuras revisiones de proveedores.

Lo que Fireworks ha divulgado: dos intrusiones, en orden

Fireworks ha publicado un boletín de seguridad inicial y una actualización posterior. Leídos en paralelo, describen dos intrusiones distintas.

El primer incidente, identificado el 6 de octubre, consistió en el uso no autorizado de credenciales internas de Fireworks. Según el boletín inicial, un tercero no autorizado accedió a variables de entorno utilizadas en trabajos de evaluación en un número limitado de cuentas de clientes.

El segundo llegó a través de un proveedor. Un proveedor de nube externo que alojaba máquinas de I+D de Fireworks sufrió un incidente de seguridad el 23 de octubre. Un día después, el 24 de octubre, el atacante usó ese acceso para llegar a máquinas de desarrollo de Fireworks y ejecutar una carga de trabajo no autorizada, lo que provocó un impacto adicional en datos de clientes.

La actualización también cambió la imagen de lo sustraído. Cuando salió el primer boletín, solo se sabía que se había accedido a secretos almacenados en Fireworks. Una investigación posterior detectó impactos en información de cuentas y facturación y, para un conjunto limitado de cuentas, impactos en secretos, conjuntos de datos y modelos incompletos.

En cuanto a la atribución, la empresa cita pruebas que vinculan la actividad con un grupo ciberdelictivo con motivación económica que vende tokens procedentes de acceso no autorizado a LLM a pasarelas de enrutamiento ilícitas, una práctica que denomina "LLMJacking".

Todavía hay un vacío en el registro. Según The Register, la actualización no indicó cuántos clientes se vieron afectados por cada ataque. Hasta que Fireworks diga más, confirma tu propia exposición directamente con el proveedor.

Qué se expuso, qué no y qué cambió Fireworks

En el primer incidente, Fireworks cree que se capturaron variables de entorno, incluidas claves de API y tokens almacenados como secretos, en ciertas cuentas afectadas. Un secreto en el entorno de un trabajo rara vez es interesante por sí mismo; su valor reside en lo que desbloquea en otros lugares.

La información de facturación expuesta incluía direcciones de facturación y envío, historial de facturas y pagos, saldo de la cuenta y uso de créditos. Los números de tarjetas de pago son otra cuestión: la empresa afirma que no los almacena y que no se vieron afectados.

Sobre los pesos de los modelos, Lin Qiao, CEO de la empresa, dijo a The Register que los atacantes no parecían ir tras los pesos y que la mayoría de las descargas fueron parciales y se detuvieron. Trátalo como la evaluación del propio proveedor, no como una conclusión independiente.

El impacto también se propaga aguas abajo. Notion, cliente de Fireworks, comunicó a los usuarios afectados que sus espacios de trabajo figuraban entre el menos del 1 por ciento de los espacios de trabajo de Notion que podrían haberse visto afectados por el incidente de Fireworks.

El producto ha cambiado en respuesta. Las cargas y descargas autoservicio de conjuntos de datos que usan Batch Inference y el entrenamiento basado en conjuntos de datos se han desactivado durante la investigación. La documentación de fine-tuning indica ahora que se han eliminado los evaluadores y los trabajos de evaluación. Se trata de la misma función cuyas variables de entorno quedaron expuestas en el primer incidente.

Por qué el LLMjacking convierte una clave filtrada en una factura enorme

El LLMjacking es el robo y la reventa del acceso a la inferencia de modelos.

El Google Threat Intelligence Group informa de que, en múltiples investigaciones de lo que denomina "LLMJacking", el vector de acceso inicial predominante han sido tokens de identidad en la nube expuestos o robados. Entre ellos figuran credenciales de IAM, claves de cuentas de servicio, tokens de acceso personal de GitHub y tokens de sesión activos. Fíjate en cuánto más amplia es esa lista que las claves de API de modelos. Para los defensores, ese es el punto principal.

Google describe los "LLM Mixers" como pasarelas de enrutamiento ilícitas que hacen de proxy, agregan y revenden acceso no autorizado a LLM a suscriptores clandestinos. Un servicio, Jet Night, ofrece un plan de tokens ilimitados por unos $60 al mes con supuesto acceso a modelos de frontera, mientras que ese nivel de servicio para consumidores costaría normalmente entre $100 y $250 al mes.

Alguien paga la diferencia, y es la víctima. En los incidentes que describe Google, los cargos fraudulentos superaron los $100,000 en un solo día, y los cargos acumulados en algunas organizaciones alcanzaron $1 millón antes de que se revocara el acceso. En un caso, un actor de amenazas realizó más de 500,000 llamadas a la API de LLM en menos de ocho horas, usando claves de API robadas a terceros para alimentar Jet Night, y el servicio trasladó casi $1 millón en costes de tokens a la organización víctima.

Investigaciones anteriores apuntan en la misma dirección. El análisis original de 2024 de Sysdig estimó que un ataque no descubierto podría costar a una víctima más de $46,000 al día en consumo de LLM. Una investigación posterior de Sysdig afirmó que esa cifra casi se triplicó hasta superar los $100,000 al día con modelos de primer nivel como Claude 3 Opus.

El playbook Secretos, Datos, Gasto para clientes de inferencia alojada

Estos siete pasos se aplican a este incidente y al próximo similar, sea cual sea el proveedor.

Secretos: lo que entregaste

Paso 1: Inventaría cada secreto almacenado. Enumera cada secreto almacenado en el proveedor, prestando especial atención a las variables de entorno asociadas a trabajos de evaluación, por lotes o de entrenamiento. Dado que se capturaron claves de API y tokens almacenados como secretos en ciertas cuentas afectadas, trata cualquier secreto dentro del alcance como comprometido hasta que se demuestre lo contrario.

Paso 2: Rota en el origen. Revoca y vuelve a emitir cada credencial de terceros con el proveedor que la emitió. El proveedor es explícito: eliminar únicamente un secreto almacenado no invalida la credencial subyacente, y las credenciales de terceros requieren actuar con sus proveedores emisores. A largo plazo, mantén las claves en bruto completamente fuera de los entornos de ejecución de los trabajos. Los equipos pueden plantearse un proxy de credenciales para ello; consulta nuestra guía sobre proxies de credenciales para agentes de IA.

Paso 3: Delimita el radio de impacto. Para cada clave rotada, anota a qué podía acceder (cuentas en la nube, repositorios, bases de datos, otras API de modelos) y revisa los registros de esos sistemas en busca de actividad posterior a la ventana de exposición. Da a los tokens de identidad en la nube y a los tokens de GitHub la misma prioridad que a las claves de modelos; en las investigaciones de Google fueron la vía de entrada más común.

Datos: lo que subiste

Paso 4: Revisa conjuntos de datos y modelos. Determina qué conjuntos de datos, trabajos de fine-tuning y modelos incompletos residían en la plataforma. Después decide si alguno de esos datos obliga a notificar a clientes, por contrato o por normativa. Involucra pronto a la asesoría jurídica.

Paso 5: Ajusta los flujos de trabajo afectados. Planifica teniendo en cuenta las funciones de conjuntos de datos en pausa para Batch Inference y el entrenamiento basado en conjuntos de datos. Decide si volverás a subir los datos cuando regresen las funciones o si a partir de ahora los mantendrás en tu propio entorno.

Gasto: lo que vigilas

Paso 6: Informa a finanzas sobre la exposición de facturación. Las direcciones, el historial de facturas y los saldos filtrados dan a un estafador detalles útiles para un correo de phishing creíble o una factura falsa. Pide a finanzas y a cuentas por pagar que confirmen cualquier solicitud de pago inesperada o cambio bancario a través de un canal en el que ya confíen.

Paso 7: Establece límites y alertas en cada clave restante. Configura alertas de gasto por clave y límites estrictos, tanto en el proveedor como en la facturación de tu propia nube. Envíalas a un canal de guardia, no a una bandeja compartida que nadie lee por la noche. La sección de monitorización que aparece más abajo detalla qué señales vigilar.

Sea cual sea el grupo, registra cada decisión con una marca de tiempo y un responsable.

Quién es responsable de cada paso

Úsalo como punto de partida por defecto. En un equipo pequeño, una sola persona puede cubrir varios roles. Lo importante es que cada paso tenga un responsable con nombre.

Dónde se aplica la retención cero de datos y dónde no

Según la documentación de tratamiento de datos de Fireworks, la empresa aplica retención cero de datos (ZDR) por defecto, lo que significa que no registra ni almacena datos de prompts o generaciones de ningún modelo abierto sin la aceptación explícita del usuario. Su página de política de ZDR añade una salvedad: algunas funciones sí almacenan contenido del cliente, como las respuestas almacenadas, los trabajos por lotes y el entrenamiento.

Fíjate en lo que la brecha tocó realmente: contenido almacenado, en forma de conjuntos de datos y modelos incompletos, además de secretos, que ZDR nunca pretendió cubrir. Un ZDR por defecto vale la pena para la inferencia en tiempo real. No es una promesa sobre todo lo que envías. Te sugerimos comprobar la configuración de retención de cada proveedor que utilices en lugar de suponer que coinciden; nuestra guía sobre el almacenamiento de solicitudes de la API de Gemini es una lectura relacionada.

En la práctica, etiqueta cada carga de trabajo como solo inferencia o como contenido almacenado. Para cargas de lotes o de fine-tuning, elimina los campos que el modelo no necesita, oculta los datos personales cuando puedas y conserva la copia maestra en tu propio entorno.

Lista de control de diligencia debida: preguntas para cualquier proveedor de inferencia

Llévalas a las revisiones de compras, las renovaciones y los cuestionarios de seguridad. Cada una surge de la cronología de Fireworks o del patrón más amplio del LLMjacking.

• [ ] Gestión de secretos: ¿Dónde se almacenan los secretos de los clientes, quién puede leerlos y los entornos de ejecución de los trabajos los reciben como variables de entorno en texto plano?
• [ ] Cadena de suministro: ¿Qué nubes de terceros alojan máquinas de I+D o de desarrollo, y cómo están aisladas de los datos de los clientes?
• [ ] Mapa de retención: ¿Qué funciones almacenan contenido del cliente? Como muestra la sección anterior, esto varía según la función, así que obtén la respuesta por escrito.
• [ ] Comunicación de incidentes: ¿Revelará el proveedor cuántos clientes se vieron afectados y cómo te llegarán las actualizaciones?
• [ ] Ciclo de vida de las funciones: Cuando se retira una función, como ocurrió aquí con los evaluadores y los trabajos de evaluación, ¿cómo se purgan sus secretos y datos?
• [ ] Controles de facturación: ¿Puedes establecer límites de gasto, cuotas por clave y alertas de anomalías que lleguen a un canal de guardia?
• [ ] Alcance de las credenciales: ¿Se pueden limitar las claves a modelos, proyectos o entornos concretos, y rotarlas sin tiempo de inactividad?
• [ ] Acceso a registros: ¿Puedes ver quién leyó tus secretos y cuándo?

Las buenas respuestas no harán desaparecer el riesgo. Los equipos que enrutan tráfico entre varios proveedores también pueden querer controles de enrutamiento y presupuesto en la capa de gateway; consulta nuestro playbook de AI gateway.

Monitorización del LLMjacking: señales que pueden aparecer antes de la factura

El LLMjacking suele ser ruidoso. Sus señales a menudo aparecen en los datos de uso mucho antes de que llegue la factura, siempre que alguien esté mirando.

• Ráfagas de volumen. Sysdig detectó más de 85,000 solicitudes a la API de Bedrock en una campaña, y 61,000 de ellas llegaron en una ventana de tres horas el 11 de julio de 2024. Un pico así debería hacer saltar un aviso a alguien.
• Anomalías de ritmo. El caso de Jet Night, más de 500,000 llamadas en menos de ocho horas, probablemente supera con creces cualquier cosa que hagan normalmente tus claves. Configura alertas ante grandes desviaciones respecto al ritmo habitual de cada clave. El trazado GenAI con OpenTelemetry es una forma de recopilar los datos de uso que necesitas para esa referencia.
• Umbrales de gasto. Los límites por hora o por día del Paso 7 contienen los daños a la escala diaria que informó Google. Una revisión mensual no puede hacerlo.
• Patrones inusuales. Vigila llamadas a modelos que no usas normalmente, nuevas regiones, direcciones IP de origen desconocidas y actividad a horas extrañas.
• Identidad, no solo claves. Trata cualquier token de identidad en la nube robado como un posible punto de entrada de LLMjacking.

Esta tendencia no empezó con Fireworks. Sysdig informó de un aumento de 10x en las solicitudes de LLMjacking durante julio de 2024, y del doble de direcciones IP únicas participando en estos ataques durante la primera mitad de 2024.

Errores comunes que cometen los equipos tras una brecha de un proveedor de inferencia

• Tratar la eliminación como revocación. Borrar un secreto de un panel es una tarea de limpieza. No es una rotación (consulta el Paso 2).
• Dar demasiado valor a una insignia de ZDR. Revisa la tabla de retención antes de suponer que una carga de trabajo nunca se almacenó.
• Rotar solo la clave obvia. Las claves de IAM, las claves de cuentas de servicio y los tokens de GitHub almacenados junto a la clave del modelo importan igual. En las investigaciones de Google, los tokens de identidad en la nube fueron el punto de entrada más común.
• Tratar el primer boletín como definitivo. Aquí el alcance creció de los secretos almacenados a la información de facturación, los conjuntos de datos y los modelos incompletos. Vuelve a comprobar tu exposición con cada actualización.
• Esperar a la factura mensual. Con los ritmos de pérdida diarios descritos anteriormente, una factura llega demasiado tarde para servir de ayuda.

Salvedades: lo que sigue sin saberse y cómo interpretar las cifras

• Fireworks no ha revelado cuántos clientes se vieron afectados.
• La afirmación de que los atacantes no buscaban los pesos de los modelos procede de Lin Qiao, CEO de Fireworks, y no se ha verificado de forma independiente.
• Las cifras de costes del LLMjacking proceden de investigaciones de Google Threat Intelligence Group y Sysdig sobre otras víctimas, no de este incidente. Muestran lo que es posible, no lo que perdieron los clientes de Fireworks.
• Las cifras de Sysdig datan de 2024 y reflejan los precios de los modelos y los volúmenes de ataque de ese periodo.
• La cifra de menos del 1 por ciento de Notion se aplica solo a los espacios de trabajo de Notion.
• Las obligaciones de notificación dependen de tu jurisdicción y de tus contratos, así que busca asesoramiento jurídico cuando corresponda.