Your Developer Machine Was Hit by a Malicious Package, The 30-Minute Credential Rotation Checklist
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The TanStack supply chain attack on May 11, 2026 scanned over 100 credential file paths on every developer machine where the payload executed. If you ran npm install with @tanstack router packages during the 22-minute attack window, your credentials were stolen. This checklist covers every credential type a developer machine typically holds, organized by blast radius so you handle the highest-impact items first. Work through it sequentially, do not skip to the services you care about most, because attackers pivot through credential chains.
Before You Start: Determine Your Exposure Window
First, confirm whether you actually need to rotate. Check your npm install history:
cat ~/.npm/_logs/*.log | grep '@tanstack' | grep '2026-05-11'
Alternatively, check your shell history for npm install commands on May 11:
grep -h 'npm install\|npm i ' ~/.zsh_history ~/.bash_history 2>/dev/null | grep -E '2026-05-11|tanstack'
If you installed any @tanstack package on May 11, 2026 between approximately 19:00 and 19:45 UTC, treat your machine as fully compromised. If you are unsure of the exact time, err on the side of rotating everything.
Also check for the TanStack-specific LaunchAgent that provides persistence. On macOS:
ls ~/Library/LaunchAgents/ | grep -i 'gh-token\|tanstack\|user.'
If you see com.user.gh-token-monitor or similar, remove it immediately:
launchctl unload ~/Library/LaunchAgents/com.user.gh-token-monitor.plist
rm ~/Library/LaunchAgents/com.user.gh-token-monitor.plist
Priority 1: AWS Credentials (Highest Blast Radius)
AWS credentials give an attacker access to production infrastructure. Rotate these first.
Long-lived IAM access keys (~/.aws/credentials):
- Log into the AWS Console from a clean machine or browser profile
- Navigate to IAM > Your user > Security credentials
- Create a new access key
- Update ~/.aws/credentials with the new key on your machine
- Deactivate the old key (do not delete yet)
- Verify your applications still work with the new key
- Delete the old key
Check for unexpected IAM activity: Review CloudTrail for the last 30 days of API calls made with your IAM user credentials. Look for any action you did not take, especially CreateUser, CreateAccessKey, AttachUserPolicy, or any activity in regions you do not normally use.
Check for keys the attacker may have created: aws iam list-access-keys --user-name YOUR_USERNAME. If you see more than two access keys (the max AWS allows is two), the attacker created a key and you need to delete it.
Check for role assumption activity: If your IAM user can assume roles, check CloudTrail for AssumeRole calls and review every API action taken in those sessions.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Priority 2: GitHub Credentials
GitHub credentials give access to source code and CI/CD pipelines, and in many cases, to production secrets stored as GitHub Actions secrets.
SSH keys (~/.ssh/): List all private keys: ls ~/.ssh/.pem ~/.ssh/id_ 2>/dev/null
For every SSH key that is registered with GitHub:
- Go to GitHub Settings > SSH and GPG keys
- Delete the compromised key
- Generate a new key: ssh-keygen -t ed25519 -C 'your_email@example.com'
- Add the new public key to GitHub
- Update your SSH config if you use key aliases
Personal Access Tokens (PATs): Go to GitHub Settings > Developer settings > Personal access tokens. Revoke every token. Every application that uses a PAT needs a new one, update them one at a time so you do not break your tools.
GitHub CLI token: Run gh auth logout, then gh auth login to reauthenticate. The stored token in ~/.config/gh/hosts.yml is rotated automatically.
Check for unexpected GitHub activity: Review github.com/settings/security-log for the last 30 days. Look for OAuth application authorizations, repository clones, and workflow dispatches you did not initiate.
Priority 3: npm, Docker, and Package Registry Tokens
npm tokens give write access to packages published under your account, a compromised npm token is a vector for publishing malicious packages to your consumers.
npm tokens (~/.npmrc):
- Go to npmjs.com > Access Tokens
- Revoke every existing token
- Generate new automation tokens for each CI/CD system that publishes packages
- Update ~/.npmrc with the new token: npm set //registry.npmjs.org/:_authToken YOUR_NEW_TOKEN
Docker Hub credentials: Check ~/.docker/config.json for stored credentials. Log out: docker logout. Revoke all access tokens at hub.docker.com > Account Settings > Security. Log back in and generate new tokens.
Other package registries: Check ~/.npmrc for registries beyond npmjs.com (private registries, GitHub Packages, JFrog Artifactory). Rotate authentication tokens for each.
Priority 4: Cloud Provider CLI Credentials
GCP credentials: Run gcloud auth list to see what accounts are authenticated. Revoke: gcloud auth revoke --all. The stored credentials are in ~/.config/gcloud/credentials.db. Re-authenticate after rotation.
Azure CLI credentials: Run az account list. The stored tokens are in ~/.azure/msal_token_cache.json. Log out: az logout. Re-authenticate with az login.
Terraform state and provider tokens: If you use Terraform with remote state (Terraform Cloud, S3 backend), check for API tokens in ~/.terraform.d/credentials.tfrc.json and rotate them.
Kubernetes configs (~/.kube/config): Review every context in your kubeconfig for bearer tokens or client certificate credentials. Rotate credentials for any cluster you have write access to. For EKS, the credentials are typically short-lived (regenerated by aws eks get-token), but the underlying IAM credentials were already rotated in Priority 1.
Priority 5: SSH Keys for Non-GitHub Hosts
Your ~/.ssh directory likely contains keys for more than GitHub. Check the authorized_keys on every server you administer:
# List all SSH keys and their comments (comments often indicate the target host)
for key in ~/.ssh/*.pub; do echo "=== $key ==="; cat $key; done
For each key that is registered on a remote server:
- Generate a new key pair
- Add the new public key to the remote server's ~/.ssh/authorized_keys
- Test connectivity with the new key
- Remove the old public key from authorized_keys
- Delete the old private key locally
Also check SSH agent forwarding configurations. If you use SSH agent forwarding (ForwardAgent yes in ~/.ssh/config), any server you connected to with forwarding enabled had access to your agent socket and could have used your keys.
Priority 6: Remaining Credentials and Post-Rotation Verification
GPG keys: If you use GPG for git commit signing or email encryption, revoke the compromised key via your keyserver (gpg --keyserver keys.openpgp.org --send-keys) after generating a new one. Update your GitHub GPG key configuration.
macOS Keychain: Open Keychain Access and review entries for services you use. Rotate any API tokens or passwords stored there that the compromised process had access to.
Browser-stored credentials: If VS Code extensions or node processes had access to your home directory, Chrome and Firefox store credentials in files within the user profile. Consider rotating important passwords stored in your browser, or use a password manager that was not accessible from the compromised session.
Post-rotation verification checklist:
- Run aws sts get-caller-identity to confirm your new AWS credentials work
- Run gh auth status to confirm your new GitHub credentials work
- Run npm whoami to confirm your npm credentials work
- Check CloudTrail and GitHub audit logs 24 hours after rotation to confirm no activity under the old credentials
The bottom line
A supply chain compromise on a developer machine is a full credential incident, not just a malware cleanup job. The malware removal takes 10 minutes. The credential rotation takes 30. Skip the rotation and you leave active credentials in the hands of attackers who have already demonstrated they know how to monetize them.
Frequently asked questions
How do I know which credentials were actually stolen versus which ones might have been?
Assume everything accessible to the user session was stolen. The TanStack payload scanned 100+ credential paths. You cannot reliably determine what was exfiltrated without a full memory forensics capture. The safer assumption is complete compromise of every file readable by your user account.
Do I need to wipe my machine, or is credential rotation enough?
If you removed the malicious package and any persistence mechanisms (LaunchAgents, cronjobs, startup items), credential rotation is sufficient for most supply chain attacks. A full wipe is recommended if you have reason to believe a rootkit or kernel-level persistence was installed, which is unusual but not unheard of in sophisticated attacks.
How do I check for malicious LaunchAgents on macOS?
Run: ls ~/Library/LaunchAgents/ and /Library/LaunchAgents/ and compare against known legitimate entries. Legitimate LaunchAgents from Apple and common software have well-known names. An entry with a generic name like com.user.gh-token-monitor or com.apple.softwareupdate that you do not recognize is suspicious. Check the plist file to see what command it runs.
Should I change my GitHub account password as well?
Yes, if the compromised process could have read browser-stored credentials or password manager data. Also review GitHub's active sessions at github.com/settings/sessions and terminate any sessions you do not recognize.
What if I cannot rotate a credential immediately because it would break production?
Deactivate it rather than rotate it if your service supports deactivation (AWS IAM keys support this). A deactivated key cannot be used but can be reactivated if needed, giving you time to update the dependent service before deletion. Do not leave an active compromised credential live longer than absolutely necessary.
How do I determine whether an attacker used stolen credentials before I completed rotation?
For AWS IAM keys, query CloudTrail with a filter on the compromised access key ID: aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAEXAMPLE. Every API call made with that key in the prior 30 days is returned, including caller IP, region, and action. For GitHub tokens, review the organization audit log at Settings > Audit log and filter by the token's associated user. For npm tokens, check the npmjs.com access log under your account settings. Any action you did not perform, especially resource creation, privilege changes, or new credential issuance, indicates the attacker used the credential and you have a secondary incident to investigate.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.