## 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

```text
"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