Six Critical Flowise CVEs: Can A Prompt Run Server Code?

August 13, 2026

Six critical Flowise CVEs include public prompt-to-code paths and authenticated sandbox escapes. Learn who is affected, what is fixed, and what to audit.

Six critical Flowise CVEs describe routes from AI-agent features to server-side code execution. The most alarming paths involve public CSV or Airtable Agent chatflows: an unauthenticated prompt could influence generated Python, bypass regex-based validation, and reach data, internal services, or the host. Other flaws required a valid Flowise account or specific settings. Operators should upgrade to at least Flowise 3.1.4 and audit exposure, credentials, logs, and containers.

The CVE records appeared on August 13, 2026, but these are not six brand-new zero-days discovered today. Flowise had already released fixes, and the underlying repository advisories were public in July. The fresh event is the coordinated NVD and GitHub Advisory Database publication that makes the scope and CVE identifiers easier to find.

What Is Confirmed

Ten Flowise vulnerability records were published through NVD and the GitHub Advisory Database on August 13. Six carry critical severity ratings. The strongest underlying evidence is not a roundup or social post; it is the detailed security advisories in the FlowiseAI/Flowise repository.

Flowise is a widely used open-source platform for visually building AI workflows, chatbots, tools, and agents. Its GitHub repository had approximately 55,367 stars and 24,888 forks when this article was researched. That scale makes the update relevant even though no current source establishes how many live installations remain vulnerable.

The six critical records are:

• CVE-2026-73483: an authenticated user could escape Flowise's JavaScript sandbox through a permitted Puppeteer dependency, execute operating-system commands as the Flowise process, and read host files. The upstream advisory says the official Docker image ran that process as root. Versions 3.0.8 through 3.1.2 required ALLOW_BUILTIN_DEP=true for this path; older affected releases exposed the dependency by default.
• CVE-2026-73602: a separate authenticated path could bypass locale-path validation in Flowise's vm2 JavaScript environment and load malicious JavaScript from the document store. The vendor-repository advisory identifies 3.1.3 as the patched release.
• CVE-2026-73601: an authenticated user could manipulate environment variables and command arguments in a Custom MCP node configured for the stdio protocol. The Custom MCP advisory describes command-execution paths involving Python or Node.js and lists 3.1.3 as the fix.
• CVE-2026-73486: an authenticated attacker could put obfuscated Python into the CSV Agent node's custom CSV-reading field. The CSV code-injection advisory says a static blocklist could be bypassed and that the resulting code ran in an environment with host access.
• CVE-2026-73485: an unauthenticated attacker who could send prompts to a chatflow using the Airtable Agent could try to make the model produce malicious Python. The Airtable Agent advisory describes execution outside a meaningful host-security boundary.
• CVE-2026-73487: public prediction requests to configured CSV or Airtable Agent flows could use prompt injection to steer generated Pandas code around a regex validator. The validator-bypass advisory describes data access, server-side request forgery, and code-execution consequences.

Most of the bundle was fixed in Flowise 3.1.3, released June 25. A separate medium-severity text-to-speech authorization issue was fixed in 3.1.4, released July 29. Because 3.1.4 is the newer release and covers that additional issue, 3.1.4 is the minimum practical target for an operator responding to the complete August 13 set. A newer supported version should take precedence if Flowise publishes one.

The current records do not say that OpenVeil uses Flowise, and the local OpenVeil product documentation does not identify Flowise as a dependency. This article is about the security boundary of self-hosted Flowise deployments, not a disclosure that OpenVeil was affected.

What Is Still Unclear

No primary source reviewed for this article reports exploitation in the wild of these six newly assigned critical CVEs. Flowise has faced exploitation of a different older vulnerability, but that is not proof that attackers are using this set.

The GitHub Advisory Database entries created from NVD are currently marked unreviewed. That label matters, but it does not erase the underlying evidence: the corresponding Flowise repository advisories identify affected packages, patched versions, prerequisites, technical paths, and fixes. Operators should use those upstream advisories and release artifacts as the working source of truth while database records mature.

The exact exposure of any individual installation depends on its version and configuration. A Flowise server is not automatically vulnerable to every path merely because it exists:

• Some flaws require an authenticated account with access to a particular endpoint.
• Some require a public or otherwise reachable chatflow using a CSV or Airtable Agent node.
• The Puppeteer sandbox escape on newer affected versions requires ALLOW_BUILTIN_DEP=true.
• The Custom MCP path requires the stdio protocol and a reachable feature path.
• Host impact depends on the Flowise process user, container privileges, mounted volumes, reachable services, and outbound network access.

The public sources also do not provide a reliable global count of vulnerable internet-facing Flowise instances. Repository popularity, historical exposure estimates, and old scans cannot be converted into a current affected-host count.

