Apache Druid proxy SSRF shows how URL parsing confusion breaks defenses

At a glance

What this is: This is a vulnerability research write-up showing how Apache Druid’s management proxy was exposed to SSRF through URL parsing confusion.

Why it matters: It matters because management proxies can become internal reachability bridges, and identity and access teams need to understand how service-level trust, network assumptions, and privileged administrative paths can be abused.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Xbow's analysis of CVE-2025-27888 in Apache Druid

Context

Server-side request forgery happens when an application can be tricked into making requests on behalf of an attacker, often into internal services that are not normally reachable from outside. In this case, the issue sits in Apache Druid’s management proxy, where URL parsing confusion created a path from user-controlled input to internal request handling. The primary security question is not just whether the parser is robust, but whether administrative endpoints are allowed to act as a trust bridge.

For identity and access practitioners, the relevance is indirect but real. SSRF often becomes dangerous when a service can reach internal metadata, secrets, or authenticated control planes, which turns a web flaw into an access-control problem. That is why the boundary between application security and identity governance matters: service accounts, internal APIs, and privileged management paths all depend on assumptions about where trust begins and ends.

This is a classic case of an attack surface that is wider than it appears from the outside. The starting position, where a management proxy exists inside an administrative console, is common in enterprise software; the difference is whether the proxy can be constrained tightly enough to prevent internal resource abuse.

Key questions

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.

Q: Why do proxy-style application features create high-risk trust boundaries?

A: Because the application becomes an intermediary that can speak to internal resources the attacker cannot reach directly. If that intermediary accepts attacker-controlled destinations, network reach becomes an implicit privilege. The risk is highest when administrative convenience features are exposed through standard application interfaces.

Q: What do teams get wrong about SSRF defenses?

A: They often stop at URL parsing and blocklists. That misses redirects, DNS rebinding, alternate IP encodings, and network-layer reachability. A service that can still connect to private or link-local destinations remains vulnerable even if its input validation looks strict on paper.

Q: How should organisations respond when an internal fetch path is exposed?

A: Treat it as a privileged access issue. Disable or restrict the path immediately, review whether it can reach metadata services or admin APIs, and add monitoring for unusual internal destinations. Then patch the parsing flaw and retest any extensions or plugins that may expose the same pattern.

Technical breakdown

How URL parsing confusion creates SSRF reachability

URL parsing confusion occurs when a system interprets the same input differently at different layers, such as validation, routing, and outbound request handling. An attacker can exploit that mismatch by supplying a URL or path that appears safe to one component but resolves to a target the application should not contact. In proxy endpoints, this becomes especially risky because the application itself is being used as the network client. The core issue is not simply bad input, but inconsistent normalization and destination enforcement across the request path.

Practical implication: enforce strict allowlists and canonicalisation checks before any proxy-style request is sent.

Why management proxies are high-risk internal fetch primitives

Management proxies are often designed to help operators reach internal services through a central console, but that convenience can become a fetch primitive if the proxy accepts attacker-influenced destinations. Once an application can initiate requests to internal hosts, it may expose metadata services, admin endpoints, or other restricted resources. This is a governance problem as much as a coding problem, because the proxy inherits trust that should remain segmented. SSRF risk rises sharply when the proxy is reachable from broadly accessible interfaces or when internal routing rules are permissive.

Practical implication: segregate administrative proxies from user-facing paths and restrict what internal destinations they can resolve.

How prior CVE patterns shape modern exploit discovery

Attackers and advanced testers often reuse knowledge from older CVEs to hypothesise where a new implementation may fail. That does not mean the old exploit still works, but it narrows the search space around known weak points such as proxy endpoints, legacy handlers, or special parsing logic. In practice, this means modern vulnerability discovery is partly pattern matching across generations of flaws. Defenders should assume that well-known SSRF classes remain relevant wherever custom plugins, extensions, or admin abstractions expose internal connectivity.

Practical implication: review extensions and proxy features as repeatable SSRF candidates, not one-off code paths.

Threat narrative

Attacker objective: The attacker wants the application to make privileged internal requests that expose internal resources or enable further compromise.

1. Entry occurs through attacker-controlled input to the Apache Druid management proxy, where URL parsing confusion allows a crafted request to reach unintended destinations.
2. Escalation follows when the application is used as an internal request launcher, creating access to resources that should not be reachable from the original request context.
3. Impact is the ability to perform server-side request forgery against internal services or endpoints that were meant to stay isolated from untrusted input.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

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

NHI Mgmt Group analysis

URL parsing confusion is a control failure, not just a coding defect. When the same URL is interpreted differently across validation, routing, and outbound fetch logic, the application effectively creates two trust models at once. That mismatch is what makes SSRF durable across product generations. For practitioners, the lesson is to treat canonicalisation and destination allowlisting as governance controls, not optional hardening.

