Fetch-url-http-3a-2f-2fmetadata.google.internal-2fcomputemetadata-2fv1-2finstance-2fservice Accounts-2f ★

Zero typed the malicious payload into their terminal:

http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

They pressed Enter.

The request traveled over the internet to the company’s load balancer. The load balancer, however, had a rudimentary security guard installed—a Web Application Firewall (WAF). The WAF inspected the incoming text. It saw the words metadata.google.internal and blocked the request immediately.

"Access Denied," the firewall effectively said. "Nice try."

Zero smiled. They knew how to bypass old firewalls. You don't speak plain English; you speak in codes. They needed to URL-encode the request.

In URL encoding, characters are replaced by a % followed by their hexadecimal ASCII value. Zero typed the malicious payload into their terminal:

Zero transformed the URL into a slurry of characters that the WAF wouldn't recognize as a threat, but the underlying server would eventually decode.

The string became: http%3A%2F%2Fmetadata.google.internal%2FcomputeMetadata%2Fv1%2Finstance%2Fservice-accounts%2F

Crucially, all requests to the metadata server must include the header:

Metadata-Flavor: Google

Without this header, the server responds with a 403 Forbidden error. This prevents accidental or malicious cross-site request forgery (CSRF) from external websites.

The endpoint in question:

http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/

When you GET this URL (with the correct header), the metadata server returns a list of service accounts attached to the instance. Zero transformed the URL into a slurry of

That unassuming URL – http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/ – is a cornerstone of Google Cloud’s zero-trust, keyless authentication model. It allows any application running on a GCE VM to securely obtain Google API credentials without ever handling a private key.

Next time you set up a web app on Compute Engine and it just works with Cloud Storage or BigQuery, you now know the silent hero behind the scenes: the metadata server.

It is important to clarify that the string fetch-url-http-3A-2F-2Fmetadata.google.internal-2FcomputeMetadata-2Fv1-2Finstance-2Fservice accounts-2F appears to be a URL-encoded or partially sanitized representation of a request to the Google Compute Engine metadata server.

Specifically, the decoded endpoint is: http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/

This article provides a deep technical dive into this endpoint: what it is, why it exists, how to use it securely, common pitfalls (including the fetch interpretation), and its role in cloud-native applications.

There are two main reasons you see this URL in a fetch-url context: Without this header, the server responds with a

If you are seeing this in an error message (e.g., "Failed to fetch URL"), it is often because of a missing header.

Google requires a specific HTTP header to protect against Server-Side Request Forgery (SSRF) attacks. If a request hits this URL without the header, the server rejects it.

The Fix: If you are writing a custom script (using curl, Python requests, etc.) to hit this endpoint, you must include this header:

Metadata-Flavor: Google

Example cURL command:

curl -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email

(This command will return the service account email attached to your VM).