GHSA-m7mq-85xj-9x33: Flowise hardcoded default key

Q: Is GHSA-m7mq-85xj-9x33 actively exploited?

No confirmed active exploitation of GHSA-m7mq-85xj-9x33 has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-m7mq-85xj-9x33?

1. PATCH: Upgrade to Flowise 3.1.0 immediately — this version enforces strong key requirements. 2. ENV VAR: Set TOKEN_HASH_SECRET to a cryptographically random value with minimum 32 bytes of entropy (e.g., openssl rand -hex 32). 3. VERIFY: Confirm TOKEN_HASH_SECRET is set in all deployment environments — check .env files, Docker Compose configs, Kubernetes Secrets, and CI/CD pipelines. 4. ROTATE: After setting a strong key, existing tokens will be invalidated — plan for re-authentication of active sessions. 5. AUDIT: Review Flowise access logs for anomalous JWT usage or unexpected workspace/user ID patterns that may indicate prior exploitation. 6. DETECT: Scan environment configs for the string 'Secre$t' or 'popcorn' across all deployments. 7. POSTURE: Apply defense-in-depth — ensure Flowise is not publicly internet-exposed without authentication, and review multi-tenant isolation controls.

Q: What systems are affected by GHSA-m7mq-85xj-9x33?

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

Q: What is the CVSS score for GHSA-m7mq-85xj-9x33?

GHSA-m7mq-85xj-9x33 has a CVSS v3.1 base score of 5.6 (MEDIUM).

CISO Take

Flowise, the popular open-source AI agent workflow builder, ships with a hardcoded default encryption key ('Secre$t') that is used to encrypt user and workspace identifiers embedded in JWT tokens — and this default is publicly disclosed in the source code repository. Any attacker who obtains a valid JWT from an unpatched Flowise instance can trivially decrypt the token's metadata field to extract internal user IDs and workspace IDs, laying the groundwork for targeted privilege escalation or cross-tenant enumeration. While no public exploit or CISA KEV entry exists, the default key is permanently disclosed post-advisory, meaning exploitation requires nothing beyond basic AES-256-CBC decryption knowledge and a valid JWT. The fix is straightforward: upgrade to Flowise 3.1.0 immediately and set TOKEN_HASH_SECRET to a cryptographically random minimum 32-byte value in your environment configuration — instances without this variable set remain vulnerable regardless of version until the env var is configured.

Sources: GitHub Advisory ATLAS CISA KEV

What is the risk?

The CVSS score of 5.6 (Medium) with a local attack vector and high privilege requirements understates the practical risk for internet-exposed Flowise deployments. The hardcoded key is permanently public knowledge post-disclosure, reducing real-world attacker effort to near-zero for anyone who holds a valid session JWT. Flowise is widely deployed as an AI agent orchestration platform, frequently handling sensitive assets including API keys for OpenAI/Anthropic/other LLM providers, RAG data sources, and multi-tenant workspace data. With 37 other CVEs already attributed to this package, Flowise has a pattern of security debt. The absence of a startup guard requiring TOKEN_HASH_SECRET means many production deployments are likely running with the weak default without operator awareness.

How does the attack unfold?

Initial Access

Attacker creates or compromises a legitimate Flowise account on an unpatched instance (<=3.0.13) to obtain a valid JWT.

AML.T0012

Credential Exploitation

Using the publicly disclosed default key 'Secre$t', attacker derives the AES-256-CBC key and decrypts the JWT 'meta' field to extract user ID and workspace ID.

AML.T0055

Lateral Movement

Attacker crafts modified JWT metadata with substituted workspace or user IDs, re-encrypts with the same default key, and attempts to access other tenants' resources via Flowise API.

AML.T0049

Impact

Unauthorized access to other workspaces exposes AI agent configurations, stored LLM API credentials, connected data sources, and conversation histories across the multi-tenant platform.

AML.T0085

Initial Access

Attacker creates or compromises a legitimate Flowise account on an unpatched instance (<=3.0.13) to obtain a valid JWT.

AML.T0012

Credential Exploitation

Using the publicly disclosed default key 'Secre$t', attacker derives the AES-256-CBC key and decrypts the JWT 'meta' field to extract user ID and workspace ID.

AML.T0055

Lateral Movement

Attacker crafts modified JWT metadata with substituted workspace or user IDs, re-encrypts with the same default key, and attempts to access other tenants' resources via Flowise API.

AML.T0049

Impact

Unauthorized access to other workspaces exposes AI agent configurations, stored LLM API credentials, connected data sources, and conversation histories across the multi-tenant platform.

AML.T0085

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Flowise	npm	<= 3.0.13	`3.1.0`

Do you use Flowise? You're affected.

How severe is it?

CVSS 3.1

5.6 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Local

AC High

PR High

UI Required

S Unchanged

C High

I High

A None

What should I do?

7 steps

PATCH

Upgrade to Flowise 3.1.0 immediately — this version enforces strong key requirements.
ENV VAR

Set TOKEN_HASH_SECRET to a cryptographically random value with minimum 32 bytes of entropy (e.g., openssl rand -hex 32).
VERIFY

Confirm TOKEN_HASH_SECRET is set in all deployment environments — check .env files, Docker Compose configs, Kubernetes Secrets, and CI/CD pipelines.
ROTATE

After setting a strong key, existing tokens will be invalidated — plan for re-authentication of active sessions.
AUDIT

Review Flowise access logs for anomalous JWT usage or unexpected workspace/user ID patterns that may indicate prior exploitation.
DETECT

Scan environment configs for the string 'Secre$t' or 'popcorn' across all deployments.
POSTURE

Apply defense-in-depth — ensure Flowise is not publicly internet-exposed without authentication, and review multi-tenant isolation controls.

