CVE-2026-56269: Flowise hardcoded JWT secret leaks

CISO Take

Flowise versions before 3.1.0 ship with a hardcoded default value ('Secre$t') for TOKEN_HASH_SECRET, the AES-256-CBC key used to encrypt user and workspace identifiers inside JWT token metadata. Any attacker who intercepts JWT tokens issued by a default-configured Flowise instance can trivially decrypt the meta field and enumerate internal user and workspace IDs — tenant boundaries become transparent. While the JWT signature check is separate and metadata tampering alone does not grant immediate access, knowing internal identifiers substantially lowers the bar for targeted privilege escalation attempts in multi-tenant deployments. The vulnerability has no public exploit and requires high existing privileges and local access (CVSS 4.6), but Flowise carries 104 CVEs in this package — teams running it should treat configuration hygiene as non-negotiable. Remediate by upgrading to Flowise 3.1.0 or setting TOKEN_HASH_SECRET to a cryptographically random 32-byte value in your environment before restarting the service.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Medium risk in isolation, elevated in multi-tenant Flowise deployments. The CVSS vector (AV:L/AC:H/PR:H/UI:R) constrains real-world exploitability significantly — an attacker needs pre-existing high-privilege access, local context, and must capture JWT tokens. However, the default secret 'Secre$t' is now publicly disclosed via the security advisory, eliminating its secrecy for any org running a default configuration. The primary risk is metadata-assisted privilege escalation in shared Flowise environments where knowing workspace IDs enables precise cross-tenant reconnaissance. Single-tenant deployments face lower immediate risk but should still rotate the secret to prevent future exposure.

How does the attack unfold?

Token Interception

Attacker with high-privilege access captures JWT tokens issued by the Flowise instance via network capture, log access, or session storage inspection.

AML.T0055

Metadata Decryption

Using the publicly disclosed default secret 'Secre$t', attacker AES-256-CBC decrypts the JWT meta field to extract plaintext internal user IDs and workspace IDs.

AML.T0106

Tenant Reconnaissance

Attacker enumerates extracted user and workspace identifiers to map the multi-tenant landscape and identify high-value targets for follow-on access.

AML.T0084

Privilege Escalation Attempt

Attacker re-encrypts manipulated workspace IDs using the known secret, injecting them into token metadata to probe unauthorized access to other tenants' agent configurations and stored credentials.

AML.T0091

Token Interception

Attacker with high-privilege access captures JWT tokens issued by the Flowise instance via network capture, log access, or session storage inspection.

AML.T0055

Metadata Decryption

Using the publicly disclosed default secret 'Secre$t', attacker AES-256-CBC decrypts the JWT meta field to extract plaintext internal user IDs and workspace IDs.

AML.T0106

Tenant Reconnaissance

Attacker enumerates extracted user and workspace identifiers to map the multi-tenant landscape and identify high-value targets for follow-on access.

AML.T0084

Privilege Escalation Attempt

Attacker re-encrypts manipulated workspace IDs using the known secret, injecting them into token metadata to probe unauthorized access to other tenants' agent configurations and stored credentials.

AML.T0091

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Flowise	npm	—	No patch

Do you use Flowise? You're affected.

How severe is it?

CVSS 3.1

4.6 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Local

AC High

PR High

UI Required

S Unchanged

C High

I Low

A None

What should I do?

6 steps

Upgrade to Flowise 3.1.0 or later immediately — the fix enforces a required, non-default TOKEN_HASH_SECRET.
If immediate upgrade is not possible, set TOKEN_HASH_SECRET to a cryptographically random value (e.g., 'openssl rand -hex 32') in the environment and restart the service.
Audit existing JWT tokens in transit — any token issued under the default secret should be invalidated by rotating sessions.
In multi-tenant deployments, review access logs for cross-workspace API calls using internal IDs as an indicator of compromise.
Detection: grep .env files and container configs for TOKEN_HASH_SECRET absence or the literal value 'Secre$t'.
Given Flowise's 104-CVE history, conduct a full configuration hygiene audit of all deployed instances.

How is it classified?

Data Extraction Auth Bypass Agent Framework AML.T0055 - Unsecured Credentials AML.T0084 - Discover AI Agent Configuration AML.T0106 - Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.1.5 - AI system security objectives

NIST AI RMF

GOVERN 1.1 - Policies and accountability for AI risk

OWASP LLM Top 10

LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-56269?