Can One Prompt Really Become Server Code?

For the CSV and Airtable Agent cases, the answer is potentially yes, when a vulnerable agent flow is configured and reachable.

The important design chain is longer than “the model ran a command”:

1. A public or unauthenticated user sends text to a chatflow.
2. The agent asks a language model to produce Python for working with CSV or Airtable data.
3. Flowise tries to restrict that generated code with string matching or regex-based checks.
4. The model output uses a permitted operation, obfuscation, or unblocked Pandas function that has a more powerful effect than the validator anticipated.
5. The resulting code reaches files, network locations, or operating-system behavior outside the intended data-analysis task.

That is why prompt injection becomes dangerous in an agent framework. A hostile prompt is still text until a downstream component translates model output into code or a privileged tool call. The security boundary is the executor, validator, sandbox, process account, container, network policy, and credential scope—not the wording of the system prompt.

The authenticated JavaScript and Custom MCP flaws follow a different path. They do not show that any anonymous visitor could compromise every Flowise server. They show that an authenticated user with access to an ostensibly restricted execution feature could cross the intended boundary and act as the Flowise process.

Those distinctions should remain visible in incident triage. Treating all six CVEs as either “just prompt injection” or “instant unauthenticated root everywhere” would be inaccurate.

Why Regex Blocklists Fail Around AI-Generated Code

A blocklist looks for known-dangerous words or forms. It can stop simple examples, but it has a structural weakness: Python, JavaScript, libraries, and data frameworks provide many ways to express equivalent behavior.

Pandas is not only a spreadsheet calculator. It can read and write multiple formats, accept URLs in some operations, transform data through callable functions, and interact with files. A validator that permits “normal Pandas operations” must reason about behavior, not merely method names.

Language models increase the challenge because they can produce varied code in response to natural-language instructions. Even without malicious intent, a model may choose an unexpected library function. With adversarial instructions, the model can be steered toward alternate syntax that a static filter did not anticipate.

The durable lesson is not that one more regex should be added. Untrusted generated code needs a real isolation boundary with minimal filesystem, process, credential, and network authority. A validator can be defense in depth, but it should not be the control that prevents a prompt from reaching production secrets or the host operating system.

What Data Could Be Exposed Besides The Server?

Remote code execution receives the dramatic headline, but the data path may matter more to many Flowise operators.

An AI workflow server often holds or can reach:

• model-provider API keys;
• database and vector-store credentials;
• OAuth client secrets and connector tokens;
• uploaded CSV files and documents;
• conversation and workflow records;
• internal APIs and cloud metadata endpoints;
• mounted project or persistence directories; and
• billing-backed voice or media credentials.

The August 13 set also includes a high-severity credential-redaction issue. Its upstream advisory says an authenticated user with credential-view permission could retrieve decrypted secrets, including connection URLs, private keys, and API keys. A medium-severity customer endpoint issue involved unauthorized access to email addresses, balances, currencies, and billing configuration by changing a customer identifier.

Another medium-severity flaw affected private-chatflow text-to-speech. The TTS advisory says an unauthenticated caller who knew a chatflow UUID could consume stored OpenAI or ElevenLabs credentials to generate audio and charge the owner's account. Flowise 3.1.4 fixed that route.

These are separate authorization problems, but they reinforce the same operational point: patching code execution without reviewing exposed secrets, usage, and audit records can leave the response incomplete.

Use The FLOW Audit After Updating Flowise

Updating is the first action, not the last. Use this four-part FLOW audit to investigate the actual deployment.

F — Find Every Version And Feature Path

Inventory production, staging, development, abandoned demos, Docker images, global npm installations, and cloned source builds. Record the Flowise and flowise-components versions rather than trusting an image tag such as latest.

Identify whether each deployment uses:

• CSV Agent or Airtable Agent nodes;
• custom JavaScript functions;
• Custom MCP with stdio;
• ALLOW_BUILTIN_DEP=true;
• public prediction endpoints;
• public text-to-speech routes; or
• multiple user workspaces and shared roles.

Upgrade to at least 3.1.4, then confirm the running process reports the expected version. Rebuilding an image is not proof that an old container stopped receiving traffic.

L — Limit Reachability And Roles

Remove public reachability from flows that do not need it. Require authentication before accepting prompts where the use case permits it. Review which users can create custom functions, view credentials, configure MCP commands, publish flows, or call internal node endpoints.

Do not expose an administration surface merely because a chat endpoint must be public. Put the management plane behind a separate access control and network boundary.

O — Observe For Abuse And Rotate Secrets

Review logs from the Flowise service, reverse proxy, container runtime, cloud provider, model providers, database, and identity system. Useful signals include unexpected child processes, shells, package downloads, access to cloud metadata addresses, unexplained outbound destinations, large or unusual model-generated code blocks, credential reads, and unexpected TTS charges.

