---
title: "Security Disclosure Recommendation: Check for Anomalous GCP Access"
description: "Learn how to Security Disclosure Recommendation: Check for Anomalous GCP Access"
date: 2026-10-22T00:46:47.651Z
authors: ["Mykal Machon"]
category: "Engineering"
url: https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-gcp-access
---

# Security Disclosure Recommendation: Check for Anomalous GCP Access

> This guide is part of Railway's response [to the security disclosure published on October 21, 2026](https://blog.railway.com/p/security-disclosure-wednesday-october-21st).

*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](https://docs.cloud.google.com/docs/security/compromised-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](https://console.cloud.google.com/iam-admin/serviceaccounts) 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](https://docs.cloud.google.com/iam/docs/keys-disable-enable).
   ```Shell
   gcloud iam service-accounts keys disable KEY_ID \
     --iam-account=railway-uploads@my-project.iam.gserviceaccount.com \
     --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](https://docs.railway.com/variables#shared-variables), 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](https://docs.railway.com/deployments/staged-changes). See [multiline variables](https://docs.railway.com/variables#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.
   ```Shell
   gcloud iam service-accounts keys delete KEY_ID \
     --iam-account=railway-uploads@my-project.iam.gserviceaccount.com

   ```

## 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](https://console.cloud.google.com/logs/query) 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="railway-uploads@my-project.iam.gserviceaccount.com"` 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](https://docs.railway.com/networking/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](https://docs.cloud.google.com/policy-intelligence/docs/activity-analyzer-service-account-authentication).
   ```Shell
   gcloud policy-intelligence query-activity \
     --activity-type=serviceAccountKeyLastAuthentication --project=my-project

   ```
6. If Security Command Center is enabled, open [Findings](https://console.cloud.google.com/security/command-center/findings) and run `access.principal_email="railway-uploads@my-project.iam.gserviceaccount.com"` in the query editor.
7. Open [Billing](https://console.cloud.google.com/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](https://docs.cloud.google.com/support) for help with logs or charges.

If you have any other questions, contact Railway support at <support@railway.com>.


---

Open this post in a browser: https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-gcp-access