Skip to main content
Return to TrendAI™ Security Blog
AI & emerging technologies Vulnerabilities and exploits

How TrendAI™ Research Helped Close an Open Redirect in Dify's Post-Login Flow

TrendAI™ Research uncovered an open redirect in Dify's post-login flow that could have handed a freshly authenticated session, token and all, to an attacker, and worked with the vendor to close it across every sign-in path before the details went public.

Research features Exploits & Zero-Days AI
August 4th, 2026 7 min read David Fiser , Alfredo Oliveira

Key Takeaways

  • TrendAI™ Research discovered an open redirect in Dify's post-login authentication flow (ZDI-26-452 / CVE-2026-18266, CVSS 5.4) that affected every sign-in path, including the embeddable webapp widget used when Dify chat widgets are hosted on third-party sites.
  • Because the post-login redirect target came from an unfiltered URL parameter, a crafted link could route a freshly authenticated session, token and all, to an attacker-controlled destination, opening the door to session hijacking.
  • Rather than a narrow patch, Dify shipped a centralized redirect-validation rewrite (PR #38864, approximately 1,850 lines across 36 files), adding an allowlist model, rejection of protocol-relative and backslash targets, and a dedicated regression test suite.
  • The finding fits a pattern TrendAI™ Research tracks across the fast-growing “LLM tools and applications” category, where AI platforms keep re-discovering classic web-security fundamentals (code injection, SSRF, path traversal, and now open redirect) because feature velocity has outpaced security review.

Summary

TrendAI™ Research discovered an open redirect vulnerability in Dify's post-login authentication flow (ZDI-26-452 / CVE-2026-18266, CVSS 5.4). The vulnerability allows redirecting an authenticated user to an attacker-controlled destination immediately after sign-in, providing an unfiltered URL parameter. The attacker then obtains an authentication token, allowing them to act on the user's behalf. Dify issued the fix on July 13th.

What is Dify, and why does this matter?

Before getting into the flaw itself, it helps to know what Dify is and why a bug here carries weight. It has quietly become one of the go-to platforms for building AI apps, so a gap in something as routine as its sign-in flow can reach a surprisingly large audience.

Dify is an open-source LLMOps platform for building AI workflows, chatbots, and agents, with a visual builder, RAG pipelines, model management, and observability. It has become one of the most widely deployed AI app platforms, with more than 140,000 GitHub stars, over 10 million Docker pulls of the API image, and deployments across dozens of industries. It is offered both as a self-hosted deployment and as a multi-tenant cloud service (cloud.dify.ai), which means a bug can carry cross-tenant risk.

Its popularity is concentrated in the Asia-Pacific region, though adoption is also growing among Western enterprises building customer-facing AI chat widgets, and that widget sign-in path is the specific surface this bug touches (Dify's embeddable “webapp” sign-in flow). It also sits squarely in the “LLM tools and applications” category that TrendAI™ Research identified as the fastest-growing source of AI-related CVEs, including code injection, SSRF, path traversal, and, as shown here, classic web auth flaws re-emerging in new AI tooling.

The vulnerability: an unvalidated post-login redirect

The post-login flow trusted the redirect destination without fully validating it first, and because that destination came from a URL parameter, a crafted link could point it somewhere it shouldn't go. In practice, that meant a freshly authenticated session, token and all, could be routed to a site an attacker controlled.

  • Where: Dify's post-login redirect handling across the standard sign-in form, SSO auth, mail+code auth, and the embeddable webapp sign-in flow used when its chat widgets are hosted on third-party sites.
  • What: insufficient validation of the post-login redirect target allowed a freshly authenticated session to be sent to an external, attacker-controlled origin.
  • Impact: Session and token exposure to the attacker's origin, enabling hijacking of the authenticated user's session (CVSS 5.4).
  • Disclosed via: TrendAI™ Zero Day Initiative™ (ZDI), which coordinated the report with Dify under its standard responsible-disclosure process. The finding is tracked as ZDI-26-452 (CVE-2026-18266).

The fix: a centralized redirect-validation rewrite

Dify shipped a substantial rewrite rather than a narrow patch, with 36 files and roughly 1,850 lines changed (PR #38864, feat/login-redirect-security), including:

  • A new centralized redirect-validation utility (login-redirect.ts) used across every auth entry point (standard sign-in, SSO, mail+code, embedded webapp sign-in, invite flows, token refresh).
  • Explicit rejection of protocol-relative (//) and backslash (/\) redirect targets, the two most common open-redirect bypass primitives.
  • Recursive decode handling to catch double/triple URL-encoded payloads.
  • Rejection of credential-embedded hosts (user@evil.com tricks).
  • An allowlist model for absolute redirect targets: only dify.ai and *.dify.ai, over HTTPS, default port, with everything else falling back to a safe default.
  • A new end-to-end test suite (e2e/features/auth/redirect-security.feature) specifically covering redirect-security regressions going forward.

Disclosure timeline: from report to public fix

The report moved from private disclosure to a public fix over roughly four months. The key dates are below.

  • 2026-03-25 — TrendAI™ Research reports the open redirect to TrendAI™ ZDI, which assigns it the tracking ID ZDI-CAN-29196.
  • 2026-03-25 — ZDI notifies Dify the same day, starting the clock on its standard responsible-disclosure window.
  • 2026-07-13 — Dify merges fix (PR #38864), publicly on GitHub, no CVE, GHSA advisory, or credit issued at time of merge
  • 2026-07-23 — The ZDI 120-day disclosure deadline falls due, the point at which ZDI may publish its advisory regardless of vendor action.
  • 2026-07-29 — ZDI published its advisory (ZDI-26-452), and CVE-2026-18266 was assigned (CVSS 5.4, CWE-601 open redirect).

Why this matters beyond Dify

This finding fits a broader pattern, one that TrendAI™ Research documented at length in our 2026 “Fault Lines in the AI Ecosystem” State of AI Security report. That analysis covered 330,239 CVEs and identified 6,086 unique vulnerabilities affecting AI systems disclosed between 2018 and 2025, with 2,130 of those disclosed in 2025 alone, a 34.6% year-over-year increase, nearly double the 17.9% growth rate seen across CVE disclosures overall. Our forecast puts 2026 on pace for another 2,800 to 3,600 AI-related CVEs.

One category in that dataset is directly relevant here: “LLM tools and applications,” our label for the wave of RAG/agent/chatbot-building platforms (Dify among them, alongside Langflow, vLLM, and AnythingLLM) that has exploded post-ChatGPT. It accounts for 1,243 CVEs, 20.4% of everything we tracked, and the dominant bug classes there are exactly what we're used to seeing in mainstream web applications: code injection, SSRF, and path traversal. This Dify finding adds a fourth to that list (open redirect and post-login flow hardening) and reinforces the report's core thesis: these platforms are re-discovering (and re-fixing) web security fundamentals that mature frameworks solved a decade ago, because feature velocity in this space has outpaced security review maturity.

It's also not the first time Dify specifically has surfaced this year. In February, a separate researcher disclosed a user-enumeration flaw in Dify's login endpoint (GHSA-9qpf-wcv3-w3qx). In June, Zafran Security's “DifyTap” research disclosed four vulnerabilities (two critical) in Dify's tracing, plugin-daemon, and file-access subsystems, enabling cross-tenant data exposure on Dify's multi-tenant cloud (CVE-2026-41947 through -41950). Our finding is the third distinct round of Dify security research disclosed in 2026, and it's a useful contrast to DifyTap: Zafran's findings were architecture-level tenant-isolation failures specific to how Dify's multi-tenant SaaS is built, while ours is a classic authentication flaw that would exist even in a fully self-hosted, single-tenant deployment. Between the two, that's a fairly complete picture of a platform's attack surface, spanning infrastructure-level isolation bugs and application-level auth bugs, both surfacing in the same six-month window.

The Dify finding also sits alongside our team's broader work tracking this failure mode across the AI tooling stack. While our research into MCP servers shows a growing trend into unauthenticated exposure with no client authentication or traffic encryption at all, the ZDI-coordinated disclosures this year alone span LiteLLM (including a CVSS 8.8 case reported in June) and mcp-kubernetes-server (CVSS 9.8), and now Dify. Different projects, same underlying story: fast-moving, widely adopted AI infrastructure shipping ahead of the security review rigor of the frameworks it's often built on top of.

Recommendations for Dify operators

For organizations running Dify, a few steps will close this off and confirm it wasn't exploited before being patched.

  • Organizations should upgrade to Dify v1.16.0 or later, which includes the redirect-validation rewrite from PR #38864. This is the single most effective step, since it closes the flaw at its source across every affected auth entry point.
  • Those self-hosting behind a custom reverse proxy should review its configuration to confirm it does not forward unvalidated redirect parameters to an external destination. A proxy that passes these through can reintroduce the same open-redirect behavior even after the application is patched.
  • They should also review authentication and redirect logs for signs of exploitation, such as post-login redirects to unfamiliar external domains or unexpected oauth_redirect_url values pointing off-site.