Your private key was exposed in code or config
Developers sometimes paste private keys into .env files, config files, or code during development. If this code is ever pushed to GitHub, shared with others, or your computer is compromised, that key is exposed. Hackers actively scan public repositories and compromised machines for exposed keys.
How this attack works
Developers often paste a private key or mnemonic into a .env file, a config, or a script 'just for testing.' If that ever reaches a GitHub repo, it's gone — bots scan new commits for key patterns continuously and sweep funds within minutes.
Keys also leak through committed .env files, shared gists, CI logs, screen shares, and info-stealer malware that reads project folders.
Any key that has touched a code file or a developer machine should be treated as permanently public.
Warning signs
- •A real private key or seed phrase was ever placed in code, a .env, or config.
- •That file may have been committed, pushed, shared, or logged.
- •Funds left an address you'd used for development or testing.
What to do right now
- •Never put real private keys in code, even temporarily
- •Use hardware wallets or separate development wallets for testing
- •Add sensitive files to .gitignore before creating them
- •Assume any key that touched a code file is compromised
- •Create a brand new wallet for real funds
Not sure this is what happened to you?
Run the 2-minute diagnostic