Flowise and Langflow Security Guide: Lock Down Low-Code Agent Builders

Flowise and Langflow let teams build LLM and agent workflows in a browser, which means a single server holds model provider keys, vector database credentials, tool tokens and the ability to run code, and that server has repeatedly been attacked through flaws listed in CISA's Known Exploited Vulnerabilities catalogue. Langflow alone has six entries in that catalogue as checked on 27 October 2026, starting with the unauthenticated code execution flaw CVE-2025-3248 that attackers used to dump server environment variables. Both tools were designed as developer workbenches and ship features that run user-supplied code by design. This guide explains how identity and access work in each, where privileged access sits, how they store and use credentials, what to log, a hardening baseline and the misconfigurations that recur. It is for platform, application security and AI engineering teams that host either tool. Framework-level controls for code-first agent stacks are covered in the Securing Agent Frameworks Guide.

Key takeaways

• These are code execution platforms. Custom components in Langflow and JavaScript function nodes in Flowise run code on the server by design, so anyone who can build flows can usually reach the host and its secrets unless you block those features.
• Published flows can be public by default. Flowise documents that a chatflow is available to anyone with its ID until you assign an API key; Langflow supports anonymous public-flow links. Inventory which flows are reachable without credentials.
• Change the security defaults explicitly. Langflow's documentation calls its default CORS settings a production risk and leaves self-registration enabled by default; Flowise warns that default JWT and session secrets let attackers forge tokens.
• The server is a credential vault. Both tools encrypt stored credentials with a key held next to the application. Protect that key, inject provider keys from a secrets manager and rotate everything on any suspected compromise.
• Patch to KEV timelines and keep the UI private. Exploited Langflow flaws have included missing authentication, code injection, cross-user flow execution and a CORS and cookie weakness. Do not expose either builder to the internet.

How identity and access work in Flowise and Langflow

• Langflow single-user versus multi-user: in single-user mode you are always a superuser and every API key has superuser privileges. In multi-user mode, non-superusers cannot use their keys on other users' resources. With LANGFLOW_API_KEY_SOURCE=env there is one key for the whole deployment and successful authentication grants superuser privileges, so use it only for single-tenant automation.
• Auto-login is the critical switch: the Langflow documentation states that automatic login lets anyone who can reach the server act as the superuser. An explicit LANGFLOW_AUTO_LOGIN=true left in an old .env file overrides the newer safe default, and disabling auto-login does not revoke sessions or API keys issued earlier.
• Flowise flow-level keys: Flowise creates a DefaultKey in the API Keys section. Assigning keys per chatflow is the only built-in way to stop anonymous prediction calls, so treat "no key assigned" as "public".

Admin roles and privileged access

• Langflow superuser: created from LANGFLOW_SUPERUSER (default username langflow) and LANGFLOW_SUPERUSER_PASSWORD, which is required when auto-login is off. Startup now fails closed rather than accepting the legacy default password langflow. Only superusers can manage accounts through the Users API.
• Langflow superuser CLI: LANGFLOW_ENABLE_SUPERUSER_CLI defaults to true; the documentation recommends false to prevent unrestricted superuser creation by anyone with shell access to the host.
• Flowise administrator: when migrating from the deprecated username and password method, Flowise requires authenticating with the existing FLOWISE_USERNAME and FLOWISE_PASSWORD before creating the new admin account, to prevent ownership claims. Complete that migration before exposing the instance to more users.
• Host and container access: anyone with access to the container, its environment or its data volume can read the encryption key and therefore every stored credential. Treat host access as equivalent to the platform's highest privilege and manage it through privileged access controls. See the Privileged Access Management Guide.
• Flow builders are privileged users: because flows can contain code execution components, "can build flows" is close to "can run code on the server". Limit builder accounts to people you would trust with shell access, or apply the component restrictions below.

Integrations, API tokens and service accounts

