← All posts
STORIES

That Time Almost Caused a Security Disaster by Pushing Keys to GitHub

Summary

If you accidentally leak your security keys on GitHub, automated scanners might not warn you. Never assume you are safe just because you didn't get an email. If exposed, you must instantly revoke the token itself, not just delete the file.

Every developer has that moment that sends shivers down their spine. For me, it happened a few days ago during late-night study time. I was working on a toy project and mindlessly pushed my code to GitHub. Oops... I had forgotten to add .env to my .gitignore and pushed it entirely to a public repository.

What Happened

Usually, when keys are leaked, you expect GitGuardian or AWS to send a warning email saying "Your security keys have been exposed!" But... I didn't receive a single warning email. I still have no idea why.

What I had pushed to the public repo were my security credentials. Since I got no emails, I had absolutely no idea they were leaked and peacefully continued developing.

Why Is This So Scary? (The Recent Tving Security Incident)

Remember the massive Tving data breach affecting 13 million users that occurred in early June 2026?

The starting point of that catastrophic incident wasn't an advanced hacking technique, but an AWS access key exposed on an open-source platform (GitHub). Hackers stole the key leaked during development, accessed their internal database, and extracted CI, DI, and encrypted passwords for 13 million users. This single mistake has led to an ongoing massive class-action lawsuit.

What if someone's bot had scraped the keys from my public repo? They could have spun up hundreds of crypto miners on my account, leaving me with a bill for tens of thousands of dollars overnight, or completely wiped my small database.

My Action History (Trigger Warning: Terrifying)

Thinking about the Tving incident, a normal person would have deleted the keys and nuked the repo within 3 minutes. But looking back at my terminal history, here are the actions I actually took:

  1. Absolutely nothing: Because I didn't get a warning email, I didn't even know I was compromised.
  2. gh repo create tetris --public --source=. --push: I proudly created a public repository and pushed all my commits.
  3. vercel deploy: Then I cheerfully deployed it to Vercel.

I only realized this much later, and that's when the chills went down my spine. The most terrifying part is that my remediation steps were literally non-existent.

Lessons Learned

You might think "I'd never do that" or "I'll get a warning email," until you do and it destroys everything in one shot.

  • Set up .gitignore as naturally as breathing before doing anything else.
  • Never hardcode security keys in your code. As soon as they are issued, use environment variables or a Secret Manager.
  • Don't blindly trust automated alerts; manually check your code before you push.
  • (Added) It feels like locking the stable door after the horse has bolted, but right after this incident, I newly integrated GitGuardian to automatically detect any future key exposures.

Today, I've resolved to make a habit of checking git status three times before pushing code to GitHub. Everyone, please be careful with your credential management!

Play Now

GLOWTRIS

Free neon block puzzle. Play instantly in your browser!

🎮 Play Free →
glowtris.com

More in STORIES