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

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

import requests

METADATA_URL = "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
headers = "Metadata-Flavor": "Google"


response = requests.get(METADATA_URL, headers=headers)
response.raise_for_status()
token_data = response.json()
access_token = token_data["access_token"]

If you have ever deployed an application on Google Compute Engine (GCE), Google Kubernetes Engine (GKE), or Cloud Run, you have likely encountered the magical, link-local address 169.254.169.254 or the DNS name metadata.google.internal. Among the most critical—and frequently misunderstood—endpoints on that server is the service accounts path: /computeMetadata/v1/instance/service-accounts/.

The encoded string that prompted this article—fetch-url-http-3A-2F-2Fmetadata.google.internal-2FcomputeMetadata-2Fv1-2Finstance-2Fservice accounts-2F—is a classic example of a URL that has been double-encoded or mishandled in logging systems, scripts, or configuration files. Understanding the raw, decoded endpoint is essential for any developer or DevOps engineer working with Google Cloud. import requests METADATA_URL = "http://metadata

Google Cloud client libraries (like the Python google-cloud-storage library or the gcloud CLI) are smart. When you run code on a GCP VM, the code automatically tries to contact this URL to retrieve an Access Token.

The flow usually looks like this:

If you see this in a debug log, it usually means your application is successfully looking for its identity.

Your keyword fetch-url-http-3A-2F-2F... is a typical example of a URL that was mistakenly encoded twice. Always decode before use: If you have ever deployed an application on

The string arrived at the application layer. The WAF saw a jumble of symbols (%3A, %2F) and didn't trigger a block. It passed the packet through.

The fetch-url function inside the inventory script received the input. The script, being helpful, automatically decoded the URL string before making the request.

Suddenly, the innocent request transformed back into the forbidden address: http://metadata.google.internal...

The server turned its head inward. It wasn't looking at the public internet anymore; it was looking at itself. It sent a GET request to its own metadata server. If you see this in a debug log,

If you run curl http://metadata.google.internal from your laptop, it will fail because the DNS name resolves to a local link address only within GCP.

The presence of fetch-url-http-3A-2F-2F... in a search term or log indicates a probable misencoding scenario. For example, someone might have written:

// Wrong: URL-encoding the entire URL
fetch(encodeURIComponent("http://metadata.google.internal/..."))

Or a logging system double-encoded an error message. The correct approach is to never URL-encode the base URL of the metadata server. Only query parameters (if any) should be encoded.

All requests to the metadata server must include the header:

Metadata-Flavor: Google

This prevents malicious websites from making server-side requests to the internal endpoint (SSRF protection). Without this header, the server returns a 403 Forbidden.