En resumen: Cuando eliminas una clave de API de Google, se indica que se elimina inmediatamente. Nuestras pruebas indican ~23 minutos. Durante ese lapso, un atacante con una clave filtrada mantiene el acceso a tus datos y APIs habilitadas (incluido Gemini). No tienes forma de revocarla más rápido o confirmar cuándo deja de funcionar. Google cerró nuestro informe original como «no se solucionará».
Actualización del viernes 22 de mayo de 2026: Google ha reabierto nuestro informe y lo está tratando como un error P0.
Cuando eliminas una clave de API, esperas que el acceso finalice de inmediato.
Las claves de API de Google no funcionan así. La revocación se propaga gradualmente a través de la infraestructura de Google. Algunos servidores rechazan la clave en segundos, mientras que otros la siguen aceptando durante 23 minutos.
Un atacante que posea tu clave eliminada puede seguir enviando solicitudes hasta que una llegue a un servidor que aún no se haya actualizado. Si Gemini está habilitado en el proyecto, pueden volcar archivos que hayas subido y exfiltrar conversaciones en caché.
La consola de GCP no mostrará la clave, y no te indicará que la clave sigue funcionando. Estás confiando en que la infraestructura de Google se actualizará con el tiempo.
La autenticación no debería ser eventualmente consistente
Muchos de los servicios de Google Cloud son eventualmente consistentes por diseño. En este modelo, las actualizaciones se propagan gradualmente a través de sus servidores en lugar de hacerlo de una sola vez. Esta compensación permite a Google escalar globalmente y mantenerse rápido, y para la mayoría de los servicios, el retraso es imperceptible. Pero para la autenticación, esa compensación es más difícil de justificar.
Los retrasos en la revocación de credenciales son explotables. Hace unos meses, Eduard Agavriloae reveló un retraso de 4 segundos que permitía a las claves de acceso de AWS eliminadas crear nuevas credenciales. Cuatro segundos fueron suficientes para ser relevantes en AWS.
Dada la reciente atención a las claves de API de Google utilizadas para acceder a Gemini, nos propusimos medir cuánto tiempo permanece abierta la ventana de revocación de claves de API de Google.
¿Qué es una ventana de revocación?
La ventana de revocación es el tiempo transcurrido entre la eliminación de una clave y la última autenticación exitosa.
Si la ventana es de unos pocos microsegundos, el comportamiento coincide con lo que los usuarios esperan. Si es más larga, cada segundo adicional da a los atacantes más tiempo para hacer un uso indebido de una clave robada.
Medición de la ventana de revocación
Para medir la ventana de revocación de claves de API de Google, realizamos 10 pruebas durante dos días.
En cada prueba, creamos una clave de API, la eliminamos y enviamos de 3 a 5 solicitudes autenticadas por segundo hasta que no se obtuvo ninguna respuesta válida durante varios minutos.
Elegimos esa tasa porque no controlamos cómo Google enruta nuestras solicitudes a los diferentes servidores de autenticación en todo el mundo. El volumen tenía como objetivo rotar a través de tantos de ellos como fuera posible por prueba, respetando la infraestructura de Google. No podemos afirmar si una tasa de solicitudes más alta extendería la ventana observada. Un atacante no tiene motivos para limitar la velocidad como lo hicimos nosotros, por lo que cabe destacar que nuestras cifras podrían no representar el peor escenario.
Para mayor exhaustividad, también revisamos nuestro trabajo unas semanas después para asegurarnos de que el comportamiento observado no se debía a problemas transitorios de red.
23 minutos
En diez pruebas, la ventana más larga fue de casi 23 minutos. ¡Es un tiempo increíblemente largo para que una clave eliminada siga autenticándose con éxito!
La ventana más corta fue de casi 8 minutos, y la mediana fue de alrededor de 16 minutos. En todas las pruebas, la tasa de éxito fue muy impredecible: un minuto después de la eliminación, una prueba mostró que el 79% de las solicitudes tuvieron éxito, mientras que otra solo el 5%.
Un atacante que posea una clave robada no observa un corte limpio ni una disminución predecible. El acceso sigue funcionando, de forma irregular, hasta que finalmente se detiene.
Seguimiento de un único ensayo en la consola de GCP
Para ilustrar la inconsistencia en la infraestructura de Google, monitorizamos uno de nuestros ensayos utilizando el gráfico "Tráfico por credencial" en GCP. La línea inferior (azul) muestra autenticaciones exitosas y refleja la duración de la ventana de revocación.
No esperábamos ver ningún otro dato, pero apareció una segunda línea. La línea superior (verde) representa las solicitudes rechazadas y está etiquetada como apikey:UNKNOWN. Habíamos asumido (erróneamente) que las solicitudes no válidas simplemente se descartarían sin ninguna atribución de proyecto. En cambio, GCP las incluye en este gráfico.
Para comprender mejor el misterioso apikey:UNKNOWN valor, intentamos autenticarnos con una clave de API eliminada hace días. Sorprendentemente, esas solicitudes aparecieron en el mismo gráfico, agrupadas en el mismo apikey:UNKNOWN grupo.
Nuestra mejor suposición es que Google conserva la atribución del proyecto tras la eliminación de la clave en caso de que los usuarios decidan restaurar la credencial.
Para los equipos de IR que investigan una credencial filtrada, el apikey:UNKNOWN valor puede ser confuso. Cualquier solicitud realizada con cualquier clave de API de Google eliminada se agrupa en la misma categoría UNKNOWN, lo que dificulta saber qué solicitudes se relacionan con una credencial en particular. Una solicitud en esa categoría podría significar que un actor de amenazas sigue intentando autenticarse con la clave eliminada, o podría ser un servicio legítimo ejecutándose con una clave obsoleta no relacionada.
Si te encuentras dentro de la ventana de revocación de 23 minutos, busca autenticaciones válidas utilizando la clave filtrada. Si estás fuera de esa ventana, el riesgo parece extremadamente bajo.
Diferencias regionales en la consistencia
Realizamos el primer experimento desde una dirección IP residencial en la Costa Este de EE. UU. Planteamos la hipótesis de que ejecutar un experimento similar en VMs de diferentes regiones de GCP podría exponer inconsistencias adicionales.
Desplegamos una VM en tres regiones: us-east1, europe-west1, y asia-southeast1. Luego realizamos 5 ensayos. Para cada ensayo, eliminamos una única clave de API y enviamos solicitudes desde cada una de las tres VMs en paralelo.
Dos cosas destacaron. Primero, inmediatamente después de eliminar una clave, las VMs en diferentes regiones mostraron tasas de éxito de autenticación muy diferentes. La tabla a continuación muestra el porcentaje de solicitudes válidas en el primer minuto por región.
Observa el ensayo 1: us-east1 82%, europe-west1 60%, asia-southeast1 32%. Las VMs más alejadas de EE. UU. detectaron la eliminación más rápido, lo cual es lo opuesto a lo que cabría esperar. No podemos decir exactamente por qué desde fuera. El enrutamiento de solicitudes de Google es más complejo que "la región de la VM es igual a la región del servidor", y una VM en Singapur no está necesariamente comunicándose con servidores en Singapur. Pero el patrón fue consistente en todos los ensayos, lo que apunta a que la diferencia se debe a algo relacionado con la infraestructura regional, el almacenamiento en caché o la afinidad de enrutamiento.
En segundo lugar, la brecha regional no fue algo puntual del primer minuto. Durante todo el periodo, asia-southeast1 tuvo una tasa media de éxito de autenticación de solicitudes del 22%, mientras que us-east1 y europe-west1 ambos se situaron en torno al 49%. Asia se mantuvo más baja minuto a minuto, no solo al principio.
Sean cuales sean las causas de estas diferencias, la ubicación del servidor influye claramente en cómo se comporta una clave eliminada después de su eliminación.
Otras credenciales de Google
Todas nuestras pruebas utilizaron claves con acceso a Gemini, pero observamos el mismo comportamiento con claves con ámbito para otras API de GCP, como BigQuery y Maps. El retardo es una propiedad del tipo de credencial, no de las API habilitadas en el proyecto.
Para ser exhaustivos, probamos otros dos tipos de credenciales de Google:
- Nuevas claves API de Gemini (prefijo AQ.). La eliminación se propagó en ~1 minuto.
- Claves de cuenta de servicio de Google. La eliminación se propagó en ~5 segundos.
Ambos funcionan a escala de Google y ambos se revocan mucho más rápido que los 23 minutos que medimos para las claves API de Google.
Divulgación a Google
Informamos de esto a Google. Google cerró el informe como «no se solucionará». La postura del equipo, según la entendemos, es que el retardo de propagación es una propiedad conocida del sistema y no un problema de seguridad.
Aunque Google documenta públicamente que su API de IAM es eventualmente consistente, no documenta específicamente este comportamiento para las claves API de Google.
[Leyenda: Captura de pantalla de la página de documentación de la API de IAM de Google.]
Expectativas de usuario incumplidas
Los sistemas distribuidos a escala de Google son complejos, y esto no es una crítica al equipo de IAM de GCP. Pero una ventana de revocación de 23 minutos es fundamentalmente incompatible con lo que los usuarios esperan de un botón de eliminación. La brecha entre esa expectativa y el comportamiento de Google pone de manifiesto cuatro problemas:
1. La interfaz de usuario es extremadamente engañosa.
Cuando eliminas la clave, Google la elimina de tu vista y te dice: «Una vez eliminada, ya no se puede utilizar para realizar solicitudes a la API». Esa afirmación es demostrablemente falsa. El usuario no tiene forma de saber si la clave sigue activa, ninguna forma de acelerar la revocación y ninguna forma de confirmar cuándo ha dejado de funcionar por completo.
2. Google implementó una revocación más rápida para otros tipos de credenciales.
Las revocaciones de credenciales de cuentas de servicio se propagan en unos 5 segundos. El formato de clave API más reciente de Gemini se propaga en aproximadamente un minuto. Ambos funcionan a escala de Google. Ambos sugieren que esto también es técnicamente solucionable para las claves API de Google.
3. Las ventanas de consistencia largas no son compatibles con la autenticación.
La expectativa al eliminar una credencial es que esta quede inactiva. Incluso unos pocos segundos de retardo importan, como demostró la investigación de AWS de Eduard el año pasado.
4. Las ventanas de revocación largas interrumpen la creación de credenciales JIT.
Un proveedor de servicios que quiera crear dinámicamente claves API de Google tiene que incorporar un búfer de 23 minutos después de la revocación antes de que la clave se considere inactiva. Esto es incompatible con el funcionamiento previsto de JIT.
Gestionando la ventana
Hasta que Google implemente una revocación más rápida, la responsabilidad de cerrar esta brecha recae en los usuarios. Dos aspectos pueden ayudar.
1. Trate la eliminación de claves como una operación de 30 minutos, no instantánea.
Si está respondiendo a una clave API de Google filtrada, asuma que la clave está activa durante 30 minutos después de hacer clic en eliminar. Esto proporciona un margen de seguridad más allá de los 23 minutos máximos que observamos. Planifique el resto de su respuesta a incidentes en torno a esa ventana.
2. Supervise el uso durante la ventana.
En "Enabled APIs and services" en la consola de GCP, revise las solicitudes de API por credencial. Si observa un uso inesperado de esa credencial después de la eliminación, alguien podría estar explotándola activamente.
Las grandes ventanas de consistencia eventual son una elección de diseño incorrecta para la revocación de credenciales. Hasta que Google cambie esto, trate cada eliminación de clave como una operación de 30 minutos y supervise la ventana para detectar usos indebidos.
