CVE-2026-30821 Overview
CVE-2026-30821 is an Unrestricted File Upload vulnerability (CWE-434) affecting Flowise, a popular drag-and-drop user interface for building customized large language model flows. Prior to version 3.0.13, the /api/v1/attachments/:chatflowId/:chatId endpoint is included in WHITELIST_URLS, enabling unauthenticated access to the file upload API. While the server validates uploads based on MIME types defined in chatbotConfig.fullFileUpload.allowedUploadFileTypes, it implicitly trusts the client-provided Content-Type header (file.mimetype) without verifying the file's actual content (magic bytes) or extension (file.originalname).
This design flaw allows attackers to bypass file type restrictions by spoofing the Content-Type header as a permitted type (e.g., application/pdf) while uploading malicious scripts or arbitrary files. Once uploaded via addArrayFilesToStorage, these files persist in backend storage (S3, GCS, or local disk), creating a critical entry point for further exploitation.
Critical Impact
When chained with other features like static hosting or file retrieval, this vulnerability can lead to Stored XSS, malicious file hosting, or Remote Code Execution (RCE).
Affected Products
- Flowise versions prior to 3.0.13
- FlowiseAI Flowise (all deployment configurations: S3, GCS, local disk)
- Flowise instances with unauthenticated file upload endpoints exposed
Discovery Timeline
- 2026-03-07 - CVE-2026-30821 published to NVD
- 2026-03-11 - Last updated in NVD database
Technical Details for CVE-2026-30821
Vulnerability Analysis
This vulnerability represents a classic Unrestricted File Upload flaw that stems from insufficient server-side validation of uploaded files. The Flowise application's attachment endpoint exists in a whitelisted URL configuration, meaning it bypasses authentication checks entirely. This allows any unauthenticated user to interact with the file upload functionality.
The core issue lies in the validation mechanism: while Flowise implements MIME type checking through chatbotConfig.fullFileUpload.allowedUploadFileTypes, this validation relies exclusively on the Content-Type header supplied by the client during the HTTP multipart form-data upload. Since this header is entirely client-controlled, an attacker can trivially bypass the restriction by setting a permitted MIME type while uploading content that doesn't match that type.
The uploaded files are then persisted through addArrayFilesToStorage to the configured backend storage system without additional validation of the file's actual content or extension. This creates a persistent attack vector where malicious files remain accessible for subsequent exploitation.
Root Cause
The root cause is a failure to implement defense-in-depth file upload validation. The application trusts the client-provided Content-Type header without performing secondary validation through magic byte verification or file extension checks. Combined with the unauthenticated access to the upload endpoint, this creates an exploitable condition where arbitrary files can be uploaded to the server's storage backend.
Attack Vector
The attack can be executed remotely over the network by any unauthenticated user who can reach the Flowise instance. The exploitation flow involves crafting an HTTP POST request to /api/v1/attachments/:chatflowId/:chatId with a spoofed Content-Type header that matches an allowed MIME type while including malicious content in the request body.
An attacker would construct a multipart form-data request targeting the vulnerable endpoint. By setting the Content-Type header to an allowed value such as application/pdf while actually uploading a malicious script file (e.g., HTML with embedded JavaScript, or a web shell), the attacker can bypass the MIME type validation. The uploaded file is then stored persistently and can be accessed later to execute Stored XSS attacks, serve malware, or potentially achieve Remote Code Execution depending on how the application serves or processes these files.
For detailed technical information and proof-of-concept details, refer to the GitHub Security Advisory GHSA-j8g8-j7fc-43v6.
Detection Methods for CVE-2026-30821
Indicators of Compromise
- Unusual file uploads to /api/v1/attachments/ endpoints with mismatched MIME types and file extensions
- Presence of script files (.html, .js, .php, .svg) in attachment storage directories with PDF or image MIME types in logs
- Unauthenticated requests to attachment endpoints from unknown IP addresses
- Unexpected file types in S3, GCS, or local storage backends used by Flowise
Detection Strategies
- Implement web application firewall (WAF) rules to inspect multipart uploads for MIME type and content mismatches
- Monitor access logs for requests to /api/v1/attachments/:chatflowId/:chatId from unauthenticated sessions
- Deploy file integrity monitoring on Flowise storage directories to detect unexpected file types
- Configure SIEM alerts for file upload activities that bypass authentication checks
Monitoring Recommendations
- Enable detailed logging for all file upload operations including client IP, MIME type, filename, and file size
- Set up alerts for file uploads occurring outside normal business hours or from suspicious geolocations
- Monitor storage backends for files with executable extensions or script content
- Track API endpoint access patterns to identify potential reconnaissance or exploitation attempts
How to Mitigate CVE-2026-30821
Immediate Actions Required
- Upgrade Flowise to version 3.0.13 or later immediately
- Audit attachment storage directories for any suspicious or malicious files uploaded prior to patching
- Implement network-level access controls to restrict access to Flowise instances
- Review application logs for evidence of exploitation attempts
Patch Information
FlowiseAI has addressed this vulnerability in version 3.0.13. The patch implements proper file content validation that goes beyond trusting the client-provided MIME type. Organizations running affected versions should upgrade immediately.
Patch and release information is available at the GitHub Flowise Release 3.0.13 page. Additional security details can be found in the GitHub Security Advisory GHSA-j8g8-j7fc-43v6.
Workarounds
- Remove /api/v1/attachments/:chatflowId/:chatId from WHITELIST_URLS to require authentication for file uploads
- Implement a reverse proxy or WAF rule to block or inspect requests to the attachment endpoint
- Disable the file upload feature entirely if not required for business operations
- Restrict network access to Flowise instances using firewall rules or VPN requirements
# Example: nginx configuration to block unauthenticated access to attachment endpoint
location ~ ^/api/v1/attachments/ {
# Require authentication or block entirely
deny all;
# Or implement custom authentication check
# auth_request /auth/verify;
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


