CVE-2026-42138: Dify LLM Platform XSS Vulnerability

CVE-2026-42138 Overview

CVE-2026-42138 is a stored Cross-Site Scripting (XSS) vulnerability [CWE-79] in Dify, an open-source large language model (LLM) application development platform. The flaw resides in two file upload endpoints: POST /api/files/upload and POST /v1/files/upload. Attackers can upload SVG files containing embedded JavaScript, which executes in the browser context of any user who later views the file. The unauthenticated endpoint POST /api/files/upload allows exploitation without credentials, expanding the attack surface to anonymous internet users. The issue affects all Dify releases prior to version 1.13.1 and is patched in that release.

Critical Impact

Unauthenticated attackers can upload malicious SVG files that execute arbitrary JavaScript in victim browsers, enabling session theft and account takeover within Dify deployments.

Affected Products

• Dify versions prior to 1.13.1 (open-source LLM application platform by langgenius)
• Dify deployments exposing POST /api/files/upload (unauthenticated path)
• Dify deployments exposing POST /v1/files/upload (authenticated application API)

Discovery Timeline

• 2026-05-04 - CVE-2026-42138 published to NVD
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-42138

Vulnerability Analysis

The vulnerability is a stored XSS [CWE-79] caused by improper handling of Scalable Vector Graphics (SVG) uploads. SVG is an XML-based image format that natively supports <script> elements and event handlers such as onload and onclick. When a server stores SVG content and serves it back with a Content-Type of image/svg+xml from a sensitive origin, browsers execute any embedded JavaScript in that origin's context.

Dify exposes two affected endpoints. POST /api/files/upload accepts uploads without authentication, allowing any anonymous network user to plant malicious payloads. POST /v1/files/upload requires an application API key but remains exploitable by any authenticated tenant. Once a target user navigates to the file URL, the payload runs with their privileges in the Dify origin.

Root Cause

The root cause is the absence of server-side sanitization and content-type restrictions on uploaded files. Dify accepts SVG content without stripping <script> tags or event handlers and serves the file inline rather than forcing download. The unauthenticated upload endpoint compounds the risk by removing the access control barrier that would normally limit who can introduce content into the platform.

Attack Vector

An attacker crafts an SVG file containing JavaScript inside a <script> element or an event-handler attribute on an SVG node. The attacker submits the file to POST /api/files/upload with no authentication, or to POST /v1/files/upload using a valid API key. The server stores the file and returns a URL. The attacker shares the URL or embeds it inside a Dify application, conversation, or knowledge base reference. When a victim's browser fetches the SVG with the response served as image/svg+xml, the embedded script executes within the Dify origin, exposing session cookies, API tokens stored in localStorage, and any in-page state. Refer to the GitHub Security Advisory GHSA-cg94-8v83-7hjj for additional technical details.

Detection Methods for CVE-2026-42138

Indicators of Compromise

• HTTP POST requests to /api/files/upload or /v1/files/upload with Content-Type: image/svg+xml or filenames ending in .svg.
• SVG files in Dify storage containing <script>, javascript: URIs, or event-handler attributes such as onload, onerror, or onclick.
• Outbound browser requests from Dify users to unfamiliar domains immediately after rendering an uploaded asset.
• Anomalous use of session tokens or API keys originating from IP addresses that do not match a user's normal pattern.

Detection Strategies

• Inspect web server and reverse proxy access logs for upload requests against the two vulnerable endpoints, especially unauthenticated calls to /api/files/upload.
• Scan stored uploads for SVG content containing scriptable elements using static analysis or YARA-style rules.
• Deploy a Web Application Firewall (WAF) rule that inspects multipart upload bodies for SVG payloads carrying <script> tags or on* handlers.
• Enable Content Security Policy (CSP) violation reporting to surface unexpected script execution on Dify pages.

Monitoring Recommendations

• Alert on any HTTP 200 response to /api/files/upload from unauthenticated sources, since this endpoint should not be reachable on hardened deployments.
• Track the volume and source diversity of SVG uploads and flag spikes from new IP ranges or user agents.
• Correlate file-render events with subsequent privileged API calls from the same browser session to detect token theft.

How to Mitigate CVE-2026-42138

Immediate Actions Required

• Upgrade Dify to version 1.13.1 or later, which contains the official fix for both upload endpoints.
• Audit existing file storage for SVG files uploaded prior to patching and remove any containing scriptable content.
• Rotate Dify session secrets and application API keys if exposure is suspected, since stored XSS can exfiltrate active credentials.
• Restrict network exposure of /api/files/upload so the unauthenticated endpoint is not reachable from the public internet.

Patch Information

The maintainers released the fix in Dify 1.13.1. The patch addresses both POST /api/files/upload and POST /v1/files/upload. Administrators running self-hosted deployments should pull the updated container images or source release and redeploy. Operators should also review the GitHub Security Advisory GHSA-cg94-8v83-7hjj for upstream guidance.

Workarounds

• Block SVG uploads at a reverse proxy by rejecting requests where Content-Type is image/svg+xml or filenames end in .svg until the patch is applied.
• Force user-uploaded files to be served with Content-Disposition: attachment and a non-renderable Content-Type such as application/octet-stream.
• Serve uploaded content from a sandbox domain isolated from the Dify session origin to contain XSS impact.
• Apply a strict Content Security Policy that disallows inline scripts and restricts script sources to trusted origins.

# Example NGINX rule blocking SVG uploads to vulnerable endpoints
location ~ ^/(api|v1)/files/upload$ {
    if ($request_method = POST) {
        if ($http_content_type ~* "image/svg\+xml") {
            return 415;
        }
    }
    proxy_pass http://dify_backend;
}