AWS access key leaked: what to do right now
Bots find these in minutes and spin up compute on your account. Speed matters more here than anywhere else.
1. Rotate it now
Revoke and reissue in the AWS IAM console
- 1Open IAM → Users → the user whose key leaked → Security credentials.
- 2Set the exposed access key to Inactive immediately. Do this before creating a replacement — deactivating is instant and reversible, deleting is not.
- 3Create a new access key, update your servers, and verify they work.
- 4Then delete the old key permanently.
Console: https://console.aws.amazon.com/iam/home#/users
2. What someone can do with it
- Depends entirely on the attached IAM policy. If it is broad, the practical answer is: everything in the account.
- The most common abuse is launching expensive compute for crypto mining — bills in the tens of thousands accumulate within hours.
- Read or delete S3 buckets, including anything with customer data or backups.
- Create new IAM users to keep access after you rotate the original key. Check for these specifically.
3. Check whether it was already used
Look for activity you did not cause
- 1Open CloudTrail → Event history and filter by the access key ID.
- 2Look for RunInstances calls in regions you never use — that is the mining pattern.
- 3Check IAM for users, roles or access keys created since the exposure. Attackers add persistence early.
- 4Open Billing → Cost Explorer and look for a step change in daily spend.
- 5If you find abuse, open an AWS support case immediately; AWS routinely waives fraudulent charges when reported promptly.
4. Find out how it leaked
AWS keys leak from committed .env files, from CI configuration, and from being pasted into frontend code for direct S3 uploads. Direct browser uploads should use a presigned URL generated on your server, never a raw access key.
Paste this into Cursor, Claude Code or your builder
Find every hardcoded credential in this project and move it out of the code. 1. Search all files — including client code, config files, and anything already committed — for hardcoded secrets: AWS keys, plus any string starting sk-, sk_live_, AKIA, ghp_, or variables named *_SECRET, *_TOKEN, *_API_KEY. 2. For each one, tell me the file, the line, and whether that code runs in the browser or on the server. 3. Move every real secret to a server-only environment variable. Do NOT use a client-exposed prefix (VITE_, NEXT_PUBLIC_, REACT_APP_) — those are compiled into the browser bundle. 4. Any provider call that needs the secret must happen server-side; change the frontend to call my own endpoint instead of the provider directly. 5. Check whether the secret is in git history, not just the current files. If it is, say so — removing it from HEAD does not remove it from history. Give me a list of every secret found, where it was, and what you changed.
This is one check out of 40+
Paste your site address and we run the whole list from the outside — leaked keys, open databases, unprotected pages — then hand you one prompt that fixes what we find. Free, about 30 seconds, no signup.
Check my site — free