GHSA-cc4f-hjpj-g9p8: Flowise: hardcoded JWT defaults enable full auth bypass
GHSA-cc4f-hjpj-g9p8 MEDIUMFlowise, one of the most widely-deployed no-code AI agent workflow platforms, ships with trivially guessable hardcoded JWT secrets ('auth_token', 'refresh_token') as defaults in all versions up to and including 3.0.13 — secrets that are publicly visible in the open-source repository. Any deployment where the four JWT environment variables were not explicitly configured at install time, a common scenario with Docker quick-start deployments, is fully vulnerable to authentication bypass without any credentials. Although the CVSS vector scores this at 5.6 medium (using a conservative local-access model), the practical exploitability for network-exposed instances is critical: an attacker only needs to know the package version to forge admin-level JWTs. The additional design flaw where the refresh token falls back to the auth token secret means partial configuration offers no meaningful protection. Upgrade immediately to Flowise 3.1.0, audit all JWT environment variables for explicit strong values, and rotate every LLM API key stored in affected Flowise instances.
What is the risk?
Practical risk is critical despite the moderate CVSS score of 5.6. The CVSS vector (AV:L/AC:H/PR:H) appears to model a conservative local-access scenario, but internet-exposed Flowise instances — the vast majority of deployments — are exploitable over the network with zero prior access. Default secrets are hardcoded in publicly visible source code, requiring no research to discover. Flowise typically stores API keys for OpenAI, Anthropic, and other LLM providers, as well as database credentials and tool configurations, making a successful auth bypass a high-value compromise for attackers targeting AI infrastructure. The package has 37 prior CVEs, indicating a pattern of security debt.
How does the attack unfold?
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?
What is the attack surface?
What should I do?
1 step-
1) Upgrade to Flowise 3.1.0 immediately — this release removes hardcoded defaults and enforces explicit configuration. 2) Audit all running instances: verify JWT_AUTH_TOKEN_SECRET, JWT_REFRESH_TOKEN_SECRET, JWT_AUDIENCE, and JWT_ISSUER are all explicitly set in environment variables to cryptographically random values of 256+ bits. 3) Add startup validation that throws a fatal error if any of these variables are absent — do not allow silent fallback. 4) Rotate all LLM API keys (OpenAI, Anthropic, etc.), database credentials, and integration secrets stored in any Flowise instance that may have been running with default JWT secrets. 5) For detection: scan auth logs for JWTs signed with 'auth_token' or 'refresh_token' as secrets; look for admin-level API calls from unexpected source IPs. 6) If you cannot patch immediately, restrict network access to Flowise instances behind a VPN or IP allowlist.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-cc4f-hjpj-g9p8?
Flowise, one of the most widely-deployed no-code AI agent workflow platforms, ships with trivially guessable hardcoded JWT secrets ('auth_token', 'refresh_token') as defaults in all versions up to and including 3.0.13 — secrets that are publicly visible in the open-source repository. Any deployment where the four JWT environment variables were not explicitly configured at install time, a common scenario with Docker quick-start deployments, is fully vulnerable to authentication bypass without any credentials. Although the CVSS vector scores this at 5.6 medium (using a conservative local-access model), the practical exploitability for network-exposed instances is critical: an attacker only needs to know the package version to forge admin-level JWTs. The additional design flaw where the refresh token falls back to the auth token secret means partial configuration offers no meaningful protection. Upgrade immediately to Flowise 3.1.0, audit all JWT environment variables for explicit strong values, and rotate every LLM API key stored in affected Flowise instances.
Is GHSA-cc4f-hjpj-g9p8 actively exploited?
No confirmed active exploitation of GHSA-cc4f-hjpj-g9p8 has been reported, but organizations should still patch proactively.
How to fix GHSA-cc4f-hjpj-g9p8?
1) Upgrade to Flowise 3.1.0 immediately — this release removes hardcoded defaults and enforces explicit configuration. 2) Audit all running instances: verify JWT_AUTH_TOKEN_SECRET, JWT_REFRESH_TOKEN_SECRET, JWT_AUDIENCE, and JWT_ISSUER are all explicitly set in environment variables to cryptographically random values of 256+ bits. 3) Add startup validation that throws a fatal error if any of these variables are absent — do not allow silent fallback. 4) Rotate all LLM API keys (OpenAI, Anthropic, etc.), database credentials, and integration secrets stored in any Flowise instance that may have been running with default JWT secrets. 5) For detection: scan auth logs for JWTs signed with 'auth_token' or 'refresh_token' as secrets; look for admin-level API calls from unexpected source IPs. 6) If you cannot patch immediately, restrict network access to Flowise instances behind a VPN or IP allowlist.
What systems are affected by GHSA-cc4f-hjpj-g9p8?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI workflow orchestration, LLM API integrations, no-code AI platforms, RAG pipelines.
What is the CVSS score for GHSA-cc4f-hjpj-g9p8?
GHSA-cc4f-hjpj-g9p8 has a CVSS v3.1 base score of 5.6 (MEDIUM).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012 Valid Accounts AML.T0049 Exploit Public-Facing Application AML.T0055 Unsecured Credentials AML.T0083 Credentials from AI Agent Configuration AML.T0091.000 Application Access Token Compliance Controls Affected
What are the technical details?
Original Advisory
**Detection Method:** Kolega.dev Deep Code Scan | Attribute | Value | |---|---| | Severity | Critical | | Location | packages/server/src/enterprise/middleware/passport/index.ts:29-34 | | Practical Exploitability | High | | Developer Approver | faizan@kolega.ai | ### Description JWT secrets have weak hardcoded defaults ('auth_token', 'refresh_token', 'AUDIENCE', 'ISSUER'). Attackers can forge valid JWTs and impersonate any user. ### Affected Code ``` const jwtAudience = process.env.JWT_AUDIENCE || 'AUDIENCE' const jwtIssuer = process.env.JWT_ISSUER || 'ISSUER' const jwtAuthTokenSecret = process.env.JWT_AUTH_TOKEN_SECRET || 'auth_token' const jwtRefreshSecret = process.env.JWT_REFRESH_TOKEN_SECRET || process.env.JWT_AUTH_TOKEN_SECRET || 'refresh_token' ``` ### Evidence All JWT defaults are weak strings. Refresh token falls back to auth token which is a design flaw. If any environment variable is unset, weak default is used. ### Impact Complete authentication bypass. Attackers can forge valid JWTs for any user account. No authentication required to access protected endpoints. Can escalate to admin access. ### Recommendation Remove all default secrets - require all JWT environment variables to be explicitly set. Add startup validation throwing error if any JWT secret is missing. Use cryptographically random secrets (256+ bits) for each secret independently. Implement JWT secret rotation mechanism. ### Notes The JWT secrets have genuinely weak hardcoded defaults ('auth_token', 'refresh_token', 'AUDIENCE', 'ISSUER') at lines 29-34. If an administrator deploys without setting the environment variables JWT_AUTH_TOKEN_SECRET, JWT_REFRESH_TOKEN_SECRET, JWT_AUDIENCE, and JWT_ISSUER, the application will use these trivially guessable values. An attacker knowing these defaults (which are publicly visible in the source code) can forge valid JWTs to impersonate any user, including administrators. The fallback chain at line 34 where jwtRefreshSecret falls back to jwtAuthTokenSecret is an additional design weakness - if only JWT_AUTH_TOKEN_SECRET is set, both tokens share the same secret. While .env.example files provide placeholder values, these are also weak and publicly visible. The application should fail to start if these secrets are not explicitly configured with strong values, rather than silently falling back to insecure defaults.
Exploitation Scenario
An attacker scans for internet-exposed Flowise instances and identifies one running version 3.0.13 via the UI footer or API response headers. Consulting the public GitHub repository, they retrieve the default JWT secrets: 'auth_token' for the auth token and 'refresh_token' for the refresh token, along with the literal strings 'AUDIENCE' and 'ISSUER'. They craft a valid JWT signed with 'auth_token', embedding an admin user claim, and submit it to the Flowise API. The server validates the forged token against the default secret and grants full admin access. The attacker then exports all workflow configurations — extracting hardcoded OpenAI and Anthropic API keys — enumerates connected vector databases, and uses the embedded credentials to exfiltrate proprietary RAG datasets. If the Flowise instance runs with network tool access, the attacker can invoke agent tools to pivot into internal systems.
Weaknesses (CWE)
CWE-327 — Use of a Broken or Risky Cryptographic Algorithm: The product uses a broken or risky cryptographic algorithm or protocol.
- [Architecture and Design] When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis. For example, US government systems require FIPS 140-2 certification [REF-1192]. Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak. Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267
- [Architecture and Design] Ensure that the design allows one cryptographic algorithm to be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N References
Timeline
Related Vulnerabilities
CVE-2025-59528 10.0 Flowise: Unauthenticated RCE via MCP config injection
Same package: flowise CVE-2026-46442 9.9 Flowise: sandbox escape enables authenticated RCE
Same package: flowise CVE-2025-61913 9.9 Flowise: path traversal in file tools leads to RCE
Same package: flowise CVE-2026-40933 9.9 Flowise: RCE via MCP stdio command injection
Same package: flowise CVE-2026-56274 9.9 Flowise: RCE via MCP server command validation bypass
Same package: flowise