Your serverless app is a service account one bug from a shell
A GCP Cloud Run service or Cloud Function runs as a service account and can fetch its token from the metadata server. One app bug and the attacker is calling GCP as your service. Here is the path, and the fix.
Serverless removed the server, not the credentials. The app still authenticates as something powerful.
What it is
Cloud Run services and Cloud Functions run as a service account and obtain access tokens from the GCP metadata server (169.254.169.254). An attacker who achieves code execution or SSRF in the app queries the metadata server, gets the service account’s token, and calls GCP as the service: Cloud Storage, Secret Manager, and more, bounded only by the service account’s roles. This is T1552 (unsecured credentials) into T1078 (valid accounts).
Why it works
No key is stored, the token comes from a trusted metadata endpoint, and the calls are the service’s own identity. An over-privileged service account turns one app bug into a broad GCP foothold.
How to detect it
Watch for service-account API calls outside the app’s normal pattern or from unexpected origins, and for application-layer signs of SSRF or injection.
The fix that holds
Least-privilege the service account, harden the app, restrict egress and access to the metadata server where supported, and alert on the service account reaching resources it does not normally touch.
Practice it
We built a Cloud Run and Functions service-account abuse scenario in GraphLattice Range so teams learn the metadata-to-GCP path and how to contain it.