Blind SSRF in secret scanning changes NHI verification risk

At a glance

What this is: This is an analysis of blind SSRF risks in a secret-scanning workflow, showing that verification requests can be influenced by scanned content and redirect handling.

Why it matters: IAM and NHI teams should care because verification logic around leaked secrets can itself become a trust boundary that reaches internal services.

👉 Read Truffle Security’s analysis of blind SSRF risk in secret-scanner verification flows

Context

Blind SSRF is a server-side request forgery pattern where the server makes an outbound request an attacker can influence, but the attacker cannot see the response. In secret-scanning workflows, that matters because credential verification often reaches out to external endpoints as part of confirming whether a discovered secret is live.

Here the governance problem is not secret detection itself but the extra network trust embedded inside verification flows. If scanned content can shape where the scanner connects next, a tool built to find exposed credentials can create a new internal reachability path that needs explicit governance in NHI operations.

Truffle Security’s analysis is about a hardening issue in a secret-scanning pipeline, not a demonstrated exploit path. That distinction matters: the control lesson is about reducing unnecessary outbound request surface before an exposure becomes operationally useful to an attacker.

Key questions

Q: How should security teams stop secret scanners from making unsafe outbound requests?

A: Treat verification as a separate trust boundary. Restrict destination domains, block loopback and unspecified addresses, and revalidate after redirects so scanned content cannot steer requests into internal services. The goal is not to stop scanning, but to ensure live-check logic cannot become a network-reachability primitive.

Q: Why do live credential checks in scanners create SSRF risk?

A: Because the scanner is making an HTTP request based on untrusted input. If the scanned secret, issuer, or discovery URL influences the destination, the tool may contact attacker-chosen hosts or internal services. Even without response access, the request itself can expose the organisation to unintended reachability.

Q: What breaks when a scanner follows redirects from untrusted issuer URLs?

A: The trust decision moves away from the original allowlist and into the redirect chain. That can let an apparently safe public URL resolve into localhost or another internal target, which defeats simple URL filtering and turns a verification feature into an SSRF path.

Q: Should teams separate secret detection from live verification?

A: Yes, when live verification requires outbound HTTP requests. Detection can often operate safely without network access, while verification adds a new trust boundary that needs governance, destination policy, and monitoring. If the scanner must reach out, the request surface should be tightly scoped and reviewed.

Technical breakdown

Why secret scanners create outbound trust

Many secret scanners do more than match patterns. They validate likely credentials by calling issuer endpoints, certificate URLs, or discovery documents to see whether the secret is live. That turns the scanner into an HTTP client that acts on untrusted input. If the scanned string controls the destination, the scanner can be induced to request attacker-chosen URLs. Even when the response is not readable, the request itself can still reach internal services, local endpoints, or metadata paths. That is why blind SSRF is a trust-boundary issue, not merely a data-exfiltration issue.

Practical implication: Treat credential verification endpoints as network-exposed attack surfaces, not as harmless validation helpers.

Redirects and localhost bypasses in verification flows

A common failure mode is relying on URL checks that only test obvious private ranges or loopback patterns. In this article, Truffle Security describes a localhost bypass in which 0.0.0.0 and redirect-following behaviour could steer requests toward internal targets. The technical lesson is that filters must account for parser differences, redirect chains, unspecified addresses, and library defaults. A scanner can appear safe at the first parse step and still become dangerous after the HTTP client follows redirects or interprets the address differently.

Practical implication: Review URL validation and redirect handling together, because either one can reopen internal request paths.

JWT issuer lookups and OpenID discovery as SSRF triggers

The JWT detector example shows how liveness checks can be coupled to issuer-based OpenID discovery. If the token’s issuer claim is attacker-controlled, the scanner may fetch discovery metadata from a destination the attacker chose, then follow redirects to internal hosts. This is not unique to JWTs. Any detector that resolves dynamic metadata from scanned content can inherit the same risk if it performs live HTTP lookups without strict destination controls. The architectural mistake is assuming verification traffic is non-sensitive simply because it is read-only.

Practical implication: Bind discovery lookups to approved domains and treat token-derived URLs as untrusted until policy enforcement is explicit.

Threat narrative

Attacker objective: The attacker’s objective is to steer verification traffic into internal or local targets through the scanner’s outbound trust path.

1. Entry occurs when an attacker supplies scanned content or a token value that influences a secret-scanning verification request.
2. Credential verification then sends outbound HTTP requests to attacker-influenced destinations, including discovery endpoints or localhost-adjacent targets.
3. Redirect-following and weak address validation can escalate the request path from an external URL to an internal host.
4. The impact is unintended internal reachability from the scanning service, expanding the trust boundary without any response theft.

Breaches seen in the wild

• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
• Red Hat Consulting GitLab breach 2025: Extortionists copied a Red Hat Consulting GitLab instance, exposing customer tokens, keys and database connection strings held in engagement reports.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Blind SSRF is a secret-scanning governance problem, not just an application bug: the scanner becomes a decision point that can be steered by attacker-controlled content. When verification traffic is built into detection, the tool is no longer only observing credentials, it is also initiating network actions. That expands the attack surface into the trust layer of NHI operations, where outbound requests need policy boundaries as much as inbound access does. The practitioner takeaway is to govern verification paths as part of the NHI control plane.

Credential verification assumes the request target is trustworthy enough to contact: that assumption breaks the moment scanned content can shape the URL, issuer, or redirect chain. This is a classic NHI trust boundary collapse because the workflow treats liveness checks as benign while they still exercise network reachability. The implication is that verification logic must be reviewed as a distinct control, not folded invisibly into detection engineering.

Redirect handling is a control surface, not an implementation detail: Go’s default redirect behaviour and weak loopback checks show how library defaults can override intended policy. A scanner that follows redirects from untrusted issuers can move from public endpoints to localhost or other internal hosts without any operator intent. Practitioners should treat HTTP client behaviour as part of the identity verification threat model, especially where scanned material can influence destination selection.

Outbound trust debt: secret scanners accumulate hidden trust obligations every time they reach out to validate a suspected credential. That debt becomes visible only when scanned content can redirect, resolve, or rebind the request path. The security model must therefore distinguish detection from verification, because verification is the step that crosses from observation into active trust and needs explicit control ownership.

Secret scanners sit at the intersection of NHI exposure and network abuse potential: they are built to find leaked credentials, yet they may also become a channel for internal reconnaissance if verification is too permissive. That does not mean the category is unsafe by design, but it does mean the governance model has to include destination allowlisting, strict HTTP client policy, and review of every detector that performs live lookups. The practitioner conclusion is to manage the scanner as an identity-adjacent service with its own threat model.

What this signals

Outward-facing verification needs the same governance discipline as any other identity-adjacent service: secret scanners that confirm credentials by reaching external endpoints must be managed as networked trust actors, not passive search tools. Once scanned input can influence request destinations, the control question becomes who is allowed to define that destination and under what policy.

Blind SSRF exposes an important control split between finding secrets and validating them: organisations often harden the detection layer while leaving the verification layer under-specified. The practical signal is that any workflow performing live lookups needs destination allowlisting, redirect control, and address-class filtering as first-class requirements, not implementation afterthoughts.

For practitioners

• Define an outbound request policy for secret scanners Allow only approved domains, block local and unspecified addresses, and review every detector that performs live verification against external endpoints.
• Harden redirect handling in verification flows Disable blind redirect following where possible, or enforce destination revalidation after every redirect hop before the request is sent onward.
• Separate detection from live liveness checks Use non-networked detection where feasible, and require explicit justification for any detector that turns scanned content into an HTTP request.
• Audit loopback and unspecified-address filtering Test scanner behaviour against 127.0.0.1, localhost, 0.0.0.0, and other special addresses to confirm the client cannot reach internal services.

Key takeaways

• Blind SSRF in secret-scanning workflows shows that verification traffic can become a trust-boundary issue even when no response data is exposed.
• The article describes redirect-following, loopback bypasses, and issuer-based lookups as the mechanisms that can steer requests toward internal hosts.
• Practitioners should separate detection from live verification and apply strict outbound policy to every scanner that makes HTTP requests from scanned content.

Key terms

• Blind SSRF: Blind server-side request forgery is a condition where an attacker influences a server to make outbound requests without seeing the response. In secret-scanning tools, the danger is not only exfiltration but also unintended network reach into internal services or localhost.
• Custom Verification Flow: A custom verification flow is an identity process that changes checks, sequencing, or escalation paths based on risk, user type, or transaction context. It allows organisations to apply stronger controls where needed and lighter friction where appropriate. This supports better fraud prevention without forcing every user through the same experience.
• Redirect-Following Behaviour: Redirect-following behaviour is the HTTP client pattern of automatically continuing to a new location when a server responds with a redirect. For identity and secret scanners, that behaviour can turn a seemingly safe lookup into a request against an internal host if destination revalidation is missing.
• Outbound Trust Boundary: An outbound trust boundary is the point where a system leaves passive observation and begins initiating network actions based on input it does not fully trust. For scanners and verification services, this boundary determines whether live checks are governed and constrained or left open to abuse.

What's in the full article

Truffle Security’s full post covers the implementation detail this analysis intentionally leaves at the control and governance level:

• Specific detector-level examples of where blind SSRF appeared in credential verification flows
• Code-level discussion of the localhost bypass and the ip.IsUnspecified() fix path
• JWT issuer and OpenID discovery behaviour that made redirect-following risky
• The disclosure context and hardening changes applied across reported issues

👉 The full Truffle Security post covers the detector examples, bypass mechanics, and hardening changes in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.