If exploitation cannot be ruled out, rotate credentials that the Flowise process could read or reach. Rotating only the Flowise login is not enough when provider keys, database passwords, OAuth secrets, or cloud tokens may have been accessible.

W — Weaken The Workload's Authority

Run the service as a non-root user. Avoid privileged containers, Docker-socket mounts, broad host-volume mounts, and unnecessary Kubernetes permissions. Restrict outbound traffic to destinations the workflow genuinely needs. Use short-lived, narrowly scoped credentials and separate them by environment.

Place untrusted generated code in a disposable isolation boundary with explicit CPU, memory, time, filesystem, process, and network limits. The goal is to make a model mistake or validator bypass boring: the code should have nowhere important to go.

Does Updating To Flowise 3.1.4 Finish The Incident Response?

No. Updating closes the documented paths, but incident response asks whether an affected version was reachable and whether anyone used it.

A practical sequence is:

1. Preserve relevant logs and configuration before replacing containers or hosts.
2. Remove public exposure or place temporary access controls in front of the service.
3. Upgrade Flowise and related packages to a supported release at or above 3.1.4.
4. Confirm the running version on every instance.
5. Search for suspicious process, file, network, API-usage, and credential-access activity.
6. Rotate secrets when access cannot be excluded.
7. Rebuild compromised or uncertain systems from trusted artifacts instead of assuming a package update removes persistence.
8. Re-test the public and authenticated routes using harmless synthetic inputs.

If the service was exposed and handles valuable credentials, involve the organization's security or incident-response team. A blog checklist cannot determine whether a particular host was compromised.

Where OpenVeil Fits—and Where It Does Not

OpenVeil is a hosted privacy-focused AI workspace for adults. It combines chat, browser-local normal chat history, web search, files, voice, image tools, video generation, and custom personas. OpenVeil documents that it does not use prompts, uploads, media, or outputs to train foundation models.

That is a different product boundary from operating a general-purpose Flowise agent builder. Someone who needs ordinary AI chat and media work may prefer a narrower managed workspace instead of exposing custom code, MCP commands, public agent flows, and server credentials.

OpenVeil does not make the Flowise CVEs go away. It is not a Flowise patch, a prompt-injection firewall, a sandbox guarantee, an incident-response service, or protection for unrelated servers. OpenVeil is also hosted: active requests still require processing by OpenVeil and necessary providers, and browser-local chat history does not mean fully offline, anonymous, or zero-log operation.

For the broader distinction, read Private AI Chat vs. Local AI, ChatGPT AgentForger: How One Link Created A Rogue AI Agent, and OpenAI's AI Models Hacked Hugging Face: How Did The Sandbox Fail?.

Frequently Asked Questions

Which Flowise version fixes the six critical CVEs?

The critical records reviewed here identify Flowise 3.1.3 as the patched release. The complete August 13 bundle includes a separate text-to-speech authorization issue fixed in 3.1.4, so operators should use at least 3.1.4 or a newer supported release.

Are all Flowise servers remotely exploitable without authentication?

No. Several critical paths require authentication or specific settings. The CSV and Airtable Agent prompt-injection paths can be unauthenticated when a vulnerable chatflow is publicly reachable and uses the affected node. Exposure must be evaluated per deployment.

Does a Docker container prevent host impact?

Not automatically. The advisory says the official Flowise image ran the service as root inside the container. Host risk increases with privileged mode, host mounts, Docker-socket access, excessive capabilities, broad network access, or powerful cluster credentials. A constrained container can reduce impact, but it is not proof of safety.

Were these six vulnerabilities exploited in the wild?

No reviewed primary source establishes in-the-wild exploitation of this six-CVE critical set. A different older Flowise vulnerability was reported exploited earlier in 2026. Keep the two claims separate.

Can a system prompt stop this kind of attack?

No. Instructions can reduce some harmful model behavior, but they are not a host-security boundary. The executor, sandbox, permissions, network policy, container configuration, and credential scope must contain generated code even when the model follows hostile instructions.

Is Flowise unsafe to use after patching?

The advisories do not support that blanket conclusion. They support upgrading, reviewing configuration, reducing exposed authority, and investigating affected deployments. Security depends on the patched version and the complete operating environment.

The Bottom Line

The August 13 Flowise CVE publication turns a scattered set of repository advisories into a clear warning: an AI agent's code executor and tool runtime are the real security boundary. In vulnerable configurations, a public prompt or authenticated feature call could cross from model-generated text into files, internal services, credentials, or operating-system commands.

Upgrade to at least Flowise 3.1.4, inventory every exposed flow and feature, investigate affected systems, rotate secrets when access cannot be ruled out, and run the service with far less authority than the host can provide. Do not rely on a system prompt or regex blocklist to contain hostile generated code.