The vulnerability lies in an insecure default configuration where FUXA uses a hardcoded JWT secret if authentication is enabled but no secret is explicitly configured. This allows an attacker to forge JWTs and gain administrative access. The analysis of the patch commit ea7b3df066f9fdef8ecdce318398ae40546bc50d reveals the functions that were modified to fix this issue. The core of the problem was that the application failed to require and properly apply a user-defined secret.
The identified vulnerable functions are the ones that, prior to the patch, were responsible for configuring the application's security settings but failed to handle the JWT secret correctly:
-
init in server/api/index.js: This function's request handler for POST /api/settings was modified to re-initialize the authJwt and authApi modules whenever security settings (including the new secretCode) are changed. The absence of this re-initialization in vulnerable versions meant that enabling authentication would cause the system to use a default, hardcoded key.
-
mergeUserSettings in server/api/index.js: This function was patched to accept the secretCode from the settings and apply it to the runtime configuration. Before the patch, it ignored any secret, contributing to the fallback to the insecure default.
-
onOkClick in client/src/app/editor/app-settings/app-settings.component.ts: This client-side function was patched to add validation, ensuring that a user must provide a secret code when enabling authentication. The lack of this check in the UI allowed the insecure server state to be configured easily.
During an exploit, an attacker would send a request with a forged JWT to any protected API endpoint. The middleware responsible for token validation (likely initialized by authJwt.init) would then process this token. While the validation function itself is not shown in the patch, its insecure state is a direct result of the identified vulnerable functions failing to configure it with a strong, user-defined secret.