Joe Leon

Contributor Spotlight: Strengthening TruffleHog's SSRF Protections

Contributor Spotlight: Strengthening TruffleHog's SSRF Protections

Joe Leon

Two security researchers recently reported blind SSRF variants in TruffleHog's credential verification flow. We patched all reported issues as a hardening measure and want to recognize the researchers who took the time to dig in. These reports do not represent security vulnerabilities in TruffleHog, and we will not be issuing CVEs or formal GitHub Security Advisories.

Background

When TruffleHog detects purported credentials, it makes outbound HTTP requests by design to verify whether discovered credentials are live. Because the input data being scanned is user-controlled, this design permits blind SSRF. Blind SSRF in this context means an attacker who controls scanned content can influence where some of those requests go, but cannot read the responses or exfiltrate data.

None of the reports of blind SSRFs discussed here demonstrated a concrete path to harm. We still patched all reported issues as a hardening measure because reducing the unnecessary outbound request surface is a good practice. You can read our full policy in our SECURITY.md, and we'll be publishing a deeper discussion on threat modeling a secret scanner soon.

Ritvik Arya, Independent Security Researcher

Ritvik submitted two reports of blind SSRF, covering multiple detectors. The first was in the GCP detector, where the fetchServiceAccountCerts function fetched a URL directly from scanned content with no SSRF protection (see our PR). The second found a bypass in TruffleHog's existing isLocalIP check: 0.0.0.0 routes to localhost on Linux and macOS, but Go's net.IP methods don't flag it. This would allow an attacker to cause TruffleHog to make an HTTP GET request to localhost. The code modification added an ip.IsUnspecified() check (see our PR). Ritvik also flagged several detectors using HTTP clients with no IP restrictions at all.

Gaëtan Ferry, GitGuardian

Gaëtan identified a blind SSRF in TruffleHog’s new JWT detector. When performing liveness verification, the detector fetches OpenID discovery endpoints based on the token's issuer claim. Gaëtan demonstrated that an attacker-controlled JWT could redirect these requests to internal hosts (e.g., localhost) by exploiting Go's default redirect-following behavior (see our PR). He provided well-documented references to blind SSRF chain research from Assetnote and Sonar, and we appreciated the constructive back-and-forth during disclosure. 

Thank You

We sincerely thank both Gaëtan and Ritvik for their work. Responsible disclosure from security researchers makes TruffleHog stronger for everyone. TruffleHog auto-updates by default, so most users are already running the patched version.

If you find a security issue in TruffleHog, report it to [email protected]. For details on what we consider in-scope, check our SECURITY.md.

infra