My GitHub Secrets Went Public

The Setup

I maintain both open source projects and private client work. For convenience, I had multiple git remotes configured on my machine. One project had both a private backup remote and a public fork.

You can probably see where this is going.

The Mistake

I was working late, finishing a feature for a client project. The codebase included a config.js file with database credentials. Yes, I know. Environment variables. I was going to fix it "soon."

I typed what I thought was a push to my private backup:

git push origin main

But my current directory wasn't what I thought it was. I was in the wrong project folder. And "origin" in that folder pointed to a public repository.

The push completed. I didn't notice for about 10 minutes.

The Discovery

I got an email from GitHub: "Secret scanning alert for repository name."

My heart stopped. I opened the email and saw it had detected:

• A database connection string with username and password
• An AWS access key
• A Stripe secret key

I sprinted to my computer and checked the repository. There it was. My client's entire codebase, including the config file with credentials, was now public.

The Scramble

The next 30 minutes were a blur of activity:

1. Made the repo private (this doesn't undo the exposure, but stops new access)
2. Rotated every credential in the config file
3. Changed the database password
4. Revoked and regenerated the AWS keys
5. Rotated the Stripe API key
6. Changed the JWT secret (which invalidated all user sessions)

Then came the embarrassing part: telling the client.

The Conversation

I called the client immediately. I explained exactly what happened, what was exposed, and what I'd already done to fix it.

The client was understandably concerned. We reviewed the logs together. There was no evidence of unauthorized access, but we couldn't be 100% certain. The credentials had been public for about 15 minutes.

What I Did Wrong

1. Credentials in Code

The fundamental problem. Even in a "private" project, credentials shouldn't be in code. Environment variables exist for a reason.

2. Multiple Remotes Without Safeguards

Having both public and private remotes configured is risky. It's too easy to push to the wrong one.

3. No Pre-push Hook

A pre-push hook could have scanned for secrets and blocked the push. I had one set up on my main projects but not on this one.

4. Not Double-Checking the Directory

I assumed I was in the right folder. A quick pwd or git remote -v would have shown me the mistake.

Changes I Made

Global Git Hooks

I set up global pre-commit and pre-push hooks that scan for common secret patterns. They run on every repository, not just the ones I remember to configure.

# ~/.config/git/hooks/pre-push
# Scans for common secret patterns before any push
if git diff --cached | grep -qE "(sk_live|AKIA|password\s*=)"; then
  echo "Potential secret detected. Push blocked."
  exit 1
fi

Removed Public Remotes from Private Projects

If a project is private, it has no public remotes. Period. If I need to create a public version, I do it in a separate, clean repository.

Prompt Shows Current Directory

I modified my shell prompt to prominently display the current directory and git remote. I can see at a glance where I am and where I'm pushing to.

Client Work on Separate Machine

Client work now happens on a separate development machine with no personal projects. Eliminates the chance of cross-contamination.

What GitHub Did Right

GitHub's secret scanning detected the exposed credentials within minutes and sent me alerts. For some services (Stripe, AWS), they also notified the providers, who revoked the credentials automatically.

This is a safety net, not a solution. But it limited the damage significantly.