The vulnerability is a classic CWE-798 (Use of Hard-coded Credentials) where the JWT signing secret is hardcoded to the predictable value "random". This insecure default is set in two places: the dev.env template file for developers and, more critically, as a programmatic fallback in the cmd.init function in cmd/serve.go using viper.SetDefault. This guarantees that if the AUTH_JWT_SECRET is not explicitly set, the application will silently start with the insecure key.
The jwt.NewTokenAuth function is responsible for creating the JWT signing service. In its vulnerable state, it would fetch this weak secret and use it to initialize the signer. An earlier, flawed mitigation attempt in this function was insufficient as it only checked for the literal string "random" and replaced it with a non-persistent, in-memory key, which was lost on restart.
An attacker who has read the public source code knows this default secret. They can then forge JWT tokens with arbitrary claims (e.g., granting themselves admin privileges) and send them to the API. The application's token verification middleware, configured by NewTokenAuth with the same weak key, will trust and validate these forged tokens, leading to a complete authentication bypass. The jwt.(*TokenAuth).GenTokenPair function is also implicated as it uses the compromised configuration to issue new tokens, perpetuating the vulnerability.