Säkerhetsforskare på Aikido Security har avslöjat att borttagna API-nycklar i Google Cloud Platform kan fortsätta fungera i upp till 23 minuter efter radering. Det innebär att en angripare som fått tag på en läckt nyckel kan behålla åtkomst till data och tjänster långt efter att nyckeln tagits bort.

Vad forskarna hittade

I tio separata tester mätte Aikido hur länge raderade API-nycklar kunde autentisera mot Googles servrar. Resultaten var tydliga:

• Längsta fönstret: nästan 23 minuter
• Kortaste fönstret: cirka 8 minuter
• Medianen: ungefär 16 minuter

Under den tiden kan en angripare fortsätta skicka förfrågningar som om nyckeln fortfarande vore giltig. Om Gemini är aktiverat på projektet kan angriparen komma åt uppladdade filer och cachade konversationer.

Varför det händer

Google Cloud använder så kallad "eventual consistency" för många av sina tjänster. Det betyder att uppdateringar sprids gradvis över infrastrukturen i stället för att slå igenom direkt. För de flesta funktioner märks inte fördröjningen, men för autentisering skapar det en sårbarhet.

När du raderar en API-nyckel i GCP-konsolen ser det ut som att nyckeln försvinner omedelbart. I verkligheten tar det tid innan alla servrar slutar acceptera den.

Googles svar

Google stängde först rapporten som "Won't Fix" med kommentaren att fördröjningen "fungerar som avsett". Efter att Aikido publicerade sin forskning den 21 maj 2026 ändrade Google sig och uppgraderade ärendet till en P0-bugg, alltså högsta prioritet.

Vad företag bör göra

Aikido rekommenderar att organisationer som raderar API-nycklar i Google Cloud:

• Övervakar API-trafik i minst 30 minuter efter radering
• Kontrollerar loggar för oväntade förfrågningar under den perioden
• Roterar nycklar regelbundet i stället för att bara radera dem
• Begränsar vilka tjänster varje API-nyckel har åtkomst till

Sårbarheten påminner om att radering inte alltid betyder omedelbar återkallning i molnmiljöer. Företag som hanterar känslig data i Google Cloud bör vara medvetna om detta fönster och planera sin incidenthantering därefter.