CVE-2026-30821 in Flowise
Summary
by MITRE • 03/07/2026
Flowise is a drag & drop user interface to build a customized large language model flow. Prior to version 3.0.13, the /api/v1/attachments/:chatflowId/:chatId endpoint is listed in WHITELIST_URLS, allowing unauthenticated access to the file upload API. While the server validates uploads based on the 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). Consequently, an attacker can bypass this restriction by spoofing the Content-Type 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). This vulnerability serves as a critical entry point that, when chained with other features like static hosting or file retrieval, can lead to Stored XSS, malicious file hosting, or Remote Code Execution (RCE). This issue has been patched in version 3.0.13.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 03/12/2026
The vulnerability identified as CVE-2026-30821 affects Flowise, a drag and drop interface for building customized large language model flows, specifically targeting version prior to 3.0.13. This flaw exists within the /api/v1/attachments/:chatflowId/:chatId endpoint which is incorrectly included in the WHITELIST_URLS configuration, creating an unintended access point that bypasses authentication requirements. The security issue stems from a fundamental trust relationship between the server and client where the system implicitly relies on client-provided metadata rather than performing robust validation of actual file content. The endpoint validates uploads using MIME type checks from chatbotConfig.fullFileUpload.allowedUploadFileTypes but fails to implement proper file content verification through magic bytes inspection or filename extension validation, creating a dangerous gap in the security posture.
The technical exploitation of this vulnerability demonstrates a classic case of insecure file upload handling where the system's validation logic is easily circumvented through simple header manipulation. Attackers can spoof the Content-Type header to match permitted MIME types such as application/pdf while actually uploading malicious scripts or executable files, effectively bypassing the intended file type restrictions. This approach leverages the principle of least privilege violation where the server trusts client-supplied information without proper verification mechanisms. The vulnerability is particularly concerning because the uploaded files are persisted in backend storage systems including S3, GCS, or local disk storage, creating a persistent threat vector that can be exploited over time. The combination of weak input validation and persistent storage creates a perfect storm for various attack vectors including stored cross-site scripting, malicious file hosting, and potentially remote code execution scenarios.
The operational impact of this vulnerability extends beyond simple unauthorized file uploads, as it creates a foundation for more sophisticated attacks within the application's architecture. When chained with other features such as static hosting capabilities or file retrieval mechanisms, the vulnerability becomes a critical entry point for attackers to establish persistent access to the system. The vulnerability aligns with CWE-434 which addresses insecure file upload handling, and specifically maps to ATT&CK technique T1195.001 for Unsecured Credentials and T1059.001 for Command and Scripting Interpreter, demonstrating how the initial compromise can lead to more severe outcomes. The attack chain typically begins with the initial file upload bypass, followed by exploitation of stored files through other system features, potentially leading to full system compromise. Organizations using Flowise versions prior to 3.0.13 face significant risk as this vulnerability allows attackers to bypass authentication, upload malicious content, and establish persistent threats within their infrastructure.
Mitigation strategies for this vulnerability require immediate patching to version 3.0.13 which addresses the core validation issue. Organizations should implement comprehensive file validation mechanisms that include magic byte checking, filename extension validation, and proper MIME type verification independent of client-provided headers. The system should enforce strict content validation at multiple layers including file type detection, size limits, and behavioral analysis of uploaded content. Additional defensive measures include implementing proper access controls for file storage systems, monitoring file upload activities, and establishing automated scanning for malicious content. Network segmentation and application-level firewalls should be configured to limit access to sensitive endpoints, while regular security audits should verify that all upload endpoints properly validate file content rather than relying on client-provided metadata. The fix implemented in version 3.0.13 addresses the specific validation gap by ensuring that file content is properly verified regardless of client-supplied headers, thereby preventing the spoofing attack vector that enabled this vulnerability.