Langflow can omit API keys and tokens from flow data in its database with LANGFLOW_REMOVE_API_KEYS=True, which reduces what a database dump or flow export leaks. Langflow also requires a separate allowlist, LANGFLOW_PROVIDER_CREDENTIAL_ALLOWED_HOSTS, before an API key from the server environment is sent to a custom provider endpoint, which prevents a flow builder from redirecting the server's key to an attacker's host. See the API Key Management Guide and the LLMjacking Guide for why these keys are targeted.

Logging and detection

• Application logs: Flowise writes logs at LOG_LEVEL (default info); Langflow records API key usage counts and last use by default. Forward both to your SIEM and keep the reverse proxy access log as the authoritative record of who called which endpoint.
• Exploit indicators: requests to code validation or component build endpoints from unauthenticated or unusual sources, and child processes such as shells, curl or package managers spawned by the application process. CVE-2025-3248 was exploited through /api/v1/validate/code.
• Credential use from elsewhere: provider keys stored in the builder used from IP addresses outside your hosting ranges, or sudden spend increases. Attackers who exploited CVE-2025-3248 dumped all environment variables to their server.
• Account and configuration changes: new users (especially self-registered), activation of accounts, new API keys, flows switched to public, and changes to environment configuration on restart.
• Tracing caution: Langflow notes that external tracing integrations are process-wide, so on a shared server every user's flow inputs and outputs go to the same tracing project. Use built-in local tracing on shared servers.

Detection mapping: Exploit Public-Facing Application (T1190), Python (T1059.006), Credentials In Files (T1552.001) and Cloud Instance Metadata API (T1552.005) in ATT&CK; Exploit Public-Facing Application (AML.T0049) and Cost Harvesting (AML.T0034) in MITRE ATLAS.

Metrics that show the controls work:

• Number of Flowise or Langflow instances reachable from the internet (target zero).
• Percentage of published flows that require an API key or SSO (target 100% unless approved as public).
• Days from a new KEV entry or vendor security release to patched production (target inside the KEV due date).
• Number of instances still using default JWT, session or encryption secrets (target zero).
• Number of provider keys held by builders without spend limits (target zero).

Hardening baseline

Langflow

1. Set LANGFLOW_AUTO_LOGIN=False, set a strong LANGFLOW_SUPERUSER_PASSWORD, a random LANGFLOW_SECRET_KEY, and deploy behind a reverse proxy with authentication, as the documentation advises.
2. Set LANGFLOW_ENABLE_SIGNUP=False, keep LANGFLOW_NEW_USER_IS_ACTIVE=False and set LANGFLOW_ENABLE_SUPERUSER_CLI=false.
3. Replace the wildcard CORS defaults with exact origins in LANGFLOW_CORS_ORIGINS, and set LANGFLOW_ACCESS_SECURE and LANGFLOW_REFRESH_SECURE to True for HTTPS.
4. Where users you do not fully trust can build flows, set LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false, LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true, keep LANGFLOW_RESTRICT_LOCAL_FILE_ACCESS=true, and set LANGFLOW_TWEAKS_POLICY to declared or off. The documentation states these are authorisation controls, not an isolation boundary.
5. Keep LANGFLOW_SSRF_PROTECTION_ENABLED=true, enable connector SSRF validation, set LANGFLOW_CONNECTOR_SSRF_ALLOW_LOOPBACK=false on shared servers and allowlist only required internal hosts.
6. Keep webhook authentication and login rate limiting enabled.

Flowise