Management proxies expand the identity boundary of the application. A proxy that can reach internal endpoints is acting with delegated network authority, which makes it adjacent to non-human identity risk even when no service account is explicitly exposed. If that proxy can be influenced by untrusted input, the application becomes a privileged intermediary. The right framing is least reachability, not just least privilege.

History-driven exploit discovery is now part of the threat model. The article shows how prior CVEs inform attacker hypothesis generation, especially around proxy endpoints and legacy SSRF patterns. That means vulnerability management has to include recurrence risk, not just patch verification. For security teams, old bug classes remain live wherever implementations preserve their shape.

Internal request paths need the same scrutiny as privileged credentials. SSRF turns network reach into a form of implicit privilege, and that privilege can be abused just like a leaked token or over-scoped service account. This is where application security and NHI governance intersect: both are managing who or what can reach sensitive internal resources. Practitioners should classify internal fetch capability as a privileged capability that demands explicit restriction and monitoring.

Proxy extensions and plugins create hidden blast radius. The vulnerability was found in a management proxy path, which is exactly the kind of feature teams often assume is narrow and safe because it is intended for administration. In practice, extensions frequently broaden the internal attack surface faster than teams document it. The operational conclusion is simple: inventory every internal-fetch path and test it as if it were an external trust boundary.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• From our research: Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For practitioners: Use The 52 NHI breaches Report to compare how weak trust boundaries and exposed access paths repeatedly turn into identity compromise.

What this signals

Internal fetch capability should now be treated as a privileged control surface. Even when the flaw is framed as SSRF, the operational consequence is the same as an over-scoped non-human identity: a component can reach resources it should not. That makes destination controls, proxy segmentation, and internal reachability review part of identity-adjacent governance, not just application patching.

URL canonicalisation is becoming a repeatable governance test, not a one-off code review item. When attackers can chain old CVE knowledge into new exploit paths, the weak point is often not novel logic but familiar parsing mistakes that survive product evolution. Teams should monitor for proxy features, plugin surfaces, and outbound request primitives with the same discipline they apply to exposed credentials.

Exploit recurrence is the warning signal. Old SSRF patterns keep reappearing because the underlying trust model remains unchanged, so remediation has to include architectural restriction, not just bug fixes. For programmes that manage service accounts, API access, and internal integrations, the takeaway is to map every component that can originate internal traffic and classify it as a privileged actor.

For practitioners

• Harden all proxy endpoints with strict allowlists Limit outbound destinations to explicit host and scheme allowlists, reject ambiguous URLs after canonicalisation, and block internal ranges, metadata IPs, and localhost targets.
• Separate administrative fetch paths from user traffic Move management proxies behind dedicated authentication, network segmentation, and role-based access controls so they are not reachable through ordinary application interfaces.
• Test extensions and plugins for internal reachability Review custom plugins, console extensions, and administrative features for any ability to initiate internal requests, then add SSRF test cases to release validation.
• Treat internal request capability as privileged access Map any component that can reach internal services to a privileged trust boundary and monitor those requests with the same rigour used for sensitive service accounts.

Key takeaways

• CVE-2025-27888 shows that URL parsing confusion can turn an ordinary management proxy into an SSRF entry point.
• The risk is not limited to code correctness, because internal request capability behaves like delegated privilege when it can reach restricted services.
• Teams should combine canonicalisation checks, destination allowlists, and segmentation for proxy endpoints before treating the issue as fully remediated.

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 Parsing Confusion: URL parsing confusion occurs when different components interpret the same URL or path differently. That inconsistency can allow a request to pass validation in one layer but resolve to a different destination in another, creating an exploitable gap between what is checked and what is actually contacted.
• 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.
• Internal Fetch Primitive: An internal fetch primitive is any application feature that can initiate outbound requests to internal destinations. It matters because the feature effectively extends the application’s trust boundary, and if it is influenced by untrusted input, it can be used to access resources that should remain isolated.

What's in the full report

Xbow's full research covers the exploit trace and remediation detail this post intentionally leaves for the source:

• Step-by-step trace of how the management proxy was probed and how the final SSRF path was reached.
• The specific behaviour of the Apache Druid proxy endpoint before versions 31.0.2 and 32.0.1.
• The full advisory context and patch guidance needed for implementation teams.
• The intermediate failed hypotheses that show how older CVE patterns shaped the search process.

👉 Xbow's full post covers the exploit trace, failed attempts, and patch context for the Apache Druid proxy flaw.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps practitioners connect access control, lifecycle governance, and secret management to the broader security programme.