Private Key Leaked on Ethereum? Save What's Left

Q: What if my contract uses OpenZeppelin Ownable2Step?

With Ownable2Step, the leaked deployer must call transferOwnership(newSafeAddress) (inside a private Flashbots bundle), and then your newSafeAddress must call acceptOwnership() in a subsequent transaction (or as Transaction 3 of the same Flashbots bundle) to finalize the transfer before the attacker can overwrite pendingOwner.

By Merunas Grincalaitis, founder of MEV DAO and a developer who builds MEV, sniping and trading bots on Ethereum. Last updated: October 2026.

TL;DR: If you have a private key leaked on Ethereum—most commonly by accidentally running git push with a .env or hardhat.config.js file to a public GitHub repository—automated GitHub Firehose bots scrape the key and drain your liquid ETH within 3 to 15 seconds, and deleting the commit or making the repo private will not un-compromise the key. Stop sending ETH to the address immediately, rotate all other accounts derived from that seed phrase, and use an atomic Flashbots bundle (eth_sendBundle) or EIP-7702 rescue batch to recover any remaining ERC-20 tokens, staked positions, LP tokens, or smart-contract ownership roles.

Every single week, a developer or trader messages me in a panic because an Ethereum private key leaked when they pushed a Hardhat, Foundry, or Next.js repo to GitHub with a .env file containing PRIVATE_KEY=0x... or MNEMONIC="...". Within ten seconds of git push, their native ETH vanished, and a relentless sweeper bot began watching the address.

Here is what happens behind the scenes when a private key leaked on Ethereum, why git push --force cannot save the key, and the step-by-step developer playbook to save every token, staking position, and smart contract owner role still attached to that address.

How GitHub secret-scanner bots find a leaked Ethereum private key in 5 seconds

Many developers assume that if they accidentally push a .env file to a brand-new, zero-star GitHub repository and delete the repo 30 seconds later, nobody could have seen it.