How is it classified?

Auth Bypass Data Extraction Agent API AML.T0012 - Valid Accounts AML.T0049 - Exploit Public-Facing Application AML.T0055 - Unsecured Credentials AML.T0106 - Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.9.4 - Access Control

NIST AI RMF

GOVERN 6.1 - Policies and procedures for AI risk management

OWASP LLM Top 10

LLM08 - Excessive Agency / Weak Authentication

Frequently Asked Questions

What is GHSA-m7mq-85xj-9x33?

Flowise, the popular open-source AI agent workflow builder, ships with a hardcoded default encryption key ('Secre$t') that is used to encrypt user and workspace identifiers embedded in JWT tokens — and this default is publicly disclosed in the source code repository. Any attacker who obtains a valid JWT from an unpatched Flowise instance can trivially decrypt the token's metadata field to extract internal user IDs and workspace IDs, laying the groundwork for targeted privilege escalation or cross-tenant enumeration. While no public exploit or CISA KEV entry exists, the default key is permanently disclosed post-advisory, meaning exploitation requires nothing beyond basic AES-256-CBC decryption knowledge and a valid JWT. The fix is straightforward: upgrade to Flowise 3.1.0 immediately and set TOKEN_HASH_SECRET to a cryptographically random minimum 32-byte value in your environment configuration — instances without this variable set remain vulnerable regardless of version until the env var is configured.

Is GHSA-m7mq-85xj-9x33 actively exploited?

No confirmed active exploitation of GHSA-m7mq-85xj-9x33 has been reported, but organizations should still patch proactively.

How to fix GHSA-m7mq-85xj-9x33?

1. PATCH: Upgrade to Flowise 3.1.0 immediately — this version enforces strong key requirements. 2. ENV VAR: Set TOKEN_HASH_SECRET to a cryptographically random value with minimum 32 bytes of entropy (e.g., openssl rand -hex 32). 3. VERIFY: Confirm TOKEN_HASH_SECRET is set in all deployment environments — check .env files, Docker Compose configs, Kubernetes Secrets, and CI/CD pipelines. 4. ROTATE: After setting a strong key, existing tokens will be invalidated — plan for re-authentication of active sessions. 5. AUDIT: Review Flowise access logs for anomalous JWT usage or unexpected workspace/user ID patterns that may indicate prior exploitation. 6. DETECT: Scan environment configs for the string 'Secre$t' or 'popcorn' across all deployments. 7. POSTURE: Apply defense-in-depth — ensure Flowise is not publicly internet-exposed without authentication, and review multi-tenant isolation controls.

What systems are affected by GHSA-m7mq-85xj-9x33?

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

What is the CVSS score for GHSA-m7mq-85xj-9x33?

GHSA-m7mq-85xj-9x33 has a CVSS v3.1 base score of 5.6 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM orchestration platformsmulti-tenant AI workflow automationRAG pipelines

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0049 Exploit Public-Facing Application

AML.T0055 Unsecured Credentials

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.9.4

NIST AI RMF: GOVERN 6.1

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

**Detection Method:** Kolega.dev Deep Code Scan | Attribute | Value | |---|---| | Location | packages/server/src/enterprise/utils/tempTokenUtils.ts:31-34 | | Practical Exploitability | Medium | | Developer Approver | faizan@kolega.ai | ### Description The encryption key for token encryption has a weak default value 'Secre$t' when TOKEN_HASH_SECRET environment variable is not set. ### Affected Code ``` const key = crypto .createHash('sha256') .update(process.env.TOKEN_HASH_SECRET || 'Secre$t') .digest() ``` ### Evidence The default value 'Secre$t' is hardcoded in the source code and is cryptographically weak. This key is used to encrypt user IDs and workspace IDs in JWT tokens. ### Impact Token forgery - attackers can decrypt and manipulate encrypted token metadata, potentially changing user IDs or workspace IDs to escalate privileges or access unauthorized data. ### Recommendation Require TOKEN_HASH_SECRET to be set as a strong random value in environment variables. Throw an error on startup if not configured. Use a minimum of 32 bytes of entropy. ### Notes The TOKEN_HASH_SECRET has a weak hardcoded default 'Secre$t' (lines 31-34 and 50-53). This secret is used to derive an AES-256-CBC encryption key for encrypting sensitive metadata (user ID and workspace ID) embedded in JWT tokens via encryptToken() called at line 394 of passport/index.ts. If TOKEN_HASH_SECRET is not configured, an attacker knowing the default can decrypt the 'meta' field in JWTs to extract user IDs and workspace IDs. While this alone doesn't grant access (the JWT signature is separate), it leaks internal identifiers that could aid other attacks. The .env.example shows '# TOKEN_HASH_SECRET='popcorn'' - another weak value, and it's commented out suggesting it's optional. The application should require this secret to be explicitly set with a strong random value.

Exploitation Scenario

An attacker targeting an organization's AI workflow automation infrastructure identifies an internet-exposed Flowise instance. They create a legitimate trial account, authenticate, and obtain a valid JWT. Using the publicly disclosed default key 'Secre$t', they derive the AES-256-CBC encryption key via SHA-256 and decrypt the 'meta' field of the JWT to extract the authenticated user's internal user ID and workspace ID. They then systematically enumerate adjacent workspace IDs by incrementing or modifying the workspace identifier and crafting new token metadata fields, re-encrypting with the same default key. If Flowise's API validates workspace access based on the token metadata rather than server-side session state, the attacker gains access to other tenants' AI agent configurations, API credentials stored in workflow nodes, connected data sources, and conversation histories — potentially compromising the entire AI supply chain downstream of the Flowise platform.

Weaknesses (CWE)

CWE-798 Use of Hard-coded Credentials Primary

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.