Apache Druid proxy SSRF shows how URL parsing confusion breaks defenses

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Xbow's research: CVE-2025-27888 in Apache Druid's management proxy turned URL parsing confusion into a server-side request forgery path.

Why it matters: This matters because management proxies can become internal request channels unless teams validate destination handling, constrain backend reachability, and patch quickly.

Context

URL parsing confusion happens when a system interprets the same address string differently at different stages of request handling. In a proxy, that mismatch can let attacker-controlled input reach internal resources that normal request filters were meant to block, which is why this class of issue matters for management planes as well as public endpoints.

Apache Druid’s proxy path is a good example of how a control surface can be more exposed than it first appears. The security question is not only whether an endpoint is reachable, but whether its request handling rules preserve the same trust boundary from user input through to backend access.

Key questions

Q: What breaks when URL parsing differs between a proxy and its backend?

A: A proxy can validate one destination while the backend resolves another, which can turn a seemingly safe request into SSRF. The failure is a broken trust boundary, because security checks and execution no longer operate on the same URL interpretation. Teams should canonicalise once and enforce that result throughout the request path.

Q: Why are management proxies especially risky when SSRF is possible?

A: They often sit close to internal services and may be allowed to reach resources that external users cannot. If an attacker can steer the destination, the proxy can become an unintended internal request channel. That is why egress control and destination allowlisting matter as much as input validation.

Q: What are the signs that URL parsing logic is failing safely?

A: Watch for inconsistent handling of encoded characters, redirects, mixed absolute and relative URLs, and destinations that pass validation but resolve differently at runtime. If the application and backend disagree on the request target, the control is not really working. The safest signal is that every ambiguous input is rejected before routing.

Q: How should security teams reduce SSRF risk in management proxies?

A: Start by restricting where the proxy can send requests, then validate that every URL is canonicalised before use. Add deny rules for internal ranges, metadata endpoints, localhost, and alternate schemes. Finally, separate administrative proxy functions from user-facing traffic so untrusted input never reaches privileged internal fetch paths.

Technical breakdown

How URL parsing confusion turns a proxy into an SSRF path

URL parsing confusion appears when components disagree about what part of a string is the host, path, scheme, or authority. In proxy-style endpoints, one layer may validate a request against a safe destination while another layer later resolves the same string differently and sends traffic to an internal target. That gap is what makes server-side request forgery possible. The risk rises when the proxy can reach management, metadata, or service networks that users cannot access directly. Practical implication: validate and canonicalise URLs before routing, then enforce the same interpretation at every downstream hop.

Practical implication: normalise destination parsing once and apply consistent allowlisting before any internal request is made.

Why management proxies increase blast radius

A management proxy is not just another application endpoint. It often sits near privileged internal resources and may be allowed to reach services that are otherwise segmented away from users. When that proxy accepts attacker-influenced destinations, the issue stops being a simple input-validation bug and becomes a trust-boundary failure. The main architectural problem is that the proxy can act with the network reach of an operator tool while exposing the input surface of a web application. Practical implication: treat management proxies as privileged egress points, not generic web handlers.

Practical implication: segment management-plane egress and restrict which upstream destinations a proxy can ever contact.

Why old SSRF patterns still matter during testing

Security testing is more effective when defenders and researchers understand prior weakness patterns in the same product or component family. That does not mean a previous CVE predicts the next one exactly. It means earlier SSRF cases can highlight which endpoint families, parsing conventions, and extension points deserve the most scrutiny. In Apache Druid’s case, the search for a new flaw followed historical proxy and query-path hypotheses before landing on the management proxy. Practical implication: use prior incident patterns to prioritise review of similar routing and parsing logic.

Practical implication: map prior SSRF findings to adjacent code paths and test them for the same trust-boundary mistakes.

Threat narrative

Attacker objective: The attacker aims to make the proxy fetch internal resources on their behalf and bypass normal network reachability limits.

1. Entry occurred through attacker-controlled input sent to the Apache Druid management proxy.
2. URL parsing confusion let the proxy interpret the destination in a way that could trigger server-side request forgery.
3. The resulting request path could reach internal resources through a management interface that should have stayed constrained.
4. Impact is exposure of internal services or data through a privileged proxy channel rather than direct external access.

Breaches seen in the wild

• Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

URL parsing confusion is a trust-boundary failure, not just a validation bug. When a proxy and its backend components disagree about what a URL means, security controls can approve one interpretation while execution follows another. That mismatch is especially dangerous in management planes because they often sit close to internal resources. Practitioners should treat parsing consistency as part of access control, not only input hygiene.

Proxy endpoints create a privileged path that deserves privileged governance. A management proxy can inherit network reach that users do not have, which means its abuse can collapse segmentation assumptions. This is the point where application security and network security intersect: the proxy becomes a controlled egress gateway unless the organisation deliberately constrains it. Teams should review proxy reachability as a governance issue, not a routing convenience.

Past SSRF incidents are useful threat models when the code path is similar. The article shows how earlier Druid SSRF experience helped focus testing on adjacent endpoint families and eventually on the management proxy. That is a reminder that recurrence often comes from shared design patterns, not identical lines of code. Security programmes should use prior findings to identify the next likely parsing or routing failure, then test those paths first.

Strict destination handling is the right mental model for this class of exposure. If a management service can resolve attacker-influenced destinations, the organisation has granted it a form of implicit internal reach that should be tightly governed. This is not only a web vulnerability pattern, it is an identity and authorisation problem for network-reachable services. Practitioners should define and enforce what the proxy is allowed to contact, then verify that behaviour continuously.

From our research library:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Proxy SSRF becomes much harder to contain when teams assume private or internal destinations are inherently safe. Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), according to the State of Secrets Sprawl 2026. The broader lesson is that any control path with internal reach needs explicit destination governance, not just perimeter trust.

URL parsing consistency should be treated as an architectural control. If one component reads a destination differently from the next, the organisation has already lost the security decision before the request is sent. For practitioners, the relevant question is whether every proxy, gateway, and extension path applies the same interpretation before any internal hop is allowed.

For practitioners

• Harden URL canonicalisation in proxy code Ensure every proxy decision uses one canonical URL interpretation before any outbound request is made, and reject ambiguous encodings, mixed host forms, and parser edge cases.
• Restrict management-plane egress destinations Allow the proxy to contact only explicitly approved internal services, and block all other outbound destinations at the network and application layers.
• Test adjacent endpoint families for shared parsing flaws Re-check other proxy, query, and extension endpoints that handle URLs or backend routing, because one SSRF issue often exposes a broader pattern.
• Treat management interfaces as privileged attack surfaces Review who can reach management functions, what those functions can call internally, and whether segmentation still holds when the interface is abused.

Key takeaways

• URL parsing confusion can convert an ordinary proxy into an SSRF conduit when validation and execution interpret the same destination differently.
• Management proxies deserve tighter destination governance than standard web endpoints because they can reach internal services by design.
• The most effective controls are canonicalisation, strict outbound allowlists, and review of adjacent routes that reuse the same parsing logic.

Key terms

• Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.
• URL Canonicalisation: URL canonicalisation is the process of turning a potentially ambiguous address into one consistent, machine-resolved form before it is used. In security controls, canonicalisation helps ensure validation, allowlisting, and routing all operate on the same interpretation of the destination.
• Management Proxy: A management proxy is a service that relays requests through an administrative interface to internal systems or resources. It can be useful for operators, but it also creates a privileged network path that must be tightly constrained because any attacker control over its destinations can become internal access abuse.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity control choices to the broader security decisions their programmes depend on.