CVE-2026-56269: Flowise Hardcoded Encryption Secret in JWT Metadata

Technical summary

The vulnerability exists in packages/server/src/enterprise/utils/tempTokenUtils.ts, where AES-256-CBC encryption of JWT metadata relies on a key derived from TOKEN_HASH_SECRET. When this environment variable is unset, Flowise falls back to the hardcoded string 'Secre$t'. Because this default is consistent across deployments and discoverable through source code inspection, any attacker with network access to a vulnerable Flowise instance can decrypt the 'meta' field of tokens to extract embedded user and workspace identifiers. Additionally, re-encryption of tampered metadata becomes possible. The JWT signature itself remains cryptographically valid during this process, meaning that metadata manipulation alone does not constitute a complete authentication bypass—signature validation would still reject the token if the encrypted payload were altered in isolation. However, the combination of identifier disclosure and metadata tampering could enable privilege escalation if coupled with other application logic flaws.

Business impact

Organizations running Flowise as a workflow or automation backbone risk exposure of internal user and workspace identifiers, which can reveal organizational structure and privilege relationships. In multi-tenant deployments, cross-tenant metadata leakage is possible. The ability to manipulate token metadata, even without bypassing signature validation, increases the surface area for privilege escalation exploits and could be chained with application logic vulnerabilities to gain unauthorized access to sensitive workflows, data, or administrative functions. The impact severity is moderated by the requirement for network access and the fact that JWT signature validation remains intact, but the ease of exploitation—requiring only knowledge of the default secret—makes this a priority for any production Flowise installation.

Affected systems

Flowise npm package versions 3.0.13 and earlier are vulnerable. Version 3.1.0 and above have addressed this issue. Organizations should audit all deployments to determine which version is in use and whether TOKEN_HASH_SECRET has been explicitly configured. Self-hosted and containerized Flowise instances are equally at risk if the environment variable is not set during initialization.

Exploitability

Exploitation requires network access to a Flowise instance and knowledge of the default hardcoded secret, which is trivially obtainable from public source code repositories. The attacker does not require valid credentials to perform decryption, though they must have the ability to capture or observe JWT tokens in transit or at rest. The CVSS score of 4.6 reflects the local/high-effort attack vector, but the low barrier to exploitation in practice—needing only the widely-known default secret—makes this a routine target for opportunistic attackers scanning for unpatched Flowise instances.

Remediation

Upgrade Flowise to version 3.1.0 or later, which corrects the hardcoded secret issue. Alternatively, immediately set the TOKEN_HASH_SECRET environment variable to a cryptographically secure random value (minimum 32 characters of high entropy) in all running Flowise instances. For existing deployments, setting this variable takes effect on the next application restart and does not require code changes. All instances should be audited to confirm explicit TOKEN_HASH_SECRET configuration; do not rely on documented defaults.

Patch guidance

Update the flowise npm package to version 3.1.0 or above. Verify the update in your package-lock.json or yarn.lock file. If you cannot upgrade immediately, set TOKEN_HASH_SECRET to a strong random value before restarting Flowise. Test token encryption behavior in a staging environment to confirm that existing tokens are not invalidated by the change (they should continue to validate if the encryption key change does not affect the JWT signature algorithm). Monitor Flowise logs for any authentication anomalies post-patching.

Detection guidance

Search logs and environment configurations for instances of Flowise running without an explicit TOKEN_HASH_SECRET variable set. Examine running processes for the default environment state. If feasible, extract and decrypt a sample JWT token from your Flowise instance using the hardcoded secret; if successful, your instance is vulnerable. Network intrusion detection rules can flag patterns of repeated token decryption attempts by external actors, though such activity may be difficult to distinguish from legitimate token validation. Regular token rotation and monitoring of unexpected privilege escalations in Flowise audit logs may reveal exploitation attempts.

Why prioritize this

Although the CVSS score is moderate (4.6), the practical exploitability is high due to the trivial default secret and the lack of authentication required to extract identifiers. Any organization using Flowise in production or in environments where internal IDs must remain confidential should prioritize patching or configuration changes immediately. The vulnerability is not publicly weaponized (not on CISA KEV), but the low friction for exploit development and the direct exposure of internal metadata make delay unwise.

Risk score, explained

The CVSS 4.6 score reflects a local/high-friction attack vector (AV:L, AC:H) and requires high privileges and user interaction (PR:H, UI:R), resulting in high confidentiality impact but low integrity and no availability impact. In practice, the risk is elevated because the 'local' aspect is overstated for a network-accessible web service, and the 'high complexity' is minimal when the default secret is public. Organizations should weight this as a higher practical risk than the score suggests, especially if Flowise is internet-facing or handles sensitive multi-tenant data.

Frequently asked questions