What Happens When You Accidentally Commit a .env File to GitHub
You just ran git push and immediately realised your .env file was in the commit. Here is exactly what happens next β and what you need to do in the next 10 minutes.
What happens in the seconds after you push
If your repository is public, automated bots are scanning GitHub's public event stream in real time. Researchers have documented these bots finding and exploiting AWS keys within 40 seconds of a public push. The bots are not manually operated β they are automated pipelines that spin up EC2 instances, send spam, mine crypto, or exfiltrate data immediately.
If your repository is private, the risk is lower but not zero: repo access can be granted through OAuth tokens, collaborator accounts, or GitHub App installations you may have forgotten about.
Assume the key is compromised the moment it hit the push.
Step 1: Rotate every exposed secret β now
Before you do anything with git, go to each service and rotate the credentials. This is more important than cleaning the history. Cleaning history is about preventing future exposure; rotation stops the active breach.
- β‘AWS: IAM β Users β Security Credentials β delete access key, create new
- β‘Stripe: Dashboard β Developers β API Keys β Roll key
- β‘OpenAI: platform.openai.com β API Keys β delete, create new
- β‘Twilio: Console β Account Info β Auth Token β Rotate
- β‘GitHub Personal Access Tokens: Settings β Developer settings β Tokens β delete
- β‘Database credentials: change password directly in your DB admin panel
Step 2: Remove the file from git history
Simply deleting the file in a new commit does not remove it from git history. Anyone with repository access can still check out the old commit and read the secrets.
The recommended tool is git-filter-repo (the official successor to BFG Repo Cleaner):
# Install pip install git-filter-repo # Remove .env from every commit in history git filter-repo --path .env --invert-paths # Force-push the rewritten history git push origin --force --all git push origin --force --tags
If you can't use git filter-repo, BFG Repo Cleaner is an alternative:
java -jar bfg.jar --delete-files .env myrepo.git cd myrepo.git && git reflog expire --expire=now --all && git gc --prune=now --aggressive git push origin --force --all
Important: All collaborators must re-clone after you force-push the rewritten history. Any stale local clone still contains the old commits.
Step 3: If the repo was public β contact GitHub support
Even after you force-push, GitHub caches refs. Submit a cached data removal request at support.github.com β βRemove sensitive dataβ. GitHub will purge the cached objects from their CDN.
GitHub also has an automated secret scanning service that may have already flagged your push and notified the service provider (e.g., AWS, Stripe) β check your email for notifications from those providers.
Step 4: Check your cloud logs for unauthorized activity
If keys were exposed for more than a few minutes, check for unauthorized usage before assuming everything is fine:
- πAWS CloudTrail: look for API calls from unfamiliar IPs in the last hour
- πStripe: Dashboard β Logs β filter by timestamp, look for unexpected charges
- πGitHub: Settings β Security log β look for unexpected OAuth grants or API calls
- πYour hosting provider: check for new instances, unusual outbound traffic
How to prevent this from happening again
The best prevention is layered β any one of these would have stopped the incident:
.gitignore first
Add .env* to .gitignore before your first commit β not after you've already committed secrets.
Pre-commit hook
Use Husky + secretlint or detect-secrets. The hook runs before git commit and blocks it if secrets are found.
GitHub secret scanning
Enable GitHub's free secret scanning in your repo settings. It alerts you on push and notifies service providers automatically.
Sanitize before sharing
When sharing config with a teammate or contractor, run it through the .env Sanitizer first β it redacts 15+ secret patterns instantly in your browser.
The 10-minute checklist
- 1Rotate every exposed credential at the source service
- 2Run git filter-repo to remove .env from full history
- 3Force-push rewritten history to GitHub
- 4Tell all collaborators to re-clone
- 5Submit cached data removal to GitHub support (if repo was public)
- 6Check CloudTrail / service logs for unauthorized activity
- 7Add .env* to .gitignore if not already present
- 8Install a pre-commit hook to catch future incidents
Use the .env Deep Sanitizer to create a safe .env.example for sharing with your team β it redacts secrets in your browser, no uploads needed.
Try the related tool
.env Deep Sanitizer β free, runs 100% in your browser.
Open .env Deep Sanitizer βEnjoyed this? Get notified when Pro launches.
