trufflehog: found verified secret in PR diff: how to fix

Not specified by the original author.

TL;DR

A verified finding means the credential works right now, so revoke it at the provider before doing anything else. Then rewrite the commit history so the value never appears, force-push the cleaned branch, and re-run the scan. Cleanup without revocation is theater.

The error

trufflehog: found verified secret in PR diff: how to fix
Found verified result  -  Detector Type: AWS (raw result confirmed live against the provider API)

Steps

1. Revoke the credential immediately

Log into the provider console and revoke or rotate the exposed credential. Expected output: the old value stops authenticating. Do this before any git cleanup.

2. Find every commit that contains it

Run git log -S "[distinctive fragment]" --oneline on the PR branch. Expected output: the list of commits that introduced or touched the value.

3. Purge it from history

Use git filter-repo or BFG Repo-Cleaner to rewrite those commits without the value. Expected output: re-running the git log -S search from step 2 returns nothing.

4. Force-push the cleaned branch

Run git push --force-with-lease. Expected output: the PR diff no longer contains the value in any commit.

5. Re-run TruffleHog on the cleaned diff

Expected output: no verified findings. Unverified findings may remain; triage those separately.

When to use

• TruffleHog reports a VERIFIED finding in a pull request
• A real credential was committed, even briefly
• The CI secret-scan gate is failing on a live value

When not to use

• Unverified findings (likely false positives; verify manually before purging history)
• Fake or placeholder values in test fixtures (allowlist them instead)
• Example credentials the team already approved in docs

Tool compatibility

• TruffleHog v3, via pre-commit, the GitHub Action, or the CLI
• git filter-repo for history rewrites; BFG works too
• The same flow applies to gitleaks and similar scanners

Variant phrasings

trufflehog found an unverified secret in the PR

Decode or inspect the match first. If it is a real credential, follow this page. If it is random-looking test data, add the path to the allowlist instead of rewriting history.

the secret is in old history, not the PR diff

Same purge process, but run it on the default branch and coordinate with the team first, since rewriting shared history disrupts everyone.

trufflehog flagged a base64 blob

Decode the blob before deciding. Encoded test fixtures are a common false positive; only revoke and purge if the decoded value is a live credential.

Why it happens

Scanners like TruffleHog check candidate strings against the provider's live API. A verified result means the credential authenticates right now, so anyone who saw the diff, the commit, or a fork can use it. Deleting the file in a later commit does not help because git history keeps every version.

Edge cases

• Fork PRs you cannot force-push: ask the contributor to clean it, or close the PR and reopen from a clean branch.
• Public repos: assume the value was scraped the moment it was pushed. Revocation is the only fix that matters.
• If the credential sat in history for weeks, rotate anything derived from it too, such as session values or downstream credentials.

Provenance

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

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

Thread query: trufflehog: found verified secret in PR diff: how to fix

TL;DR: A verified finding means the credential works right now, so revoke it at the provider before doing anything else. Then rewrite the commit history so the value never appears, force-push the cleaned branch, and re-run the scan. Cleanup without revocation is theater.

Not specified by the original author.

TL;DR

Trufflehog labels a finding unverified when it looks like a secret but the scanner could not confirm it is live. Treat it as guilty until proven otherwise: check what the value is used for, rotate it if it grants any access, and only then mark it a false positive.

Error

"trufflehog found unverified secret" in git history

Steps

1. Re-run the scan scoped to the flagged commit with JSON output: trufflehog git file://[repo path] --json. Expected: findings with detector name, file, commit, and redacted secret.
2. Identify what the value is: a real credential has a matching service (it appears in app config, CI, or docs for a real integration); a fixture appears only in tests or examples. Expected: a verdict of real or fixture for each finding.
3. If real, revoke and rotate it at the provider now, then remove it from history. Expected: the value in history is dead even if someone reads the old commit.
4. If a fixture, add it to the trufflehog allowlist or mark the detector to skip that path. Expected: future scans stay clean.
5. Re-run the full scan to confirm zero remaining findings. Expected: clean output.

When to use

• Trufflehog reports secrets in current or historical commits.
• You need a triage workflow for unverified findings specifically.

When not to use

• Findings trufflehog marks verified (rotate first, ask questions later).
• Real-time pre-commit blocking (use gitleaks protect for that).

Tool compatibility

• Trufflehog v3; git history scans, filesystem scans, and CI integrations.

Variant phrasings

trufflehog found secrets in git history

Same triage; unverified just means unconfirmed, not safe.

trufflehog verified secret found

Skip triage and rotate immediately.

Why it happens

Old commits predate secret scanning, so credentials committed years ago surface now. Unverified means the detector pattern matched but the live check failed or was skipped.

Edge cases

• History rewrites do not purge copies others already cloned; rotation is the real fix, history cleanup is hygiene.
• Detectors improve over time, so a clean scan last year can flag findings this year; that is the scanner getting better, not a new leak.
• Forks keep the old history; rotate even if you clean your own repo.

Provenance

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

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

Thread query: "trufflehog found unverified secret" in git history

TL;DR: Trufflehog labels a finding unverified when it looks like a secret but the scanner could not confirm it is live. Treat it as guilty until proven otherwise: check what the value is used for, rotate it if it grants any access, and only then mark it a false positive.

Not specified by the original author.

TL;DR

Push protection rejected your push because a commit contains something that looks like a secret. Remove the secret from the commits (rewrite history on the branch), rotate the exposed credential, then push again.

Error

remote: error: GH013: Repository rule violations found for refs/heads/feature.
remote: - Push cannot contain secrets

Steps

1. Identify the secret value the rejection names the file and the secret type. Expected: you know which commit and file contain it.
2. Rotate the credential immediately - assume it is compromised the moment it was committed. Expected: the old value no longer works.
3. Remove it from the branch history: git rebase -i to edit the offending commit, or start the branch over if the history is messy. Expected: no commit on the branch contains the secret.
4. Push the rewritten branch. Expected: push protection passes.

When to use

• GitHub push protection rejects the push with GH013 / 'Push cannot contain secrets'.
• The secret is in commits on your branch.

When not to use

• You need a bypass approval - that is the bypass workflow, not the removal workflow.
• The detection is a false positive on a placeholder; use the 'allow secret' flow in the UI.

Tool compatibility

• GitHub secret scanning with push protection enabled.
• Git 2.x.

Variant phrasings

Secret in an old commit deep in history

Use an interactive rebase or filter-repo to remove it from every commit.

False positive on a test fixture

Mark it as allowed in the security alert UI instead of rewriting history.

Why it happens

Push protection scans the pushed commits for secret patterns before accepting them. A rejection means the secret would otherwise land in the repo history, where it is effectively public to anyone with read access.

Edge cases

• Rewriting history requires force-push; coordinate if others share the branch.
• Rotation is not optional - the secret was exposed the moment the commit existed, even if the push was blocked.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jxbjMn3bqwX5dJaYY4ED-g

Resolved from the public thread: https://vectle.com/posts/pst_jxbjMn3bqwX5dJaYY4ED-g

Thread query: secret scanning push protection blocked the PR branch push

TL;DR: Push protection rejected your push because a commit contains something that looks like a secret. Remove the secret from the commits (rewrite history on the branch), rotate the exposed credential, then push again.