8.1

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

GHSA-c8m8-3jcr-6rj5

GHSA-c8m8-3jcr-6rj5: FUXA has a hardcoded fallback JWT signing secret

FUXA used a static fallback JWT signing secret (frangoteam751) when no secretCode was configured.

If authentication was enabled without explicitly setting a custom secret, an attacker who knew the default value could forge valid JWT tokens and bypass authentication.

This issue has been addressed in version 1.3.0 by removing the static fallback and generating a secure random secret when no secretCode is provided.

(GitHub Advisory)

Miggo Vulnerability Database

→

GHSA-c8m8-3jcr-6rj5

GHSA-c8m8-3jcr-6rj5:

8.1

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
@frangoteam/fuxa	npm	<= 1.2.11	1.3.0

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability stems from a hardcoded JWT signing secret, 'frangoteam751', defined in server/api/jwt-helper.js. This became the default secret if the application was configured with security enabled but without a specific secret code.

The analysis of the patch between the last vulnerable version (1.2.11) and the first patched version (1.3.0) revealed several key changes. The commit c7e74e0ffc688130c0f02489d4f4946bead6403f directly addresses the issue.

Root Cause: In server/api/jwt-helper.js, the static variable secretCode was initialized to 'frangoteam751'. The patch replaces this with a call to utils.generateSecretCode(), ensuring a random secret is generated if one is not already set.
Missing Safeguards: The vulnerability was exploitable because the application's startup and settings-update logic failed to enforce the presence of a secret. The patch rectifies this by adding checks in two critical locations:
- server/main.js: During server initialization, new code now checks if settings.secureEnabled is true and settings.secretCode is missing. If so, it generates a random secret.
- server/api/index.js: Within the init function that handles API settings, a similar check is added to generate a secret if security is enabled without one being provided in the request.

Therefore, the vulnerable functions are the entry points that allowed the application to run with this insecure default (init and the main server startup logic) and any function within jwt-helper.js that used the hardcoded secret to verify tokens.

Vulnerable functions

init

server/api/index.js

This function, responsible for API initialization and handling settings updates, was vulnerable because it did not ensure a 'secretCode' was provided when 'secureEnabled' was set to true. This caused the application to fall back to using a hardcoded JWT secret, allowing an attacker who knows the secret to forge valid tokens and bypass authentication.

server startup logic

server/main.js

The main server startup script was missing a crucial check to ensure that a JWT secret was configured when security was enabled. This oversight allowed the application to initialize in an insecure state, relying on a predictable, hardcoded secret for token validation, thus creating an authentication bypass vulnerability.

JWT token processing functions

server/api/jwt-helper.js

This module is the root cause of the vulnerability, as it defined the hardcoded fallback JWT secret 'frangoteam751'. Any function within this file that used the module-level 'secretCode' variable to verify JWTs would be the function appearing in a runtime profile during an exploit. An attacker would forge a token signed with the known secret, and the verification function in this module would improperly validate it.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.