Flowise EUVD-2026-38746

The vulnerability is triggered only when the TOKEN_HASH_SECRET environment variable is NOT explicitly configured - the application then silently falls back to the hardcoded 'Secre$t' value. Because the .env.example ships with this variable commented out, this unset state is the effective default for unconfigured deployments. The information-disclosure path (decrypting one's own JWT meta field) requires that the attacker can authenticate to the Flowise instance and obtain a JWT token; no elevated privileges are required for this path. The metadata manipulation path (re-encrypting altered user/workspace IDs) additionally requires that a downstream API endpoint processes the meta field content without re-validating identity via the JWT HMAC/RSA signature - this condition is not confirmed from available data and may vary by endpoint. Active exploitation is limited to Flowise enterprise-tier deployments that partition by user and workspace IDs in the 'meta' field; development or single-user deployments have no meaningful tenant-isolation to compromise. Exploitation does not bypass JWT signature validation and cannot on its own produce a cryptographically valid forged token.

The provided CVSS 4.0 vector (AV:L/AC:H/PR:H/UI:A, score 4.3) models a highly constrained scenario - local access, high privileges, high complexity, and required user interaction - which appears to reflect the privilege-escalation follow-on path rather than the information-disclosure path accessible to ordinary authenticated users over the network. The real-world risk for network-accessible Flowise deployments where TOKEN_HASH_SECRET is unset is likely higher than the 4.3 score implies: the default key 'Secre$t' is now publicly documented in both the GHSA advisory and upstream source code, any authenticated user holds a JWT containing their own encrypted meta field, and decrypting it requires only standard AES-CBC tooling. Kolega.dev assessed practical exploitability as 'Medium.' The concrete integrity impact is bounded because the JWT signature (HMAC or RSA) is validated separately - re-encoding a tampered meta field does not produce a valid signed JWT, limiting the attack to injection of crafted meta values into API calls that accept them without re-signature. No CISA KEV listing and no public proof-of-concept have been identified. The primary risk is identifier disclosure enabling reconnaissance and potential privilege escalation in multi-tenant enterprise deployments; single-tenant or development instances have reduced exposure. The CVSS AV:L and PR:H discrepancy with the description should be verified with the vendor, as the description implies network-accessible authenticated exploitation for the disclosure path.

An attacker who has created a legitimate account on a Flowise instance where TOKEN_HASH_SECRET was never configured authenticates, captures their issued JWT, and uses the publicly disclosed default key 'Secre$t' (AES-256-CBC via SHA-256 of the secret) to decrypt the 'meta' field, obtaining internal user and workspace UUIDs for their own session and inferring enumerable patterns for other tenants. The attacker then re-encrypts a modified 'meta' field substituting a target workspace ID and embeds it into API requests to probe whether any multi-tenant access control endpoint processes the meta value without independently re-validating tenant membership through the JWT signature. No public proof-of-concept code has been identified, but the attack requires only standard cryptographic tooling (e.g., Node.js crypto module or openssl) and the construction details now documented in the advisory and source code.