Summary
A stored cross-site scripting (XSS) flaw in ComfyUI's /userdata endpoint allowed user-uploaded HTML and SVG files to be served with executable content types.
When a victim visited these file URLs, attacker-controlled scripts ran in the ComfyUI origin, exposing browser-stored API tokens, settings, and enabling authenticated-equivalent actions.
Affected context
The vulnerability arises in ComfyUI deployments that expose the /userdata/{file} route and permit users or external tools to upload arbitrary content into the userdata directory.
The handler directly served files via web.FileResponse(path) and relied on file extensions to derive MIME types, meaning .html and .svg uploads were returned as text/html and image/svg+xml.
In environments where users can share or bookmark /userdata URLs, other users or operators could be tricked into opening these URLs, causing untrusted scripts to execute within the ComfyUI web origin.
Exploit preconditions
- Attack surface: HTTP interface of ComfyUI, specifically the
GET /userdata/{file}endpoint. - Required access: Ability to upload or otherwise place files into the
userdatadirectory viaPOST /userdataor equivalent mechanisms. - User interaction: A victim must be induced to browse to the malicious
/userdata/{file}URL (e.g., via shared links, bookmarks, or embedded frames). - Why exploitation is possible: The server reflects user-controlled files with extension-derived content types, allowing HTML/SVG content to be interpreted as active web documents in the same origin as the main ComfyUI application.
Why this happens
The core issue is that untrusted, user-controlled content is being served as active web pages under the same origin as the application.
By using web.FileResponse(path) and trusting file extensions to determine MIME types, the /userdata handler turns uploaded .html and .svg files into fully executable documents.
This maps to CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-Site Scripting), where untrusted data is delivered to a browser in a way that allows script execution in a trusted origin.
Conceptually, the bug is an unsafe content-hosting pattern: a user content bucket is exposed without forcing downloads or isolating it under a separate origin, thus collapsing the trust boundary between application code and user content.
Potential impact
- Malicious scripts can read and exfiltrate browser-stored API tokens associated with ComfyUI.
- Attackers may access or modify user settings, workflows, and other sensitive data accessible through the ComfyUI API.
- Execution of authenticated-equivalent API calls, potentially automating or manipulating workflows on behalf of the victim.
- Persistent compromise of a user's ComfyUI environment when shared links or widely distributed URLs are used.
- Potential pivot to broader account or environment misuse if ComfyUI tokens are reused elsewhere.
General mitigation guidance
Effective mitigation focuses on isolating or deactivating active content in user-controlled storage areas.
Typical defensive patterns include:
- Forcing potentially dangerous MIME types (such as
text/html,image/svg+xml, and other script-capable types) to be delivered as downloads or with a safe, non-executable content type. - Serving user-uploaded files from a separate origin or domain so that scripts, if any, cannot access primary application cookies or APIs.
- Applying strict allowlists for file types that may be rendered inline and treating all other content as attachments.
- Adding a default
Content-Security-Policythat restricts inline scripts and limits the ability of user-controlled pages to execute arbitrary code, recognizing that CSP is a defense-in-depth measure rather than a sole control. - Minimizing the storage of high-value secrets in browser-accessible contexts and favoring scoped or short-lived tokens with least privilege.
How teams detect issues like this
Detection often relies on recognizing unsafe content serving patterns during development and review.
Example approaches include:
- Static analysis checks and linting rules that flag frameworks or helpers (like generic file response handlers) when they serve content directly from user-controlled directories.
- Code reviews that specifically look for endpoints exposing file systems, download handlers, or "user content" directories without MIME-type or origin isolation.
- Automated security tests that upload HTML/SVG payloads and confirm whether they execute as active documents in the application origin.
- Logging and monitoring for unusual access patterns to
/userdatapaths, especially URLs that appear to be shared or accessed by multiple users.
