Relative path traversal in Dify exposes internal plugin API

At a glance

What this is: This is an analysis of CVE-2026-41948 in Dify, where path traversal in a public plugin icon endpoint can expose internal Plugin Daemon data without authentication.

Why it matters: It matters because AI application platforms increasingly sit inside identity and access boundaries, and a traversal bug can collapse the separation between public console traffic and internal services.

By the numbers:

• The issue is tracked as CVE-2026-41948 and scored 9.4 CRITICAL in CVSS 4.0.

Context

Relative path traversal is a file or path handling flaw that lets an attacker escape an intended namespace and reach something the application never meant to expose. In this case, the weakness sits inside a public console proxy that forwards requests to an internal plugin service, which makes the issue as much about trust boundaries and service identity as about input validation.

Dify's architecture separates the public API service from an internal Plugin Daemon, but the proxy route trusts a user-controlled filename to build the upstream path. That means a single unsanitised parameter can bypass namespace isolation and reach internal endpoints that were designed only for private service-to-service traffic.

Key questions

Q: What breaks when an AI platform trusts user-controlled paths to reach internal services?

A: The application loses the separation between public traffic and private service-to-service routing. A traversal payload can escape the intended namespace, reach internal endpoints, and expose operational data or management surfaces that were never meant to be internet-facing. Once that happens, access control and network design stop reinforcing each other, which makes the whole boundary easier to abuse.

Q: Why do path traversal flaws in AI application platforms create more risk than a simple file read bug?

A: Because these platforms often proxy into internal plugin, retrieval, or agent services that carry rich operational metadata and privileged functions. A traversal bug can therefore become a trust-boundary escape, not just a content exposure issue. That increases the chance of reconnaissance, service fingerprinting, and chaining into deeper internal abuse.

Q: How can security teams tell whether an internal endpoint is still too exposed to the public edge?

A: Look for unauthenticated routes that return versioning, build data, request counters, or subsystem health, especially when they are reachable through a public console or proxy layer. If a route can be influenced by user input and still exposes internal service state, it should be treated as a boundary failure rather than a harmless status page.

Q: Should organisations put reverse proxy controls in front of AI platform plugin services?

A: Yes, when public application routes forward into internal plugin or agent services, the proxy should enforce path canonicalisation, access restrictions, and explicit allowlists. That control becomes especially important where the platform supports self-registration or exposes management functions through a shared console surface. Without it, a small parsing flaw can reach far beyond the intended asset namespace.

Technical breakdown

How the plugin icon proxy turns path input into upstream access

The vulnerable route accepts tenant_id and filename, then concatenates the filename into an internal request path before forwarding it to the Plugin Daemon. Because the code does not canonicalise dot segments, a value like ../../../health/check consumes the intended path prefix and resolves to an internal root endpoint instead of the asset namespace. The key design flaw is that tenant isolation depends on path structure alone, so traversal becomes a namespace escape rather than a simple bad path. In a microservice design, this is a control failure at the proxy boundary, not just a parsing bug. See the Web Application Attacks Guide.

Practical implication: Treat any service that forwards user-controlled paths as a trust boundary and reject dot-segment traversal before proxying.

Why unauthenticated console endpoints are especially dangerous in AI platforms

The route has no effective login requirement, and open registration can remove the remaining friction even when some neighbouring endpoints assume a workspace account exists. That matters because internal AI platform services often expose status, debug, and plugin metadata that reveal versioning, deployment mode, request counters, and subsystem health. Once a public request can reach those surfaces, the platform stops behaving like a closed control plane and starts behaving like an externally reachable management plane. In an AI application stack, that exposure can accelerate recon, chaining, and targeted abuse against higher-value internal functions.

Practical implication: Require authentication and reverse-proxy restrictions on every management-facing AI platform route, even when the intended user path looks low risk.

How internal service metadata increases attack value after traversal

The exposed /health/check response returns runtime status, build_time, platform, worker-pool state, and a version identifier. Those fields are not sensitive on their own in isolation, but together they give an attacker deployment fingerprinting, uptime confidence, and a way to confirm the internal service is reachable and behaving normally. That is why information disclosure often precedes deeper exploitation: it removes uncertainty. In a platform that orchestrates AI apps and agents, internal metadata can also expose where plugin execution lives, which surfaces exist, and which follow-on routes are worth probing. See the Vulnerability Management Guide.

Practical implication: Reduce metadata exposure on internal health and debug routes, and assume reconnaissance value even when the data looks operational.

Threat narrative

Attacker objective: The attacker wants unauthorised visibility into internal AI platform services so they can fingerprint the deployment and expand to higher-value internal routes.

1. Entry occurs when an unauthenticated visitor sends a crafted request to the public plugin icon endpoint and supplies traversal sequences in the filename parameter.
2. Credential access is not required, because the proxy forwards the request across the namespace boundary and reaches an internal daemon route directly.
3. Impact follows when the internal health endpoint discloses version, build, platform, and worker-pool data that supports fingerprinting and follow-on targeting.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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

