{“lastseen”:”2026-05-18T12:09:01″,”description”:”## Executive Summary\\n\\nWe identified a couple of vulnerabilities in AI automation platform Dify resulting in cross-tenant sensitive information disclosure and one-click account takeover. These findings reinforce the pattern we documented in our previous n8n blogpost: **even though AI automation platforms are increasingly becoming integration hubs for complex workflows, their security posture still lags behind their rapid evolution and operational importance.**\\n\\n## Introduction\\n\\nDify is an open-source platform for building LLM-powered applications: agents, chatbots, and automated workflows. With over 134,000 GitHub stars and over 10 million docker pulls, it has rapidly become one of the most popular tools in the AI application space, offering both self-hosted and managed cloud deployments.\\n\\nOur research into Dify uncovered two distinct vulnerabilities that illustrate this risk:\\n\\n 1. A file handling flaw that enables one-click account takeover through a single malicious link _(detailed below)._\\n\\n\\n 1. An insufficient tenant isolation issue in shared environments that exposes other users’ application source code. \\n\\n\\n\\nBoth findings point to the same structural challenge: **platforms that centralize trust must also centralize rigor in how they isolate users and handle untrusted input.**\\n\\nThe first issue was addressed in Dify 1.13.1. The second was fixed in the sandbox layer by moving from a shared identity to per-execution UIDs, then shipped to Dify users through the newer sandbox image bundled with 1.13.3.\\n\\nDify did not respond to any of our disclosure messages and chose to patch silently.\\n\\n## One Click to Account Takeover\\n\\nThe flaw lies in how Dify handles file uploads through workflow tool nodes, such as _Image Downloader_ or _Image Toolbox_.\\n\\nSVG is an XML-based image format that can natively embed JavaScript, via \\u003cscript\\u003e tags or event handlers on SVG elements. When a browser renders an SVG file served from a trusted origin, any embedded script executes with full access to that origin’s session context, including cookies, local storage, and API calls.\\n\\nDify uses two subdomains:\\n\\n * **upload.dify.ai:** where user-uploaded files are stored and served\\n\\n\\n * **cloud.dify.ai** : the main application domain, where users authenticate and manage their workflows\\n\\n\\n\\nCritically, upload.dify.ai**** and cloud.dify.ai are configured as DNS aliases. From the browser’s perspective, both subdomains resolve to the same origin. This collapses the intended security boundary: a file that should have been confined to a static asset domain is instead rendered with the full privileges of the application domain.\\n\\nA malicious SVG uploaded to upload.dify.ai**** could simply be accessed via cloud.dify.ai, and the browser would execute its JavaScript payload as if it were part of the application itself.\\n\\nBut this design wouldn\u2019t be dangerous if access control was enforced on uploaded files**.** Each uploaded file receives a unique ID and is stored at a predictable path:\\n\\nhttps:\/\/upload.dify[.]ai\/files\/tools\/\\u003cunique-id\\u003e\/filename.svg\\n\\nHowever, these files are publicly accessible with no authentication and no per-user scoping (a.k.a Insecure Direct Object Reference). Anyone who knows the URL can retrieve the file. And that ID is not necessarily secret: it could leak through Referer headers or surface in shared workspace contexts.\\n\\nTherefore, in this case, the exploitation scenario was straightforward: \\n\\n * The threat actor generates a malicious link leading to a resource in his account\\n\\n\\n * The resource link is shared to another user, and one click leads to account takeover.\\n\\n\\n\\nEventually, Dify team fixed this first issue by overwriting the content-type of the HTTP response to \\”application\/octet-stream\\”, independently from the nature of the file, represented with the args.as_attachment flag version 1.13.1. \\nThis value triggers download instead of rendering.\\n\\nhttps:\/\/www.imperva.com\/blog\/wp-content\/uploads\/sites\/9\/2026\/05\/dify.mp4\\n\\n## Cross-Tenant Source Disclosure in the Python Sandbox\\n\\nThis bug lived deeper in the stack, inside **dify-sandbox** , the service Dify uses to execute untrusted code.\\n\\nThe failure here was particularly interesting, as it required a chain to fully leak other users’ source code on the Dify platform.\\n\\n 1. Sandboxed Python executions shared a filesystem location.\\n 2. Those executions shared the same runtime identity.\\n 3. The leaked artifact contained encrypted code, not plaintext.\\n 4. But the \\”encryption\\” was repeating-key XOR, so ciphertext alone was often enough.\\n\\n\\n\\n## Where the Leak Came From\\n\\n_Fig. 1: Dify cross-tenant source disclosure_\\n\\nThe Dify monorepo only pins the sandbox image. At tag 1.13.1, Dify still shipped langgenius\/dify-sandbox:0.2.12 in its compose files:\\n\\n * Dify 1.13.1 sandbox pin: https:\/\/github.com\/langgenius\/dify\/blob\/1.13.1\/docker\/docker-compose-template.yaml#L246-L249\\n\\n\\n\\nInside that sandbox version, the Python runner used a fixed sandbox root:\\n\\n * sandbox root definition: https:\/\/github.com\/langgenius\/dify-sandbox\/blob\/0.2.12\/internal\/core\/runner\/python\/setup.go#L23-L26\\n\\n\\n * chroot behavior described in FAQ: https:\/\/github.com\/langgenius\/dify-sandbox\/blob\/0.2.12\/FAQ.md#L3-L13\\n\\n\\n\\nThe important detail is what happened during execution. The runner generated a temporary script under ${LIB_PATH}\/tmp\/\\u003cuuid\\u003e.py, which became \/tmp\/\\u003cuuid\\u003e.py from the Python process’s perspective after chroot. The same runner stamped every wrapper script with a single hard-coded sandbox UID:\\n\\n * vulnerable runner: https:\/\/github.com\/langgenius\/dify-sandbox\/blob\/0.2.12\/internal\/core\/runner\/python\/python.go#L89-L164\\n\\n\\n * static sandbox UID: https:\/\/github.com\/langgenius\/dify-sandbox\/blob\/0.2.12\/internal\/static\/user.go#L1-L6\\n\\n\\n\\nThree lines tell the story:\\n\\n * Identity was fixed through static.SANDBOX_USER_UID.\\n\\n\\n * The wrapper script was written with os.WriteFile(\u2026, 0755).\\n\\n\\n * The file lived under the shared sandbox tmp directory.\\n\\n\\n\\nSeparate tenants executing inside the same sandbox root, under the same effective identity, with readable code artifacts left in a shared \/tmp. That is the entire isolation bug.\\n\\nOur proof of concept simply sampled \/tmp during execution and collected newly created files. In a shared cloud deployment, that exposed wrapper scripts belonging to other tenants running on the same sandbox host.\\n\\nThe attacker-side workflow looked like this:\\n\\n## What the Attacker Actually Stole\\n\\nThe leaked file was not the raw user script.\\n\\nDify generated a Python wrapper that loaded a native seccomp helper, decoded a Base64 blob, decrypted it, and exec’d the result.\\n\\nThe decryptor lived in the embedded prescript:\\n\\n * prescript decryptor: https:\/\/github.com\/langgenius\/dify-sandbox\/blob\/0.2.12\/internal\/core\/runner\/python\/prescript.py#L22-L47\\n\\n\\n\\nThe critical line:\\n\\nOn the Go side, the matching encryption logic was just as direct:\\n\\nThis looks like \\”encryption,\\” but it is really a byte-wise Vigenere cipher with a 64-byte repeating key.\\n\\nSomething like that:\\n\\n## Why the Encryption Broke\\n\\nIf Dify had used a modern authenticated cipher and never exposed the key, reading \/tmp\/\\u003cuuid\\u003e.py would still have been bad, but it would not immediately reveal source code. Instead, the runner:\\n\\n * generated a random 64-byte key\\n\\n\\n * XORed every plaintext byte with key[i mod 64]\\n\\n\\n * Base64-encoded the result\\n\\n\\n * embedded the ciphertext in the wrapper script\\n\\n\\n\\nRepeating-key XOR leaks structure across every byte position modulo the key length. Once the key length is known, recovery collapses into a set of small single-byte XOR problems, not a modern cryptanalytic challenge.\\n\\nOur PoC used exactly that property. The attack strategy:\\n\\n 1. Lock onto the real key size of 64 bytes.\\n\\n\\n 1. Score candidate plaintext bytes for \\”Python-likeness.\\”\\n\\n\\n 1. Slide common cribs, import , from , def main( \u2014 across the ciphertext.\\n\\n\\n 1. Reward outputs that decode as UTF-8, contain Python tokens, and successfully parse with ast.parse.\\n\\n\\n\\nWorkflow code is highly structured plaintext: full of repeated syntax, imports, identifiers, indentation, JSON handling, and predictable scaffolding. Even when the exact business logic is unknown, the shape of Python source gives the attacker enough signal to recover key bytes and reconstruct the rest.\\n\\nThe sandbox did not need to leak the key. The ciphertext was enough.\\n\\nA reduced version of the recovery logic:\\n\\nThe real PoC is more careful, including crib dragging, UTF-8 heuristics, Python-token scoring, AST validation, and more.\\n\\n## Why This Was Recoverable in Practice\\n\\nThree properties made the attack reliable.\\n\\n**Fixed key size.** The vulnerable runner hard-coded key_len := 64, so the PoC did not have to discover a moving target.\\n\\n**Strong plaintext priors.** Python source naturally contains ASCII-heavy text, repeated keywords, common import patterns, indentation and punctuation, and valid UTF-8.\\n\\n**Machine-verifiable output.** The PoC did not stop at \\”looks readable.\\” It strongly preferred candidates that parsed as real Python, turning recovery into a search problem with a sharp scoring function.\\n\\n## How Dify Fixed It\\n\\nThe fix landed in dify-sandbox 0.2.13:\\n\\n * fix: tenant isolation use uid: https:\/\/github.com\/langgenius\/dify-sandbox\/commit\/6b3577c7779c4afc9f26645df5a4660a7282a566\\n\\n\\n\\nThe patched runner changed the trust boundary in the right place:\\n\\n * fixed runner: https:\/\/github.com\/langgenius\/dify-sandbox\/blob\/0.2.13\/internal\/core\/runner\/python\/python.go#L30-L176\\n\\n\\n * UID pool: https:\/\/github.com\/langgenius\/dify-sandbox\/blob\/0.2.13\/internal\/core\/runner\/python\/uid_pool.go#L9-L67\\n\\n\\n\\nThe important changes:\\n\\n * uid, err := AcquireUID(ctx)\\n\\n\\n * The wrapper was written with os.WriteFile(\u2026, 0600).\\n\\n\\n * The file was reassigned with syscall.Chown(\u2026, uid, \u2026).\\n\\n\\n * The embedded prescript stopped using the single global sandbox UID and used the per-run UID instead.\\n\\n\\n\\nThis matters more than any cryptographic tweak. Before the fix, every execution looked like the same sandbox user. After the fix, each execution got its own identity and its own readable artifact set.\\n\\nDify did not \\”fix the encryption.\\” It fixed the isolation boundary.\\n\\n## The Impact\\n\\n * **One-click account takeover:** The attacker acts as the victim: modifying workflows, changing settings, inviting collaborators.\\n\\n\\n * **Workflow theft:** Private workflows (often encoding proprietary business logic, integration architecture, and prompt engineering) become fully accessible.\\n\\n\\n * **Credential exfiltration:** API keys, OAuth tokens, and model configurations stored in Dify can be extracted, enabling lateral movement into every connected external service.\\n\\n\\n * **Full instance compromise:** If the victim is an administrator, the attacker gains control of the entire Dify deployment and every integration it orchestrates.\\n\\n\\n\\n## Conclusion\\n\\nBoth vulnerabilities we found in Dify stem from the same oversight: security controls that weren’t designed to keep pace with the platform’s feature growth. As these tools add collaboration, file sharing, and multi-tenant environments, each new surface needs to be hardened with the same rigor as the core application.\\n\\nWhat makes this particularly relevant for security teams is the open-source model: Dify is widely self-hosted, meaning unpatched instances may persist long after fixes are released. Organizations running Dify (in any configuration) should verify they are on v1.13.1 or later.\\n\\n## Timeline\\n\\n * January 14, 2026: initial disclosure sent\\n\\n\\n * March 17, 2026: Dify 1.13.1 released, addressing the first issue\\n\\n\\n * March 19, 2026: dify-sandbox 0.2.13 released with UID-based tenant isolation\\n\\n\\n * March 20, 2026: follow-up sandbox patch stabilizes the UID-based design inside the chroot\\n\\n\\n * March 25, 2026: Dify 1.13.3 released, bundling the fixed sandbox at 0.2.14\\n\\n\\n\\nThe post Dify: When Your AI Platform Becomes the Attack Surface appeared first on Blog.”,”published”:”2026-05-18T11:00:06″,”modified”:”2026-05-18T11:00:06″,”type”:”impervablog”,”title”:”Dify: When Your AI Platform Becomes the Attack Surface”,”source”:””,”references”:””,”id”:”IMPERVABLOG:4621FF44A630721E0269C594E0434B43″,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/www.imperva.com\/blog\/dify-when-your-ai-platform-becomes-the-attack-surface\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-05-18T12:09:01″,”description”:”## Executive Summary\\n\\nWe identified a couple of vulnerabilities in AI automation platform Dify resulting in cross-tenant sensitive information disclosure and one-click account takeover. These findings…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,59,13,33,7,11,5],"class_list":["post-55288","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-impervablog","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n