SigNoz versions from 0.8.0 before 0.143.0 default the JWT tokenizer signing secret to an empty string if not explicitly set, and the configuration validation does not reject this empty value. As a result, deployments without a configured secret sign and verify session tokens using an empty HMAC key. Since the JWT tokenizer was the default provider, any such deployment is vulnerable. An unauthenticated attacker who knows an existing user's ID can forge valid session tokens by signing the id, orgId, and email claims with the empty key. The organization ID and email registration status can be retrieved without authentication from the /api/v2/sessions/context endpoint. Forged refresh tokens can be exchanged for new token pairs at /api/v2/sessions/rotate and cannot be revoked, remaining valid for their full lifetime (default 30 days). The vulnerability is addressed in version 0.143.0, which mandates a JWT secret when the JWT provider is selected and changes the default provider to opaque tokens.

An unauthenticated attacker can forge valid session tokens for any user, including administrators, by exploiting the empty JWT signing secret. This allows unauthorized access and potential full control over the affected SigNoz deployment. The attacker can also obtain organization IDs and verify email registrations without authentication. The forged refresh tokens cannot be revoked and remain valid for up to 30 days, prolonging unauthorized access.

A fix is available in SigNoz version 0.143.0, which requires a JWT secret when the JWT provider is selected and changes the default token provider to opaque tokens. Users should upgrade to version 0.143.0 or later to remediate this vulnerability. Until upgraded, ensure that the JWT signing secret is explicitly configured to a non-empty value to prevent exploitation.