CVE-2026-56271: Authentication Bypass via Hardcoded JWT Secrets in Flowise Enterprise Passport Middleware

Flowise is a visual builder for developing applications utilizing Large Language Models (LLMs) and AI agents. It features an enterprise authentication subsystem implemented via Passport.js middleware to manage secure sessions and restrict API access to authenticated users.

The vulnerability, designated as CVE-2026-56271, resides in the server module's configuration parsing logic. When enterprise authentication is enabled, the platform relies on JSON Web Tokens (JWTs) to authenticate requests. However, the system contains fallback logic that automatically defaults to static, hardcoded cryptographic values if the administrator has not configured custom secrets.

This behavior violates fundamental cryptographic principles by exposing critical trust assets. The vulnerability is classified under CWE-321 (Use of Hard-coded Cryptographic Key) and CWE-327 (Use of a Broken or Risky Cryptographic Algorithm). Unauthenticated attackers can exploit this logic remotely to gain unauthorized access to the application.

The root cause of this vulnerability lies within the initialization sequence of the enterprise passport middleware, located at packages/server/src/enterprise/middleware/passport/index.ts. To authenticate API requests, the server relies on the verification of JWTs supplied in HTTP headers.

During initialization, the application attempts to read several critical configuration parameters from the environment. These include JWT_AUTH_TOKEN_SECRET, JWT_REFRESH_TOKEN_SECRET, JWT_AUDIENCE, and JWT_ISSUER. If these parameters are missing, instead of halting initialization or raising a fatal configuration exception, the middleware proceeds using hardcoded fallbacks.

The default values utilized by the application are 'auth_token' for the authentication token secret, 'refresh_token' for the refresh token secret, 'AUDIENCE' for the expected token audience, and 'ISSUER' for the expected token issuer. Because these strings are publicly available in the open-source repository, any instance of Flowise deployed without these environment variables relies on the exact same static key material to verify session signatures.

The core flaw can be observed in the variable assignment logic where environment configuration is evaluated. If the left-hand operand of the logical OR operator is undefined, the program evaluates the right-hand operand, which contains the static string literal.

// VULNERABLE COMPONENT
// packages/server/src/enterprise/middleware/passport/index.ts
 
const authSecret = process.env.JWT_AUTH_TOKEN_SECRET || 'auth_token';
const refreshSecret = process.env.JWT_REFRESH_TOKEN_SECRET || 'refresh_token';
const audience = process.env.JWT_AUDIENCE || 'AUDIENCE';
const issuer = process.env.JWT_ISSUER || 'ISSUER';

To remediate this structural flaw, the application must completely eliminate hardcoded secrets from its execution paths. In secure designs, the application either throws a fatal error during bootstrap when required configurations are absent, or dynamically generates unique, high-entropy secrets in memory during startup.

// PATCHED COMPONENT
// Utilizing crypto package to prevent predictable fallback keys
import crypto from 'crypto';
 
// Generate a high-entropy, ephemeral secret if environment configuration is absent
const dynamicAuthSecret = process.env.JWT_AUTH_TOKEN_SECRET || crypto.randomBytes(32).toString('hex');
const dynamicRefreshSecret = process.env.JWT_REFRESH_TOKEN_SECRET || crypto.randomBytes(32).toString('hex');
 
// Enforce configuration validation for claims parameters
const audience = process.env.JWT_AUDIENCE;
const issuer = process.env.JWT_ISSUER;
 
if (!audience || !issuer) {
    throw new Error('Initialization failure: JWT_AUDIENCE and JWT_ISSUER must be explicitly declared');
}

By implementing dynamic fallback values, any session tokens forged using the static default values will fail validation because the server-side validation key is now unique to the runtime instance and completely unpredictable.

Exploitation of CVE-2026-56271 requires no specialized privileges, user interaction, or advanced cryptographic analysis. The attack complexity is low. An attacker must first confirm that the target instance is running a vulnerable version of Flowise and has not had its default JWT configuration altered.

The attacker then constructs a malicious JWT. The token header is configured with standard hashing algorithms such as HMAC SHA-256 (HS256). The payload is crafted with claims identifying the user as an administrator, accompanied by the standard 'AUDIENCE' and 'ISSUER' claims. Finally, the attacker signs the serialized header and payload using the hardcoded cryptographic key 'auth_token':

{
  "alg": "HS256",
  "typ": "JWT"
}
{
  "sub": "admin-user-id-or-email",
  "role": "admin",
  "aud": "AUDIENCE",
  "iss": "ISSUER",
  "exp": 1924905600
}

Once the forged token is generated, the attacker attaches it to the Authorization header of an HTTP request directed at a protected API endpoint (e.g., Authorization: Bearer <forged_token>). The server receives the request, attempts validation using the static secret, and admits the request because the signature matches.

The security impact of successful exploitation is complete administrative compromise of the affected Flowise instance. Because Flowise acts as an orchestrator for Large Language Models and AI agents, it holds sensitive system integration configurations, including API keys for model providers (e.g., OpenAI, Anthropic, Cohere), database connection strings, and vector database credentials.

By bypassing authentication, an attacker gains full access to these secrets. They can modify existing AI pipelines, inject malicious prompts (prompt injection attacks), redirect data streams, or read private chat transcripts stored in the system. If the Flowise instance is configured to execute shell tools or custom Python scripts, an administrative compromise can easily lead to Remote Code Execution (RCE) on the host machine.

The vulnerability is rated as Critical with an NVD CVSS v3.1 score of 9.8. This score reflects the combination of zero-privilege remote access, low exploitation complexity, and extreme impact across confidentiality, integrity, and availability metrics.

The primary remediation path is upgrading the Flowise deployment to version 3.1.0 or later. This version contains changes to how authentication tokens are validated, preventing fallback to known static keys. Developers must ensure that all dependencies, including flowise, flowise-ui, and flowise-components, are updated simultaneously.

If immediate upgrading is unfeasible, administrators must enforce configuration hardening by manually defining high-entropy keys within the environment variables. The configuration requires setting JWT_AUTH_TOKEN_SECRET and JWT_REFRESH_TOKEN_SECRET to randomized strings of at least 32 characters, alongside specific, unique values for JWT_AUDIENCE and JWT_ISSUER.

Deployers must also audit existing configurations. If the application was previously run with default values, any existing sessions must be invalidated immediately. Changing the secrets will automatically expire all active sessions, forcing users to authenticate against the newly defined security parameters.