If your team is using Flowise to build AI-powered chatbots or workflows, an attacker may have already slipped a backdoor onto your server — and it would look like nothing more than an uploaded file.
Who Is at Risk — and How Many People Is That?
Flowise is one of the most widely used open-source tools for building custom AI applications. It lets developers — and increasingly, non-developers — drag and drop components together to create chatbots, document analyzers, and automated workflows powered by large language models like ChatGPT or Claude. The project has accumulated over 35,000 stars on GitHub and is deployed by startups, enterprise teams, and solo developers across the world, many of whom run it on internet-facing servers.
The vulnerability, tracked as CVE-2026-41269 and rated HIGH severity, affects every version of Flowise before 3.1.0. Any organization running an older version with file upload features enabled is potentially exposed. That covers a significant slice of Flowise's user base, particularly teams that stood up an instance and haven't kept pace with updates.
What an Attacker Can Actually Do
Here's how the attack works in plain terms. Flowise lets users configure chatbots that can accept file uploads — think a customer support bot that lets users attach a PDF, or a research tool that processes documents. Behind the scenes, Flowise has a list of "allowed" file types so that only safe, expected files (like PDFs or images) can come through. The problem is that an attacker can tamper with that allowed-types list before uploading a file, sneaking JavaScript code onto the server disguised as a legitimate upload.
Once that malicious JavaScript file lands on the server, it doesn't just sit there harmlessly. Flowise runs on Node.js, a technology that can execute JavaScript files as live programs. So the attacker's uploaded file becomes a fully functional program running on your server — what security researchers call a web shell. Think of it as a remote control: the attacker can now issue commands to your server as if they were sitting at the keyboard. They can read your database credentials, steal API keys for your AI services, pivot into internal networks, delete data, or install additional malware.
What makes this particularly nasty is the word persistently in the official description. The web shell doesn't disappear when you restart the application. It stays on disk, waiting. Even if you don't notice the initial intrusion, the attacker retains a foothold they can return to days or weeks later — long after the window of obvious suspicious activity has closed.
The Technical Detail That Matters
The root cause is a server-side MIME type validation bypass in the Chatflow configuration's file upload settings. The frontend interface correctly blocks .js files from being selected in the browser — but the backend fails to enforce the same restriction independently. By directly modifying the upload configuration to add application/javascript as a permitted MIME type, an attacker bypasses the frontend gatekeeping entirely and pushes a Node.js web shell to persistent server storage. This is a textbook example of the vulnerability class known as unrestricted file upload (CWE-434), and it carries a CVSS score of 7.1.
Has This Been Exploited in the Wild?
As of publication, there is no confirmed active exploitation of this specific vulnerability. The fix was shipped in Flowise version 3.1.0, and the CVE was disclosed responsibly before widespread attacks could be documented. That's the good news.
The less comfortable news: Flowise has been targeted before. Security researchers have previously documented unauthenticated access vulnerabilities in earlier Flowise versions, and the platform has appeared in discussions on threat intelligence forums as a target of interest — largely because AI builders are increasingly run with elevated permissions and connected to sensitive API keys and data sources. Attackers follow value, and right now, AI infrastructure is extraordinarily valuable. The combination of a public proof-of-concept being theoretically straightforward to construct, and a large base of unpatched internet-facing instances, means the clock is ticking before someone weaponizes this.
What You Need to Do Right Now
The fix is clear and the steps are concrete. Do these three things:
-
Update to Flowise 3.1.0 or later — immediately.
This is the only complete fix. Runnpm install flowise@3.1.0or pull the latest Docker image (docker pull flowiseai/flowise:3.1.0) and redeploy. Do not wait for a scheduled maintenance window. If you are using a managed deployment through a cloud marketplace, check whether your provider has pushed the update automatically and verify the running version in your admin panel. -
Audit your upload directories for unexpected
.jsfiles.
If you were running a version prior to 3.1.0 on an internet-accessible instance, treat it as potentially compromised. Search your Flowise storage and upload directories for any.jsfiles that should not be there. On Linux, a quickfind /path/to/flowise/uploads -name "*.js"is a starting point. Any unfamiliar JavaScript files should be treated as malicious until proven otherwise. -
Rotate every API key and credential your Flowise instance could access.
That means your OpenAI API key, any database connection strings stored in flows, your Flowise admin credentials, and any cloud credentials associated with the host machine. If a web shell was present even briefly, assume all secrets the application could reach have been read. Regenerate them, revoke the old ones, and review access logs for anomalous outbound connections over the past 30–90 days.
CVE-2026-41269 was patched in Flowise 3.1.0. If you are a security researcher with additional technical findings related to this vulnerability, responsible disclosure channels are available through the Flowise GitHub repository.