Unfortunately, dozens of blackhat botnets continuously subscribe to the GitHub Events API (https://api.github.com/events) and GH Archive firehose in real time:

Every public PushEvent across all of GitHub is streamed within 1 to 3 seconds of your git push.
Automated regex scanners match any 64-character hex string ([0-9a-fA-F]{64}) or 12/24-word BIP-39 mnemonic inside .env, hardhat.config.ts, foundry.toml, truffle-config.js, or Jupyter notebooks (.ipynb).
The bot derives the Ethereum address (secp256k1 → keccak256), queries balances across Ethereum mainnet, Arbitrum, Base, Optimism, Polygon, and BSC simultaneously, and immediately drains all native gas tokens (ETH, BNB, POL).
Worse, the leaked key is permanently added to the attacker's sweeper bot database (and often resold or leaked across wallet drainer github dumps), meaning if you ever send ETH to that address months later, it will be swept within 1 block.

Emergency 15-minute triage: What to do when your wallet is stolen or leaked

If you are searching wallet stolen what to do or stolen wallet what to do right after a key leak, execute these four steps in strict order:

Minute	Action	Critical Mistake to Avoid
Minute 0–2	Do NOT send ETH to the leaked address to "pay gas" for moving remaining ERC-20s or transferring contract ownership.	Any ETH sent via a normal transaction will be stolen by the sweeper bot before you can sign a second transaction.
Minute 2–5	Check if a seed phrase (`MNEMONIC`) leaked or just one private key. If a seed phrase leaked, immediately evacuate Account #2, #3, #4 and every L2 chain (Arbitrum, Base, OP) to a brand-new hardware wallet seed.	Creating a "New Account" inside the same MetaMask wallet uses the same compromised seed!
Minute 5–10	Inventory every non-liquid asset and smart contract role still tied to the leaked address on Etherscan + DeBank.	Attackers grab native ETH first; they often miss ERC-20s without Uniswap V2 pools, staked tokens, unclaimed airdrops, and `Ownable` contracts!
Minute 10–15	Revoke API keys (`ALCHEMY_API_KEY`, `ETHERSCAN_API_KEY`, AWS keys) that were in the same `.env` file.	Attackers use leaked RPC keys from your `.env` to run their own bots on your billing card.

For a broader victim checklist covering non-GitHub drains as well, see Wallet Drained? What to Do in the First Hour (Ethereum Checklist).

What developers forget: Rescuing `Ownable` smart contracts and protocol admin roles!

When a developer has an Ethereum private key leaked from a Hardhat or Foundry repo, the biggest financial risk is often not the 0.2 ETH that was sitting in the deployer wallet—it is the deployed smart contracts where that leaked address is still the owner, DEFAULT_ADMIN_ROLE, or upgrader (ProxyAdmin)!

If your leaked key is the owner() of a live token contract, vault, or treasury on Ethereum:

You cannot just send gas ETH to the deployer wallet and call transferOwnership(newSafeAddress) in the public mempool—the sweeper bot will steal the gas ETH immediately.
Instead, you must execute an atomic Flashbots bundle (eth_sendBundle) or EIP-7702 Type-4 transaction:
- Tx 1 (Clean Sponsor Wallet): Send exact gas (maxFeePerGas * gasLimit) to the leaked deployer address.
- Tx 2 (Leaked Deployer Address): Call yourContract.transferOwnership(newHardwareWallet) (or grantRole(DEFAULT_ADMIN_ROLE, newSafe) + renounceRole(DEFAULT_ADMIN_ROLE, leakedAddress)).

Because the bundle executes atomically inside a private builder (Flashbots, Titan, Beaverbuild), the sweeper bot never sees the gas funding in the mempool, and your smart contract's admin keys are transferred to safety in a single block!

Rescuing remaining ERC-20 tokens, LP positions, and airdrops from a leaked key

For ERC-20 tokens, NFTs, staked positions, or vesting streams still sitting in the compromised wallet:

Standard ERC-20s & NFTs: Use our open-source compromised-wallet-sweeper-rescue GitHub script and follow How to Rescue Tokens From a Compromised Wallet With a Sweeper Bot (Flashbots Guide).
If the attacker attached an EIP-7702 sweeper delegation (0xef0100...): A classic 2-transaction Flashbots bundle will revert when Tx 1 sends ETH into the attacker's malicious receive() fallback. Use an EIP 7702 Rescue vs Flashbots Bundles transaction where your clean wallet pays gas directly and overwrites the attacker's delegation in place.
Unclaimed airdrops & staked tokens: Read How to Claim an Airdrop From a Compromised Wallet (Before the Sweeper Does) and Unstake From a Compromised Wallet: Rescue Locked Tokens.

If you don't want to code the bundle under time pressure, use our automated MEV DAO Sweeper Bot Rescue Service.

How to prevent a `.env` private key leak in Foundry and Hardhat forever

Once you have rescued your remaining assets and abandoned the leaked address permanently, upgrade your local workflow so a plaintext private key never sits in a .env file again:

In Foundry (cast / forge): Import your deployer key into Foundry's encrypted keystore using cast wallet import my-deployer --interactive (which encrypts the key with scrypt under ~/.foundry/keystores/ and prompts for a password at runtime) instead of putting PRIVATE_KEY=0x... in .env.
In Hardhat: Use npx hardhat vars set PRIVATE_KEY (Hardhat Configuration Variables stored outside the project repo) or connect a hardware wallet via @nomicfoundation/hardhat-ledger.
Install gitleaks as a pre-commit hook: Add a global Git pre-commit hook (gitleaks protect --staged) that blocks any commit containing a 64-byte hex key or BIP-39 phrase before it ever leaves your laptop.

Frequently asked questions

If I delete my GitHub repo immediately after pushing a `.env` file, is my private key safe?

No. Automated bots scrape the public GitHub Events API firehose within 1 to 3 seconds of every git push. Even if you delete the repository or force-push a cleaned commit 10 seconds later, you must assume the private key is permanently compromised and stored in multiple sweeper bot databases.

Why did my ETH disappear on Arbitrum and Base when I only used the key on Ethereum?

Every EVM-compatible chain (Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Avalanche) uses the exact same secp256k1 elliptic curve and address derivation. A private key leaked from an Ethereum project gives the attacker full control over that exact 0x... address on every EVM chain simultaneously.

How do I transfer `Ownable` smart contract ownership from a leaked deployer key?

Never send ETH to the leaked deployer address in the public mempool. Instead, construct a 2-transaction Flashbots bundle (eth_sendBundle) where Transaction 1 sends exact gas ETH from a clean wallet and Transaction 2 calls transferOwnership(newSafeAddress) from the leaked deployer key in the same block—or use an EIP-7702 sponsored call.

What if my contract uses OpenZeppelin `Ownable2Step`?

With Ownable2Step, the leaked deployer must call transferOwnership(newSafeAddress) (inside a private Flashbots bundle), and then your newSafeAddress must call acceptOwnership() in a subsequent transaction (or as Transaction 3 of the same Flashbots bundle) to finalize the transfer before the attacker can overwrite pendingOwner.

Can I remove a sweeper bot from a leaked private key so I can use the wallet again?

No. Because a private key cannot be changed, anyone who has a copy of your leaked 64-character hex key can sign transactions for that address forever. You can rescue the tokens, NFTs, and contract roles out of the wallet using Flashbots, and you can clear an EIP-7702 delegation, but you must permanently retire the address after the rescue.

Related guides

Accidentally leaked a private key on GitHub and need to rescue ERC-20 tokens, staked assets, or Ownable smart-contract admin roles before the sweeper takes them? Use the MEV DAO Token Rescue Bot with a 3-day free trial at mevdao.org/subscribe, or message me urgently on Telegram (@merunas).