Security Disclosure Recommendation: Check for Anomalous GCP Access

Author: Mykal Machon

This guide is part of Railway's response to the security disclosure published on October 21, 2026.

If you use a Google Cloud service account key with Railway, disable it if it may have been exposed, review Cloud Audit Logs for activity you didn't generate, and redeploy your services with a new key.

If a service account key file (the JSON you store in a variable such as GOOGLE_APPLICATION_CREDENTIALS_JSON) may have been exposed, or you see resources or charges you don't recognize, check for anomalous Google Cloud access. Google's guidance is to revoke and reissue the credential, then review Cloud Audit Logs for what it did.

This guide applies the guidelines from Google's Handling compromised Google Cloud credentials, extended to include Railway-specific operations. By default, service account keys don't expire, so an exposed key works until you disable it.

## Disable the key

Disabling a key blocks new authentication with it. Short-lived tokens already issued from the key stay valid for up to an hour, so disable the service account itself if you need to cut off access immediately.

1. Open the Service accounts page, select the project, and open the service account that owns the key. The key ID is the private_key_id field in the JSON file.

2. On the Keys tab, click Add key and then Create new key to generate the replacement JSON. The JSON file downloads once. Google doesn't keep a copy.

3. Disable the exposed key. The console can't disable keys, so use the CLI. Your Railway services can't authenticate with it from this point until you deploy the new key in the next section. See Disable and enable service account keys.

   gcloud iam service-accounts keys disable KEY_ID \
     [email protected] \
     --project=my-project
   

4. If you need to stop access now rather than within an hour, disable the whole service account from its Details tab, or apply an IAM deny policy to it. Every workload using the account loses access until you re-enable it, including your Railway service with the new key. Wait at least 60 minutes before you re-enable it, so tokens issued from the exposed key have expired.

5. Review the account's IAM roles and remove any you don't recognize, in particular Service Account Token Creator on other accounts.

## Update the key on Railway

On Railway, a service account key is usually one multiline variable holding the JSON, so updating it means editing the variable and redeploying.

1. Open the service that uses the key and click Variables. If the key is a shared variable, edit it once in Project Settings and every service that references it gets the new value when you deploy.

2. Set the variable to the new JSON. Variables can hold multiple lines, so paste the file contents as-is, then deploy the staged change. See multiline variables.

3. Confirm the new deployment is active and its logs show successful Google API calls, with no invalid_grant or PERMISSION_DENIED errors.

4. Update anything outside Railway that used the old key, such as local development or CI, then delete the old key once the new deployment has run cleanly and you've finished the review below.

   gcloud iam service-accounts keys delete KEY_ID \
     [email protected]
   

## Review for misuse

Admin Activity audit logs are always on and record every configuration change by every principal. Data Access logs, which record reads and writes of your data, are off by default except for BigQuery.

1. Open Logs Explorer in the affected project and set the time range to the exposure window.

2. Query for everything the service account did. Enter logName:"cloudaudit.googleapis.com" on one line and protoPayload.authenticationInfo.principalEmail="[email protected]" on the next, replacing the email with the exposed account's.

3. Look for calls that aren't your application's: new service accounts or keys, new IAM bindings, new Compute Engine instances, new Cloud Storage buckets, and project-level SSH keys. If your services use static outbound IPs, calls from any other IP point at the attacker. Without them, your services egress from shared Railway IPs, so an unfamiliar IP is a lead rather than proof.

4. Check whether the key was used to impersonate other accounts by filtering on protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail.

5. Confirm the key's last authentication date with Activity Analyzer. See View recent usage for service accounts and keys.

   gcloud policy-intelligence query-activity \
     --activity-type=serviceAccountKeyLastAuthentication --project=my-project
   

6. If Security Command Center is enabled, open Findings and run access.principal_email="[email protected]" in the query editor.

7. Open Billing reports and compare the exposure window against the previous month by service and SKU. Compute, GPU, and Vertex AI usage are the common targets.

8. If you find resources, service accounts, keys, or IAM bindings the attacker created, keep a copy of anything you need for forensics, then delete them.

9. Optional: open a case with Cloud Customer Care for help with logs or charges.

If you have any other questions, contact Railway support at [email protected].