Quisieron añadir un mapa al sitio y acabaron pagando acceso a IA para la mitad de Internet: así funciona la nueva vulnerabilidad de Google

Durante años, Google convenció a los desarrolladores de que se podían dejar a la vista las claves de la API de Google, directamente en el código fuente del sitio. Esas claves se reconocen por el prefijo «AIza», y se insertan en las páginas para Google Maps, Firebase y otros servicios. Ahora se ha descubierto que esa regla habitual dejó de funcionar.

Tras la aparición de Gemini, esa misma clave en el código público puede abrir acceso a datos que nadie pensó exponer a terceros y, al mismo tiempo, permitir gastar el dinero del propietario del proyecto en llamadas a modelos de lenguaje.

Los autores de la investigación de The Dig escriben que el problema está en la arquitectura. En Google Cloud el mismo formato de clave se utiliza para dos tareas diferentes. Históricamente la clave servía más como «etiqueta del proyecto» para contabilidad y facturación, y no como secreto. Por eso Google decía explícitamente que las claves de la API no son secretos, e incluso en la documentación de Google Maps sugería insertar la clave en el código de la página. Para esas claves existen restricciones por origen de la petición, por ejemplo por la lista de direcciones de página permitidas, pero tales restricciones se eluden, y las claves no se diseñaron desde el inicio como credenciales completas.

La situación cambia cuando en ese mismo proyecto activan la API Gemini; en el texto la llaman Generative Language API. Tras activarla, las claves ya existentes en el proyecto pueden obtener acceso a puntos «sensibles» de Gemini. Los autores no vieron advertencias en la interfaz, correos ni solicitudes de confirmación adicionales. Una clave antigua para un widget de mapa, que durante años estuvo en un JavaScript público, de repente empieza a funcionar como clave para Gemini. Basta con que alguien del equipo active Gemini para un prototipo interno y la clave antigua quede igual y siga en los orígenes del sitio.

Los autores describen un escenario de ataque sencillo. Un atacante encuentra la clave en el código de una página y luego llama a las interfaces de Gemini con esa clave. En lugar de denegar, el servidor devuelve una respuesta exitosa. Según ellos, mediante tales peticiones se puede ver la lista de archivos subidos y el contexto guardado, además de inflar los gastos por llamadas a modelos o agotar los límites, con lo que las aplicaciones legítimas dejarían de responder. Un detalle importante: no es necesario comprometer la infraestructura de la víctima; basta con copiar la clave del código abierto.

Para estimar la escala, los autores revisaron el conjunto Common Crawl de noviembre de 2025 y afirmaron haber encontrado 2863 claves activas de la API de Google que estaban en acceso público y que además son aceptadas por Gemini. Según ellos, entre los afectados hubo grandes empresas del sector financiero, firmas de seguridad, servicios internacionales de recursos humanos y el propio Google. Como demostración, comprobaron una clave que estuvo en el código fuente de una página pública de uno de los productos de Google al menos desde febrero de 2023, es decir, antes de la aparición de Gemini. La verificación mediante el punto de acceso /models devolvió una respuesta exitosa y la lista de modelos disponibles. Los autores subrayan que la clave se usó como un identificador público del proyecto, sin intentos de invocar funciones «generativas».

Las vulnerabilidades se notificaron a Google el 21 de noviembre de 2025. Al principio la empresa calificó el problema como «comportamiento por diseño», pero tras los ejemplos con claves de la propia corporación se cambió el estado a error y se elevó la evaluación del impacto. El equipo solicitó la lista completa de claves encontradas y la recibió. A continuación, según los autores, Google puso en marcha un proceso interno para buscar claves filtradas y comenzó a limitar el acceso de esas claves a Gemini, mientras debatía la corrección de la causa raíz. El 13 de enero de 2026 la vulnerabilidad se clasificó como «Single-Service Privilege Escalation, READ» de nivel Tier 1. Al 2 de febrero de 2026, según los autores, el trabajo para corregir la causa raíz aún continuaba, y el periodo de divulgación de 90 días finalizó el 19 de febrero de 2026.

En Google señalaron que las nuevas claves en AI Studio se planea que, por defecto, limiten su uso solo a Gemini, para que una clave no funcione accidentalmente en otros servicios. Además, la compañía pretende bloquear por defecto las claves que detecten en filtraciones y que vean en peticiones a Gemini, y promete notificar con antelación a los propietarios de los proyectos sobre las claves filtradas que encuentren.

La recomendación para los equipos que usan Google Cloud es práctica. Si en el proyecto se activó Gemini, conviene revisar todas las claves de la API y asegurarse de que las claves con acceso a Gemini no se hayan publicado en sitios públicos ni en repositorios de código abiertos. Las claves antiguas para mapas y otros escenarios «en cliente» resultan especialmente peligrosas, porque durante años se publicaron siguiendo las recomendaciones anteriores. Si una clave está a la vista y además es válida para Gemini, es preferible reemplazarla y configurar restricciones por servicio y entorno para que la clave del interfaz público no pueda abrir acceso a los datos de Gemini.