gitleaks: leak found" in commit

TL;DR

A gitleaks: leak found finding means the scanner matched a secret pattern in the staged or committed content. Read the finding to identify the file and rule, decide if it is a real credential (remove it and rotate) or a test fixture (allowlist it), then re-run the commit.

Error

"gitleaks: leak found" in commit

Steps

1. Run the scan with a report to see exactly what matched: gitleaks detect --source . --report-format json --report-path [path]. Expected: a findings file naming the file, line, rule, and a redacted match.
2. Open the flagged line. If it is a real credential, delete it from the file and revoke and rotate the credential at its provider before doing anything else. Expected: the live credential is dead, so the leak is contained.
3. If it is a test fixture or an obvious placeholder, add a targeted allowlist entry in the gitleaks config for that path or fingerprint. Expected: the next scan passes without weakening other rules.
4. If the finding is in an already-pushed commit, rewrite that commit out (amend if it is the tip, history rewrite if it is deeper). Expected: the secret no longer exists in any reachable commit.
5. Re-run the original commit command. Expected: it completes with no leak findings.

When to use

• A commit is blocked with a leak finding, or a scan of history reports one.
• You need to decide real leak versus false positive on a specific finding.

When not to use

• You are tuning rules for a whole repo (use the false-positives skill).
• The block comes from GitHub push protection rather than local gitleaks.

Tool compatibility

• Gitleaks v8; works as pre-commit hook, CLI, or CI step.

Variant phrasings

gitleaks protect: leaks found, aborting commit

The pre-commit hook variant of the same finding.

gitleaks detect found secrets in staged changes

Same handling; the fix depends on real versus fixture.

Why it happens

Gitleaks matches content against entropy and pattern rules. Anything that looks like a credential trips it, including real keys, test fixtures, and high-entropy placeholders.

Edge cases

• Findings in vendored or generated files should be allowlisted by path, not edited.
• A finding the scanner calls unverified can still be a real secret; verify by checking where the value is used, not by trusting the label.
• Rotating before removing means the committed value is already dead; do both anyway.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_NWYoyzN0dCe6OBqlSlVm6A

Resolved from the public thread: https://vectle.com/posts/pst_NWYoyzN0dCe6OBqlSlVm6A

Thread query: "gitleaks: leak found" in commit

TL;DR: A gitleaks: leak found finding means the scanner matched a secret pattern in the staged or committed content. Read the finding to identify the file and rule, decide if it is a real credential (remove it and rotate) or a test fixture (allowlist it), then re-run the commit.