CVE-2026-30821 is a critical flaw (CVSS 9.8) in Flowise, the drag and drop builder for LLM flows. Before version 3.0.13, the attachments upload endpoint required no login and trusted the client's declared file type. Upgrade to 3.0.13, then review what has been stored in your upload storage.
What's affected
Per the GitHub advisory, Flowise versions up to and including 3.0.12 are affected, and 3.0.13 is the patched release. The NVD text says versions before 3.0.13.
The advisory names the route /api/v1/attachments/:chatflowId/:chatId and says it was listed in WHITELIST_URLS, the list of paths that skip authentication. The npm package is flowise. Docker images built from older tags are affected too.
How to check if you're exposed
Check the version you run:
npm ls flowise
docker ps --format '{{.Image}}' | grep -i flowise
If Flowise is reachable from the internet or a shared network, also check which storage it writes uploads to. The advisory says files persist in S3, Google Cloud Storage or on local disk. List recent objects in that location and look for file types you did not expect, such as scripts or HTML, stored under names that suggest documents.
What to do now
- Upgrade Flowise to 3.0.13 or later and redeploy. For Docker, pull a tag at or above 3.0.13.
- Put Flowise behind a reverse proxy or VPN with its own authentication until you have upgraded, and avoid exposing it to the open internet.
- Review the upload storage for unexpected files and remove anything you cannot account for.
- Check whether stored uploads are served back to users anywhere in your setup, because the advisory says a stored file can become an entry point for further attacks when chained with file retrieval or static hosting.
- Rotate API keys and credentials held in Flowise if you find suspicious uploads. Run the free in-browser dependency scan at https://gold.safeguard.sh/scan to see whether the affected package is in your lockfile or SBOM.
Why it matters
The advisory describes two mistakes that stack. First, the upload route was on the global authentication whitelist, so anyone could call it. Second, the server checked the declared MIME type but not the real file content or extension. A client can claim a file is a PDF while sending something else. The record files this as CWE-434, unrestricted upload of a file with a dangerous type.
The advisory says that on its own this is a critical entry point. Depending on what else is deployed, it can lead to stored cross-site scripting, hosting of malicious files, or remote code execution. Fixing this class of bug usually means requiring authentication on write endpoints and validating content on the server, never the client header. The record does not mark this CVE as exploited in the wild, and it is not in the CISA KEV catalog.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Can I rely on the allowed file type setting?
Not before 3.0.13. The advisory says the server trusted the Content-Type header supplied by the client.
Is a firewall rule enough?
It lowers exposure, but the advisory lists 3.0.13 as the fix. Upgrade and restrict network access.
Sources
Last reviewed: 19 October 2026.
