fix: validate location input to prevent SSRF via URL fragment injection

[adilburaksen]

Summary

Vulnerability

The location field from the secrets: action input is used verbatim in URL construction inside src/client.ts:

const endpoint = ref.location
  ? this._endpoints.secretmanager.replace(
      'https://secretmanager.',
      `https://secretmanager.${ref.location}.rep.`,
    )
  : this._endpoints.secretmanager;

No format validation is applied to ref.location anywhere in the parsing path (src/reference.ts). This means an attacker who can influence the secrets: input (e.g. through a compromised dependency that writes workflow files, or a pull-request workflow with insufficient trust controls) can inject characters that manipulate the constructed URL:

Payload	Constructed URL	Effect
attacker.com#	https://secretmanager.attacker.com#.rep.googleapis.com/v1/...	Fragment truncates the real hostname; request goes to attacker.com
attacker.com?x=	https://secretmanager.attacker.com?x=.rep.googleapis.com/v1/...	Query string swallows the real hostname; request goes to attacker.com
attacker.com@evil.host	URL with user-info redirect	Request routed to evil.host

In all cases the HTTP client sends a GCP Bearer token (Authorization: Bearer <token>) to the attacker-controlled host.

Root Cause

src/reference.ts — the Reference constructor — splits and trims the secret reference string but does not validate the extracted location segment against any expected format before storing it.

Fix

Added a regex guard at the end of the Reference constructor, covering every code path that can set this.location:

if (this.location && !/^[a-z]+-[a-z0-9]+$/.test(this.location)) {
  throw new Error(
    `Invalid location format: "${this.location}". Must be a valid GCP region (e.g. "us-central1", "europe-west4").`,
  );
}

This matches the real GCP region naming convention (us-central1, europe-west4, northamerica-northeast1, etc.) and rejects any value containing #, ?, @, uppercase letters, or other URL-special characters before it can reach the HTTP client.

Four new test cases were added to tests/reference.test.ts covering #, ?, @, and uppercase injection payloads. All 24 tests pass.

Test plan

• npm test — 24/24 pass, including 4 new injection test cases
• Existing location-based reference formats (us-central1, europe-west4) still parse correctly (covered by existing test out:projects/my-project/locations/my-location/secrets/my-secret)
• attacker.com#/my-secret/latest → throws Invalid location format
• attacker.com?foo=/my-secret/latest → throws Invalid location format
• attacker.com@evil.host/my-secret/latest → throws Invalid location format
• US-CENTRAL1/my-secret/latest → throws Invalid location format

Files changed

• src/reference.ts — validation guard added to Reference constructor
• tests/reference.test.ts — 4 new test cases for malicious location payloads

[adilburaksen]

Flagging the security context for prioritization:

A consumer workflow that passes any user-influenced value into the secrets: input (e.g. via workflow_dispatch inputs or a dynamic secrets list) is vulnerable to GCP access token exfiltration. The token scope is https://www.googleapis.com/auth/cloud-platform — full Cloud Platform access for the workflow's service account.

The attack requires no interaction beyond the workflow run itself:

1. Attacker supplies a secrets: value with location: attacker.com#
2. The action constructs https://secretmanager.attacker.com#.rep.googleapis.com/...
3. Node.js URL parsing treats # as a fragment delimiter → host resolves to secretmanager.attacker.com
4. The Authorization: Bearer <token> header is sent to the attacker's host on the first request (no redirect needed, no header stripping)

This has been reported to Google Security (OSS VRP). The fix in this PR (regex validation of location before URL construction) is minimal and non-breaking. Happy to address any review feedback.

[adilburaksen]

Hi, just checking in — is there anything needed from our side to move this forward? Happy to rebase or address any review feedback.

[adilburaksen]

Gentle follow-up @verbanicm. This is one of a small cluster of same-class fixes across the org's actions where an unvalidated user-influenced input is substituted into the API endpoint, routing the request (with the GCP access token) to an attacker-controlled host — here via #/? in the location field surviving the split('/') in the Reference constructor. This PR validates location against the GCP region format before URL construction (4 tests added, CI green, CLA signed). Companion fixes: upload-cloud-storage#404 and deploy-cloud-functions#472. Happy to rebase — could you take a look when you have a moment? Thanks!