Please report security issues to security@trufflesec.com and include
trufflehog in the subject line. If your vulnerability involves SSRF or
outbound requests, please see our policy for that specific class of
vulnerability below.
As part of its intended operation, TruffleHog makes network requests to upstream secret providers in order to verify liveness of each secret.
Truffle Security treats blind SSRF (i.e., the ability to induce outbound requests without data retrieval) as a hardening opportunity rather than a vulnerability.
We do not issue CVEs or formal advisories for reports showing outbound interactions unless they demonstrate a tangible security risk to users.
We will issue a CVE if a researcher demonstrates a clear exploit chain. For example:
-
Credential Exfiltration: Forcing TruffleHog to send third-party secrets (discovered during a scan) or the host's own environment credentials (e.g., IAM metadata) to an attacker-controlled endpoint.
-
Internal Exploitation: Using a blind request to trigger secondary vulnerabilities (e.g. RCE) on restricted internal services configured for defense-in-depth.
We will not issue a CVE for:
-
Reflected Payloads: Inducing a request to an attacker-controlled endpoint that requires the attacker to have write access to the scan input (i.e., the attacker receiving data back that they already had access to).
-
Basic Outbound Control: Demonstrating control over the request URL, Path, or Body, without demonstrating a path to credential leakage or internal system exploitation.
-
Service Probing: Simple open/closed port verification or basic interaction with internal services (e.g., triggering a GET request to a local web server) without a demonstrated compromise of data or system integrity.
-
Secondary Vulnerability Dependencies: Where the impact relies entirely on the pre-existing lack of authentication, misconfiguration, or known vulnerabilities of a third-party internal service.
To help us evaluate your report, please specify:
-
Level of Control: Which request components are controllable (Method, Host, Path, Headers, or Body)?
-
Secret Context: Can you prove that a legitimate secret that the attacker did not already have access to (i.e., not the attacker's payload) is attached to or contained within the outbound request?
-
Target Reach: Can the request reach restricted internal IPs (e.g., 127.0.0.1 or 169.254.169.254)?
-
Demonstrated Impact: What is the specific risk to a user or environment beyond a simple DNS/HTTP interaction?