Vulnerability Database

353,823

Total vulnerabilities in the database

Flowise: Weak Default JWT Secrets — flowise

Use of a Broken or Risky Cryptographic Algorithm

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 | [email protected] |

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.

  • Published: Apr 16, 2026
  • Updated: Apr 17, 2026
  • GHSA: GHSA-cc4f-hjpj-g9p8
  • Severity: Medium
  • Exploit:
  • CISA KEV:

CVSS v3:

  • Severity: Medium
  • Score: 5.6
  • AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.