Namespace isolation is not a security boundary if the application constructs the namespace from attacker input. Dify's design assumes that embedding a tenant UUID in the URL is enough to separate public requests from internal plugin assets. Once the filename parameter can inject traversal segments, the boundary collapses because routing logic and access control are no longer independent. Practitioners should treat any path-derived isolation model as fragile unless the upstream path is canonicalised and policy-enforced before forwarding.

AI application platforms now need identity-aware proxy governance, not just input validation. The interesting failure here is not only CWE-23, but the fact that a public console route becomes a bridge into an internal management service. That creates a governance problem for AI app stacks, where plugin services, agent tooling, and runtime health endpoints often sit behind assumptions about trusted callers. The right mental model is service identity and request provenance, not merely endpoint hygiene.

Internal health endpoints are security-relevant when they sit behind a broken trust boundary. The exposed metadata did not contain secrets, but it still provided versioning, environment, and live status data that reduces attacker uncertainty. In modern AI stacks, that is enough to support targeted exploitation and chaining across adjacent services, especially where plugins, retrieval, and agent execution are split across microservices. Teams should classify operational telemetry as a recon asset when it is reachable from any externally influenced path.

Open registration turns an otherwise technical flaw into a governance gap. Even when the traversal itself is unauthenticated, default sign-up behaviour reduces friction for abuse and expands the blast radius of exposed management routes. That means the control problem spans application logic, onboarding policy, and perimeter enforcement. Where AI platforms are used to build and run agents, the governance question is not whether the service has users, but whether the public surface can ever reach internal execution paths.

For AI platforms, the real failure mode is trust-boundary leakage across the plugin and agent plane. The breach illustrates a specific control gap: the application trusted path structure to preserve separation between public console traffic and internal service identity. That is a named concept worth tracking because similar failures will recur wherever orchestration layers proxy into hidden plugin, retrieval, or execution services. Practitioners should design for explicit boundary checks instead of assuming internal service URLs remain private by convention.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: Identity Governance for AI Agents Guide

What this signals

Trust-boundary leakage is the right concept for this class of AI platform flaw: when a public console can proxy into internal plugin or agent services, path handling becomes an identity and governance problem, not merely an input-validation bug. Security teams should map every externally influenced route to the private service it can reach, then decide whether that service is allowed to disclose status or metadata at all.

The 81.5% year-over-year surge in AI-related credential leaks in 2025 shows that AI infrastructure is already leaking faster than core model providers, according to the State of Secrets Sprawl 2026. That trend matters here because platform weaknesses rarely stay isolated, and exposed control planes often become the foothold for broader credential and service abuse.

For practitioners

• Harden every proxy path against traversal Canonicalise and reject dot segments before any upstream request is formed, and test the exact console routes that translate user input into internal service paths. See the Web Application Attacks Guide.
• Restrict public access to internal plugin services Block direct reachability to the Plugin Daemon and any equivalent internal control plane at the reverse proxy, firewall, and network policy layers.
• Disable or gate open registration on exposed AI platforms Remove easy self-sign-up paths where a console or management route could be abused, and require explicit approval for workspace creation where feasible.
• Treat health and debug routes as recon targets Inventory every unauthenticated status endpoint, then reduce the metadata they return and alert on repeated requests with traversal-like filename values.

Key takeaways

• The central risk is not just a bad path string but the collapse of isolation between a public console and an internal AI service boundary.
• The exposed Plugin Daemon response shows how unauthenticated traversal can reveal version, build, platform, and live status data that supports follow-on targeting.
• The control gap is failure to canonicalise and block path traversal before proxying, combined with weak exposure controls on internal management endpoints.

Related NHI Mgmt Group resources: Identity Governance for AI Agents Guide · Shadow AI and AI Agent Discovery Guide · Vulnerability Management Guide · Open Source Security Guide

Key terms

• Relative Path Traversal: Relative path traversal is a file access flaw where user input lets an attacker move outside the intended directory using relative path elements. It can expose configuration, secrets or code, so defenders normalise paths, enforce allowlists and block input that resolves beyond approved locations.
• 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.
• Policy Management Plane: A policy management plane is the central control layer used to define, distribute, and maintain security policy across environments. It helps teams apply consistent rules at scale instead of managing isolated device configurations. In dynamic infrastructures, it becomes the coordination point for automation, topology changes, and ongoing enforcement.
• Namespace Isolation: Namespace isolation is the expectation that users or policies restricted to one Kubernetes namespace cannot affect resources or data outside that namespace. It fails when a shared controller executes delegated logic with broader runtime privileges than the author of the request.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for teams that need to connect identity control, service access, and AI governance in one programme.