Secrets in git history

A git repository doesn't store just the current state of the code, but its whole history: every commit is a full snapshot. So deleting a password or token from the code and committing the change doesn't remove it: the secret is still accessible in the commit where it was introduced. It's one of the most common and rewarding mistakes to find after gaining access (or even from outside, if the .git is web-accessible).

When you find a repo (typically in /opt, /var/www, a user's home, or referenced in a .gitignore), review the whole history:

git -C <repo> log --oneline --all          # list commits
git -C <repo> show <commit>                # see a specific commit's diff
git -C <repo> log -p                        # history with diffs
git -C <repo> grep -i 'password\|token\|secret' $(git -C <repo> rev-list --all)

What usually turns up: API tokens, service keys (a CONSUL_HTTP_TOKEN, an AWS key), connection URLs with credentials, deleted .env files, passwords in "test" commits. Each can be the next link in the chain (authenticating against an internal service, escalating, etc.).

Note on modern git. Recent versions block operating on repos owned by someone else ("dubious ownership"); fix it with git config --global --add safe.directory <repo>.

It also pays to look at the corners log does not show up front:

git -C <repo> reflog                        # "lost" commits (rebase, reset)
git -C <repo> stash list && git -C <repo> stash show -p
git -C <repo> branch -a                     # forgotten remote branches

Tools. For large repos, gitleaks or trufflehog automate secret hunting across the whole history:

gitleaks detect --source <repo> -v
trufflehog git file://<repo> --only-verified

How to detect it. As with credentials in source, effective detection is proactive: gitleaks/trufflehog walking the whole history (not just HEAD) in a pre-commit hook and in CI find the secret before it spreads, which is the only real defence because a committed secret may already have been cloned. If the .git is web-exposed, the discovery phase leaves requests to /.git/ (HEAD, /.git/config, objects) in the access log, a signature a WAF flags (see .git dump). And the use of the found secret (an API token, a service key) is detected at the target service as an anomalous access with that credential.

Defence. Never commit secrets (use environment variables, secret managers, .gitignore from the start); if one leaks, rotate it (removing it from history with git filter-repo isn't enough: it may already have been cloned) and review access. Related to credentials in source and the web-exposed .git dump.