CVE-2026-56269: 
Flowise Analyse et atténuation des vulnérabilités

CVE-2026-56269 is a hardcoded credentials vulnerability in FlowiseAI's Flowise platform (npm package flowise) affecting all versions up to and including 3.0.13 (before 3.1.0). The flaw involves a weak hardcoded default value 'Secre$t' for the TOKEN_HASH_SECRET environment variable, used to derive the AES-256-CBC key that encrypts user and workspace IDs embedded in JWT token metadata. It was published on June 24, 2026, with a patch released in version 3.1.0. The vulnerability carries a CVSS v3.1 base score of 4.6 (Medium) and a CVSS v4.0 base score of 4.3 (Medium) (GitHub Advisory, Feedly).

The root cause is classified as CWE-798 (Use of Hard-coded Credentials). In packages/server/src/enterprise/utils/tempTokenUtils.ts (lines 31–34), the application derives an AES-256-CBC encryption key by hashing process.env.TOKEN_HASH_SECRET || 'Secre$t' via SHA-256 — meaning any deployment that does not explicitly configure TOKEN_HASH_SECRET silently falls back to the predictable default. An attacker with knowledge of this default can decrypt the meta field of any JWT token to extract internal user IDs and workspace IDs, and re-encrypt manipulated values. Notably, the .env.example file ships with TOKEN_HASH_SECRET commented out (suggesting it is optional), compounding the risk of misconfigured deployments. Because JWT signature validation is separate from this metadata encryption, tampering with the meta field alone does not bypass authentication, but it does expose internal identifiers and may facilitate privilege escalation (GitHub Advisory).

Successful exploitation allows a local, high-privileged attacker to decrypt JWT token metadata and extract internal user IDs and workspace IDs, constituting a confidentiality breach of sensitive internal identifiers. An attacker may also re-encrypt manipulated metadata with altered user or workspace IDs, potentially enabling unauthorized access to other users' data or privilege escalation within the Flowise platform. Availability is not impacted, and the integrity impact is limited since the JWT signature remains a separate validation barrier (GitHub Advisory, Feedly).

1. Identify target deployment: Determine whether the target Flowise instance (version ≤ 3.0.13) has TOKEN_HASH_SECRET configured. Deployments using default or commented-out configurations are vulnerable.
2. Obtain a JWT token: Acquire a valid JWT token from the Flowise application — this may require authenticated access or interception of a token in transit.
3. Extract the meta field: Parse the JWT token and extract the encrypted meta field from the payload.
4. Decrypt metadata using the default secret: Using the known default secret 'Secre$t', derive the AES-256-CBC key by computing SHA-256('Secre$t'). Decrypt the meta field to reveal plaintext user ID and workspace ID values.
5. Manipulate identifiers: Alter the decrypted user ID or workspace ID to target a different user or workspace (e.g., an administrator account).
6. Re-encrypt and inject: Re-encrypt the manipulated metadata using the same derived key and replace the meta field in the JWT. Submit requests with the modified token to attempt unauthorized data access or privilege escalation (GitHub Advisory).

• Logs: Flowise application logs showing access to resources by user IDs or workspace IDs that do not match the authenticated session's expected identifiers; repeated JWT validation attempts with unusual meta field values.
• Network: Unusual API requests where the JWT meta field contains workspace or user IDs inconsistent with the authenticated user's profile, particularly targeting administrative workspaces.
• Configuration: Absence of the TOKEN_HASH_SECRET environment variable in the Flowise deployment configuration (.env file or container environment), indicating use of the default hardcoded secret.

Upgrade Flowise to version 3.1.0 or later, which addresses this vulnerability (GitHub Advisory). Immediately configure a strong, unique value for the TOKEN_HASH_SECRET environment variable (minimum 32 bytes of entropy) and ensure it is never left at the default or commented-out state. After applying the patch and setting a new secret, rotate all JWT tokens issued prior to remediation to invalidate any tokens whose metadata may have been decrypted using the old default. The vendor recommends that the application throw a startup error if TOKEN_HASH_SECRET is not explicitly configured.

The vulnerability was discovered via a deep code scan by Kolega.dev and reported by kolega-ai-dev, with the advisory credited to igor-magun-wd and approved by faizan@kolega.ai (GitHub Advisory). VulnCheck also published an advisory covering this issue. No significant broader media coverage or notable community commentary has been identified beyond standard vulnerability database entries.