Flowise AI Flaw Exposes Hardcoded JWT Secrets, Enabling Full Auth Bypass

A newly disclosed vulnerability in Flowise, the popular open-source low-code platform for building AI agents and LLM workflows, could allow attackers to forge authentication tokens and take over any account, including admin accounts, without valid credentials.

The flaw, tracked as GHSA-cc4f-hjpj-g9p8, was published on April 15 by security researcher igor-magun-wd and stems from weak, hardcoded default values used to sign JSON Web Tokens (JWTs) in Flowise’s enterprise authentication middleware. It affects all versions up to and including 3.0.13 and was patched in 3.1.0.

The issue lives in packages/server/src/enterprise/middleware/passport/index.ts, lines 29-34, where Flowise defines its JWT signing parameters:

const jwtAudience = process.env.JWT_AUDIENCE || 'AUDIENCE'
const jwtIssuer = process.env.JWT_ISSUER || 'ISSUER'
const jwtAuthTokenSecret = process.env.JWT_AUTH_TOKEN_SECRET || 'auth_token'
const jwtRefreshSecret = process.env.JWT_REFRESH_TOKEN_SECRET || process.env.JWT_AUTH_TOKEN_SECRET || 'refresh_token'

If an administrator deploys Flowise without explicitly setting JWT_AUDIENCE, JWT_ISSUER, JWT_AUTH_TOKEN_SECRET, or JWT_REFRESH_TOKEN_SECRET, the application silently falls back to these publicly known, trivially guessable strings.

Flowise AI Flaw

Because the source code is open and indexed on GitHub, anyone can find these defaults and use them to sign their own valid JWTs effectively minting an authentication token for any user, with zero credentials required.

Researchers classified this under CWE-327 (Use of a Broken or Risky Cryptographic Algorithm) and CWE-321 (Use of Hard-Coded Cryptographic Key), and Kolega.dev’s deep code scan flagged the practical exploitability as high.

Beyond the weak defaults, the code contains a subtler design mistake: the refresh token secret falls back to the auth token secret if JWT_REFRESH_TOKEN_SECRET isn’t set independently.

That means a deployment that only configures JWT_AUTH_TOKEN_SECRET ends up using the same key for both access and refresh tokens — collapsing what should be two independent cryptographic boundaries into one. Compromise one token type, and the other falls with it.

The impact assessment is stark: complete authentication bypass, forged JWTs for any account, no authentication required to reach protected endpoints, and a direct path to admin-level escalation.

Given Flowise’s use in building AI agent pipelines often connected to internal data sources, APIs, and business logic a forged admin token could expose sensitive workflow configurations, credentials embedded in agent nodes, or connected third-party integrations.

Analysts note the vulnerability’s severity rating shows some inconsistency across disclosure fields (Critical in the summary table, Moderate elsewhere, with a CVSS 3.0 vector of AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N reflecting more constrained exploitation conditions). No CVE has been assigned as of publication.

Remediation

Security researchers recommend Flowise administrators:

Upgrade immediately to version 3.1.0 or later
Explicitly set all four JWT environment variables with cryptographically random values (256-bit minimum)
Never rely on .env.example placeholder values in production
Implement startup validation that throws an error if any JWT secret is missing
Configure independent secrets for auth and refresh tokens rather than allowing fallback chaining
Establish a JWT secret rotation policy going forward

Organizations running self-hosted Flowise instances, particularly in enterprise or multi-tenant configurations, should treat this as a priority patch given the low barrier to exploitation and the severity of potential account takeover.