1. Run v3.0.1 or later with email and password authentication, set APP_URL, and set JWT_AUTH_TOKEN_SECRET, JWT_REFRESH_TOKEN_SECRET, EXPRESS_SESSION_SECRET and TOKEN_HASH_SECRET to random values. Consider shortening the 90-day refresh token lifetime.
2. Assign an API key to every chatflow and agentflow that is not deliberately public, and restrict CORS_ORIGINS and IFRAME_ORIGINS to the sites that embed them.
3. Store the credential encryption key in AWS Secrets Manager (SECRETKEY_STORAGE_TYPE=aws) or inject it from your secrets manager; do not leave it on the data volume.
4. Keep CUSTOM_MCP_SECURITY_CHECK=true, HTTP_SECURITY_CHECK=true and PATH_TRAVERSAL_SAFETY=true; prefer CUSTOM_MCP_PROTOCOL=sse; add internal hosts and metadata addresses to HTTP_DENY_LIST.
5. Keep function node dependencies to an explicit list with TOOL_FUNCTION_EXTERNAL_DEP rather than ALLOW_BUILTIN_DEP=true or TOOL_FUNCTION_BUILTIN_DEP=*, and use DISABLED_NODES to remove code execution nodes you do not need. Flowise's own advisories in 2026 included NodeVM sandbox escapes, so do not rely on the sandbox alone.

Both

1. Run in a container as a non-root user with a read-only root filesystem where supported, no host mounts, egress limited to approved model and tool endpoints, and instance metadata blocked.
2. Put the UI and management API on a private network behind SSO; expose only the specific prediction endpoints that applications need, through an API gateway.
3. Subscribe to the projects' security advisories and the CISA KEV feed, and patch within KEV due dates. See the Vulnerability Management Guide.
4. Roll out changes in staging first: disabling auto-login or custom components breaks existing flows and scripts, so run the main flows for a week, fix breakages by moving code into reviewed components, then apply to production. Keep the previous environment file and database backup for rollback, but never roll back to auto-login on a reachable server.

Common misconfigurations

• Internet-facing builder on an old release: the Langflow CVE-2025-3248 exploitation hit servers before 1.3.0, ran Python without authentication and sent every environment variable to the attacker. The JADEPUFFER agentic ransomware case began the same way and then used default credentials on connected systems to destroy a production database.
• Auto-login left on: an old .env with LANGFLOW_AUTO_LOGIN=true survives an upgrade and makes every visitor a superuser.
• Public flows by omission: Flowise chatflows deployed without an API key, so anyone who finds the flow ID in an embed can call the model at your cost.
• Wildcard CORS with credentials: CISA's KEV entry for CVE-2025-34291 describes an overly permissive CORS configuration combined with a SameSite=None refresh cookie that let a malicious web page obtain tokens and execute code.
• Shared multi-tenant server with code execution enabled: treating Langflow's multi-user mode or Flowise workspaces as isolation while custom components and function nodes remain available. CVE-2026-55255 in KEV let an authenticated Langflow user run another user's flow by specifying its ID.
• Admin-grade keys in flows: root database passwords and unrestricted provider keys stored in the builder, turning any code execution flaw into a data and spend incident.

Framework mapping

Practitioner checklist

• Find every Flowise and Langflow instance, including proof-of-concept servers, and record owner, version and exposure.
• Take the UI and management API off the internet and put them behind SSO.
• Disable Langflow auto-login and self-registration; complete the Flowise v3 authentication migration.
• Replace default JWT, session and encryption secrets with values from a secrets manager.
• Assign API keys to every non-public flow and review which flows are public.
• Restrict or block custom code components and function nodes on shared servers.
• Keep SSRF, MCP and path traversal protections on, and block metadata endpoints.
• Scope every stored provider and database credential, with spend limits and least-privilege users.
• Patch against each new KEV entry within its due date and rotate all stored credentials after any suspected compromise.

Standards and references

• Langflow: API keys and authentication
• Flowise: Application authorization
• Flowise: Flows authorization
• Flowise: Environment Variables
• FlowiseAI: Flowise security advisories
• CISA: Known Exploited Vulnerabilities Catalog
• OWASP: Top 10 for LLM Applications 2025
• MITRE ATT&CK: Exploit Public-Facing Application

Related NHI Mgmt Group resources: Securing Agent Frameworks Guide · LangChain and LangGraph Security Guide · AI App Builder Security Guide · AI Agent Sandboxing and Code Execution Guide · Secrets Management Guide