Flowise versions before 3.1.0 ship with a hardcoded default value ('Secre$t') for TOKEN_HASH_SECRET, the AES-256-CBC key used to encrypt user and workspace identifiers inside JWT token metadata. Any attacker who intercepts JWT tokens issued by a default-configured Flowise instance can trivially decrypt the meta field and enumerate internal user and workspace IDs — tenant boundaries become transparent. While the JWT signature check is separate and metadata tampering alone does not grant immediate access, knowing internal identifiers substantially lowers the bar for targeted privilege escalation attempts in multi-tenant deployments. The vulnerability has no public exploit and requires high existing privileges and local access (CVSS 4.6), but Flowise carries 104 CVEs in this package — teams running it should treat configuration hygiene as non-negotiable. Remediate by upgrading to Flowise 3.1.0 or setting TOKEN_HASH_SECRET to a cryptographically random 32-byte value in your environment before restarting the service.

Is CVE-2026-56269 actively exploited?

No confirmed active exploitation of CVE-2026-56269 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-56269?

1. Upgrade to Flowise 3.1.0 or later immediately — the fix enforces a required, non-default TOKEN_HASH_SECRET. 2. If immediate upgrade is not possible, set TOKEN_HASH_SECRET to a cryptographically random value (e.g., 'openssl rand -hex 32') in the environment and restart the service. 3. Audit existing JWT tokens in transit — any token issued under the default secret should be invalidated by rotating sessions. 4. In multi-tenant deployments, review access logs for cross-workspace API calls using internal IDs as an indicator of compromise. 5. Detection: grep .env files and container configs for TOKEN_HASH_SECRET absence or the literal value 'Secre$t'. 6. Given Flowise's 104-CVE history, conduct a full configuration hygiene audit of all deployed instances.

What systems are affected by CVE-2026-56269?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-tenant AI platforms, LLM workflow orchestration.

What is the CVSS score for CVE-2026-56269?

CVE-2026-56269 has a CVSS v3.1 base score of 4.6 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-tenant AI platformsLLM workflow orchestration

MITRE ATLAS Techniques

AML.T0055 Unsecured Credentials

AML.T0084 Discover AI Agent Configuration

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.1.5

NIST AI RMF: GOVERN 1.1

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

Flowise before 3.1.0 (npm package flowise, versions 3.0.13 and earlier) uses a weak hardcoded default value 'Secre$t' for the TOKEN_HASH_SECRET environment variable in packages/server/src/enterprise/utils/tempTokenUtils.ts when the variable is not configured. This secret derives the AES-256-CBC key used to encrypt user IDs and workspace IDs in the 'meta' field of JWT tokens. An attacker who knows the default secret can decrypt this metadata to extract internal user and workspace identifiers, and re-encrypt manipulated values such as altered user or workspace IDs. Because the JWT signature is validated separately, decrypting or tampering with this metadata does not by itself grant access, but the disclosure of internal identifiers and possible metadata manipulation could aid privilege escalation or unauthorized data access.

Exploitation Scenario

An attacker with high-privilege access to a Flowise instance — such as a compromised admin account or insider threat — intercepts JWT tokens issued to other users via network capture, log access, or session storage. Using the publicly known default secret 'Secre$t', they AES-256-CBC decrypt the token's meta field to extract plaintext user IDs and workspace IDs for all tenants. Armed with these identifiers, they craft targeted API requests to probe workspace-specific endpoints for data belonging to other organizations or teams. In a second stage, they re-encrypt manipulated workspace IDs using the known secret and inject them into token metadata, attempting to access other tenants' agent configurations, stored API keys, or workflow data by exploiting any server-side logic that trusts the decrypted meta values beyond the JWT signature check.

Weaknesses (CWE)

CWE-798 Use of Hard-coded Credentials

CWE-798 — Use of Hard-coded Credentials: The product contains hard-coded credentials, such as a password or cryptographic key.

[Architecture and Design] For outbound authentication: store passwords, keys, and other credentials outside of the code in a strongly-protected, encrypted configuration file or database that is protected from access by all outsiders, including other local users on the same system. Properly protect the key (CWE-320). If you cannot use encryption to protect the file, then make sure that the permissions are as restrictive as possible [REF-7]. In Windows environments, the Encrypted File System (EFS) may provide some protection.
[Architecture and Design] For inbound authentication: Rather than hard-code a default username and password, key, or other authentication credentials for first time logins, utilize a "first login" mode that requires the user to enter a unique strong password or key.

Source: MITRE CWE corpus.