Security Disclosure Recommendation: Check for Anomalous AWS Access

Author: Mykal Machon

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

If you use AWS access keys with Railway, deactivate any key that may have been exposed, review CloudTrail and billing for activity you didn't generate, and redeploy your services with a new key.

If an AWS access key pair (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) may have been exposed, or you see resources or charges you don't recognize, check for anomalous AWS access. AWS's guidance is to deactivate the key, replace it, review CloudTrail for what the key did, and delete anything it created.

This guide applies the guidelines from AWS's What can I do if I notice unauthorized activity in my AWS account?, extended to include Railway-specific operations. Access keys are long-lived, so an exposed key works until you deactivate it.

## Deactivate the key

AWS lets each IAM user hold two access keys, which gives you an overlap window. Deactivate first rather than delete, so you can reactivate briefly if a service you forgot about breaks.

1. Open the IAM console and enter the exposed access key ID in the search bar to find its user.
2. On the user's Security credentials tab, in the Access keys section, click Create access key to generate the replacement.
3. For the exposed key, click Actions and then Deactivate. Requests signed with the old key fail from this point.

See Update access keys for the full procedure.

## Update the key on Railway

An AWS access key on Railway is a pair of variables, so updating it is a variable edit and a redeploy.

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 picks up the change.
2. Edit AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to the new values, then deploy the staged change.
3. Confirm the new deployment is active and its logs show successful AWS calls, with no InvalidClientTokenId or SignatureDoesNotMatch errors.
4. Update anything outside Railway that used the old key, such as local development or CI.

## Review for misuse

CloudTrail records every management API call made with a key for 90 days, and IAM tracks when each key was last used.

1. Open the CloudTrail console and click Event history. Set Lookup attributes to AWS access key, enter the exposed key ID, and set the time range to the exposure window. See Working with CloudTrail event history.
2. Look for calls that aren't your application's: RunInstances, CreateUser, CreateAccessKey, AttachUserPolicy, CreateRole, PutBucketPolicy, and anything from a Region you don't use. Source IPs that aren't Railway's egress ranges point at the attacker.
3. Repeat the search in every Region. Event history is per Region, and attackers often launch resources in Regions you don't watch.
4. Download the credential report from the IAM console and look for users, keys, or passwords you didn't create.
5. Open Cost Explorer and compare the exposure window against the previous month
6. Delete resources, users, roles, policies, and keys the attacker created. Snapshot anything you need for forensics first.
7. If AWS Support sent an irregular-activity notification, reply in the Support Center with the actions you took.

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