- Google ha indicado durante más de 10 años que las claves API no son secretas y es seguro hacerlas públicas, pero tras la activación de la API de Gemini, la misma clave pasó a convertirse en un medio de autenticación sensible
- Las claves públicas usadas en Google Maps, Firebase y otros servicios obtuvieron automáticamente permiso de acceso a la API de Gemini, por lo que con una clave expuesta es posible acceder a datos privados y generar cargos
- Truffle Security confirmó que 2,863 claves API de Google en uso real están expuestas en Internet, y que entre ellas hay incluso claves de servicios del propio Google
- Google reconoció el problema y está introduciendo bloqueo de claves filtradas, configuración predeterminada exclusiva para Gemini y funciones de alerta por exposición, pero la revisión retroactiva de las claves existentes sigue incompleta
- Este caso muestra el riesgo de expansión de privilegios en credenciales existentes debido a la integración de funciones de IA, y los desarrolladores deben revisar de inmediato si la API de Gemini está habilitada y si sus claves están expuestas
Problema central
- Google Cloud usa una estructura de clave API única con formato
AIza..., que cumple al mismo tiempo dos propósitos: identificación pública y autenticación sensible
- En el pasado, Google indicaba explícitamente a los desarrolladores que era seguro incluir la clave API directamente en el código del cliente
- Incluso en la checklist de seguridad de Firebase se indicaba que “la clave API no es un secreto”
- Sin embargo, al habilitar la API de Gemini, todas las claves API del proyecto existente obtienen automáticamente permiso para acceder a los endpoints de Gemini
- Los privilegios se amplían sin advertencia, sin paso de confirmación y sin notificación por correo
- Esto provoca dos problemas
- Expansión retroactiva de privilegios (Retroactive Privilege Expansion): una clave pública de Maps del pasado pasa a ser una credencial con acceso a Gemini
- Valores predeterminados inseguros (Insecure Defaults): al crear una nueva clave, la configuración por defecto queda como “Unrestricted”, permitiendo acceso a todas las API, incluida Gemini
- Como resultado, miles de tokens usados para facturación pasaron a convertirse en credenciales de autenticación reales expuestas en Internet
Escenarios posibles de ataque
- Un atacante puede copiar una clave
AIza... desde el código fuente de un sitio web y acceder a la API de Gemini con una simple solicitud curl
- Con ello, el atacante podría
- Acceder a datos privados (endpoints
/files/, /cachedContents/)
- Generar cargos por uso de la API de Gemini
- Agotar la cuota y provocar interrupciones del servicio
- El atacante no necesita comprometer la infraestructura de la víctima; puede lanzar el ataque extrayendo la clave de una página web pública
Escala de las claves expuestas
- Truffle Security analizó el dataset de Common Crawl de noviembre de 2025 (aprox. 700 TiB) y encontró 2,863 claves API de Google activas
- Estas claves se usaban originalmente para servicios públicos como Google Maps, pero tenían permisos de acceso a la API de Gemini
- Entre los afectados había instituciones financieras, empresas de seguridad, una firma global de reclutamiento y el propio Google
- Incluso Google estaba expuesto al mismo riesgo estructural
Caso de claves internas de Google
- Truffle Security demostró acceso a la API de Gemini usando una clave incluida en el código fuente público del sitio web de un producto de Google
- Esa clave había sido pública desde antes de febrero de 2023 y originalmente se usaba solo para identificación de proyecto
- Al llamar al endpoint
/models, devolvió una respuesta válida (200 OK), confirmando acceso a una API sensible
- Es decir, un caso en el que una clave antes inofensiva obtuvo privilegios sensibles sin intervención del desarrollador
Reporte de la vulnerabilidad y cronología de respuesta
- 21 de noviembre de 2025: reporte al VDP de Google
- 25 de noviembre: Google lo consideró “comportamiento intencional”
- 1 al 2 de diciembre: después de que Truffle Security presentó el caso de una clave interna de Google, Google lo reclasificó como bug y elevó la severidad
- 12 de diciembre: Google comenzó a ampliar el pipeline de detección de claves filtradas y a restringir el acceso a Gemini
- 13 de enero de 2026: Google clasificó la vulnerabilidad como “escalación de privilegios en un solo servicio (Single-Service Privilege Escalation, READ)”
- 2 de febrero: se confirmó que seguían en marcha las correcciones de la causa raíz
Medidas posteriores de Google
- Google anunció en su documentación oficial los siguientes planes de refuerzo de seguridad
- Scoped defaults: las nuevas claves creadas en AI Studio solo permitirán acceso exclusivo a Gemini
- Leaked key blocking: bloqueo automático del acceso a la API de Gemini para claves filtradas
- Proactive notification: aviso inmediato al usuario cuando se detecte una clave expuesta
- Algunas mejoras ya están en marcha, pero la revisión retroactiva y la notificación a usuarios por claves previamente expuestas aún no se han completado
Guía de revisión para desarrolladores
- Paso 1: verificar en todos los proyectos de GCP si la Generative Language API está habilitada
- Paso 2: si lo está, identificar en la configuración de claves API las claves con “Unrestricted” o que incluyan Gemini
- Paso 3: confirmar si esas claves están incluidas en código público o en páginas web
- Las claves expuestas deben rotarse de inmediato
- Extra: con la herramienta TruffleHog es posible detectar automáticamente claves reales con acceso a Gemini
- Ejemplo de comando:
trufflehog filesystem /path/to/your/code --only-verified
Conclusión
- Este caso muestra el riesgo estructural de que credenciales públicas existentes adquieran privilegios sensibles debido a la incorporación de funciones de IA
- Google ya reconoció el problema y está respondiendo, pero vuelve a quedar en evidencia la importancia de contar con valores predeterminados seguros y de separar las claves por diseño
- Los desarrolladores y las empresas deben revisar de inmediato si la API de Gemini está habilitada y si sus claves están expuestas
1 comentarios
Comentarios en Hacker News
La documentación de Google AI Studio recomienda desplegar apps mediante un proxy abierto
Este enfoque hace pensar erróneamente que la clave API está segura por estar detrás del proxy, pero en realidad permite abusos de facturación de IA
Incluso apps sin ninguna función de IA quedan expuestas a modelos costosos si el alcance de la clave no se limita manualmente
Estas apps vulnerables se pueden encontrar fácilmente solo con búsquedas en Google, Twitter o Hacker News
El análisis relacionado está resumido en este artículo
Google dice que bloqueará las claves filtradas, pero en primer lugar nunca trató esas claves como secretas
Lo ideal habría sido impedir que todas las claves creadas antes del lanzamiento de Gemini pudieran acceder a Gemini
Si el sistema de detección de filtraciones produce falsos positivos, existe el riesgo de bloquear incluso claves legítimas de Gemini
Como mínimo, habría que quitar el permiso de la Generative Language API de todas las claves existentes, aunque ni siquiera eso sería una solución completa
Al final, quizá sea necesario retirar ese permiso de todas las claves de forma masiva
Eso rompería muchísimas aplicaciones y explica por qué Google no quiere reconocer el problema
Más grave aún es que las claves también exponen contexto en caché y datos subidos
Se descubrió que claves de Google hardcodeadas en imágenes antiguas de Android realmente podían usarse con Gemini
Algunas ya estaban siendo usadas por muchas personas y tenían límites de velocidad, pero varias seguían funcionando
Hace unos dos meses, estas claves fueron consideradas filtradas y todas quedaron desactivadas
Las claves creadas hace mucho tiempo eran originalmente para servicios limitados como Firebase o Firestore
Pero tras el lanzamiento de Gemini, el acceso a Gemini se activó automáticamente también para las claves existentes, lo que facilitó el abuso
En otras palabras, una clave pública incluida en un archivo APK terminó convirtiéndose también en una clave de acceso a Gemini
Por ejemplo, si el desarrollador X crea una clave para Maps y otro desarrollador Y activa Gemini en el mismo proyecto,
la clave de X obtiene permisos de acceso a Gemini
Por eso hay que evitar reutilizar proyectos y usar proyectos de GCP separados por servicio
Genera dudas por qué una falla de seguridad tan obvia no fue detectada antes
Una empresa grande como Google debería tener pruebas o especificaciones estandarizadas para esto
Cuanto más crece y se vuelve compleja una organización, más aumentan estos puntos ciegos de supervisión
pero ellos siguieron obsesionados solo con problemas de invertir árboles binarios
Esta situación recuerda casos pasados de abuso del SSN (número de Seguro Social)
Originalmente era solo un número de identificación, pero el problema creció cuando en algún momento empezó a usarse como clave de autenticación
Es la típica estructura donde por implementar algo rápido y barato, al final el costo se le traslada al usuario
Parece que Google todavía no ha resuelto completamente este problema
Fue un gran error provocado por sacar Gemini con demasiada prisa,
y para corregirlo probablemente habría que desactivar claves existentes, con alto riesgo de romper flujos de trabajo de clientes
También es un golpe muy dañino para la imagen de Google
Este es una especie de problema de expansión retroactiva de privilegios (Retroactive Privilege Expansion)
Si antes tenías una clave de Maps expuesta públicamente en un sitio web y otro desarrollador del equipo activa Gemini,
esa clave pública pasa de inmediato a ser una credencial de acceso a Gemini
Como resultado, cualquiera puede usar esa clave para acceder a cargas de archivos o datos en caché
Los usuarios que siguieron la documentación anterior y usaron claves públicas son quienes están pagando las consecuencias
Un atacante puede robarla y provocar una explosión de cargos
Para explicarlo fácil: miles de claves API existentes pasaron de ser simples tokens de facturación a
convertirse de repente en credenciales de acceso a Gemini
Una clave de la API de Maps estaba pensada originalmente para darle mapas al usuario mientras el cobro iba a mi tarjeta
El problema es que ahora esas claves también pueden acceder a Gemini
Se debieron crear proyectos internos separados para aislar las claves,
pero por querer desplegar rápido, se usó tal cual código generado por LLM, y cuando apareció el problema se terminó culpando a Google
También fue impresionante la investigación previa de la empresa de seguridad que analizó este problema
Por ejemplo, en el artículo “Anyone can Access Deleted and Private Repository Data on GitHub”
mostraron un caso de vulnerabilidad de acceso a datos de repositorios eliminados en GitHub
También esta vez su análisis fue de gran ayuda