¿Tus API keys han podido quedar expuestas?
En octubre de 2026 se han conocido tres incidentes que tocan secretos de clientes: las variables de entorno de Railway, la versión 1.107.0 de LiteLLM con un ladrón de credenciales y las API keys cifradas de TiDB Cloud.
Hacemos el inventario de vuestros secretos, los rotamos en un orden que corta primero el riesgo mayor, revocamos los antiguos, revisamos si alguien los usó y los dejamos en un gestor de secretos con tokens de vida corta.
# ¿Qué versión de LiteLLM hay instalada?$ pip show litellm | grep -i ^versionVersion: 1.107.0# 1.107.0 es la versión maliciosa publicada el 21-oct en PyPI y Docker Hub$ docker images | grep -i litellm$ grep -rn "litellm" requirements*.txt pyproject.toml poetry.lock uv.lock 2>/dev/null# Fija la última versión buena en el lockfile y en las imágenes$ pip install "litellm==1.106.2"# Fijar la versión no limpia la máquina: rota los secretos que tenía a manoTres incidentes, la misma tarea pendiente
En los tres casos el proveedor ha hecho su parte y la rotación de lo que estaba expuesto queda del lado del cliente: el proveedor no puede cambiar vuestra clave de Stripe ni la de OpenAI.
Railway
El 21 de octubre detectó actividad anómala en los sistemas que guardan las variables de entorno de sus clientes. Un tercero pudo acceder a variables cifradas y en algunos casos descifrarlas. Pausó los despliegues y pide rotar credenciales. No ha publicado cifra de afectados ni vector. Fuente.
LiteLLM 1.107.0
El 21 de octubre se publicó en PyPI y Docker Hub una 1.107.0 maliciosa: roba credenciales y carga código remoto al arrancar cualquier proceso Python. Los atacantes usaron tokens OAuth de GitHub CLI robados a tres ingenieros; el tag de GitHub está limpio. Es la segunda vez este año. Fuente: Wiz.
PingCAP / TiDB Cloud
Entre el 9 de septiembre y el 7 de octubre, un tercero usó credenciales robadas de una cuenta de servicio y copió metadatos de cuentas y proyectos, texto del editor SQL, registros de facturación y valores cifrados de API keys. Sin evidencia de impacto en los datos almacenados en TiDB. Fuente: PingCAP.
Seis pasos, del inventario a los tokens de vida corta
Los cuatro primeros cortan el acceso y miden el daño. Los dos últimos cambian cómo guardáis los secretos para que la próxima filtración afecte a menos cosas y dure menos.
- 01
Inventario de secretos
Variables del PaaS, ficheros .env, secretos del CI, claves dentro de imágenes Docker y del código. Para cada uno: qué da acceso a qué y en cuántos sitios está.
- 02
Rotar en orden
Proveedores de IA, cloud, bases de datos, pasarelas de pago y tokens de CI. Primero lo que se convierte antes en consumo o en acceso a más secretos.
- 03
Revocar las antiguas
Una clave que ya no usáis pero sigue activa vale lo mismo para quien la tenga. Comprobamos en cada proveedor que la anterior está revocada.
- 04
Revisar los logs de uso
Consumo de los proveedores de IA, CloudTrail o el registro de auditoría de vuestro cloud, accesos a la base de datos y el panel de Stripe, durante la ventana de exposición.
- 05
Gestor de secretos
Movemos los secretos a un gestor (el de vuestro cloud, Vault o Doppler) para que cada uno viva en un sitio y rotarlo sea cambiar un valor.
- 06
Tokens de vida corta
Donde el proveedor lo permite, el CI y los servicios piden credenciales temporales (OIDC, roles de IAM) en lugar de guardar claves que no caducan.
Qué se rota primero y por qué
LiteLLM es un proxy delante de los proveedores de modelos, así que una máquina que lo ejecuta suele tener a mano las claves de IA. Con una clave de IA robada alguien puede generar consumo a vuestra costa en minutos, y una clave de cloud abre el resto.
Los tokens de CI van al final de la lista porque los usamos para desplegar los cambios anteriores. Si hay indicios de que el CI está comprometido, suben al principio y desplegamos desde otro sitio mientras tanto.
Crear, desplegar, revocar, comprobar
Si se revoca antes de desplegar la nueva, la aplicación se cae. Si se despliega la nueva y no se revoca la antigua, la filtración sigue abierta.
Menos sitios donde vive cada clave
Lo que más tiempo cuesta en una rotación de urgencia es averiguar dónde está cada clave. Un gestor de secretos convierte ese inventario en algo que ya existe antes del incidente.
- La misma API key vive en el PaaS, en el portátil de dos personas y en el CI
- Nadie sabe cuántos sitios hay que tocar para rotarla
- Las claves no caducan: una filtrada hace un año sigue valiendo
- Sin registro de quién leyó qué secreto y cuándo
- Cada secreto está en un sitio (AWS Secrets Manager, Vault, Doppler o el de vuestro cloud) y las apps lo leen de ahí
- Rotar es cambiar un valor y redesplegar
- El CI obtiene credenciales temporales por OIDC en vez de guardar claves fijas
- El gestor registra los accesos, y eso es lo primero que se mira en un incidente
¿Usáis Railway, LiteLLM o TiDB Cloud?
Escríbenos →Preguntas frecuentes sobre credenciales expuestas
Uso Railway, ¿tengo que rotar todo?
Tengo LiteLLM 1.107.0, ¿basta con bajar a 1.106.2?
¿Qué tengo que hacer si uso TiDB Cloud?
¿Por qué en ese orden?
¿Rotar significa que ya estamos a salvo?
Empezamos por el inventario
Cuéntanos dónde desplegáis y qué proveedores usáis. Con eso preparamos la lista de secretos que hay que rotar y en qué orden, y decidís si la ejecutamos nosotros o vuestro equipo.
Cuéntanos tu reto. Te proponemos solución.
Sin compromiso. En menos de 24 h recibes una propuesta con alcance, plazos y presupuesto. Sin letra pequeña.