CVE-2026-97055 in SigNoz
Summary
by MITRE • 09/24/2026
SigNoz from v0.8.0 before v0.143.0 defaults the JWT tokenizer signing secret (tokenizer::jwt::secret, set via SIGNOZ_TOKENIZER_JWT_SECRET or the deprecated SIGNOZ_JWT_SECRET) to an empty string, and Config.Validate() does not reject the empty value, so a deployment that does not configure a secret starts up and both signs and verifies session tokens with an empty HMAC key. Because the JWT tokenizer was the default provider, any such deployment is affected. An unauthenticated attacker who knows the ID of an existing user can forge a valid session token for that user — including an administrator — by signing the id, orgId and email claims with an empty key; the organization ID (and whether an email is registered) can be obtained without authentication from /api/v2/sessions/context. A forged refresh token can be exchanged at /api/v2/sessions/rotate for a new token pair and cannot be revoked, so it remains usable for its full lifetime (30 days by default). Fixed in v0.143.0, which requires a JWT secret when the jwt provider is selected and changes the default provider to opaque.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in SigNoz versions prior to 0.143.0 represents a critical authentication bypass resulting from improper configuration of cryptographic keys for JSON Web Token (JWT) validation. The core technical flaw lies in the application's handling of the JWT signing secret, specifically the tokenizer::jwt::secret parameter which can be configured via environment variables SIGNOZ_TOKENIZER_JWT_SECRET or its deprecated counterpart SIGNOZ_JWT_SECRET. In default configurations where no explicit secret is provided by the system administrator, the software initializes this value to an empty string rather than rejecting it as invalid. Furthermore, the internal validation logic within Config.Validate() fails to enforce a non-empty requirement for this critical security parameter. Consequently, any deployment operating with these defaults proceeds to sign and verify session tokens using an HMAC algorithm with an empty key. This effectively nullifies the integrity protection offered by JWTs, allowing any party capable of constructing valid token structures to generate signatures that the application will accept as authentic without possessing a shared secret.
The operational impact of this flaw is severe due to the predictability of user identifiers and the lack of revocation mechanisms for refresh tokens. An unauthenticated attacker can exploit this weakness by first obtaining the identity details of an existing user, including their ID, organization ID, and email address. These data points are accessible without authentication through the /api/v2/sessions/context API endpoint, which exposes context information about active sessions or available organizations. With these claims in hand, the attacker constructs a JWT containing the victim's id, orgId, and email fields. By signing this token with an empty HMAC key, the resulting signature is mathematically valid according to SigNoz’s verification logic. The application accepts this forged token as legitimate, granting the attacker full access privileges associated with the targeted user account, including administrative rights if such a role exists for that identity.
The persistence of unauthorized access is exacerbated by the behavior of refresh tokens within the system's authentication flow. Once an initial session token is established using the forged JWT, it can be exchanged at /api/v2/sessions/rotate for new pairs of access and refresh tokens. Crucially, these newly minted refresh tokens cannot be revoked or invalidated through standard logout procedures or administrative intervention. This means that even if the original vulnerability were patched in a subsequent deployment, any attacker who successfully exploited this flaw during the vulnerable window retains persistent access to the system via their stored refresh token for its entire lifetime, which defaults to thirty days. This lack of revocation capability transforms what might otherwise be a transient authentication bypass into a long-term backdoor that persists across configuration updates unless manually remediated by clearing user sessions or rotating secrets aggressively.
From a standards perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-345 Insufficient Verification of Data Authenticity, as the system fails to properly verify the origin and integrity of authentication tokens due to weak key management practices. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, where an adversary leverages legitimate credentials or forged representations thereof to gain initial access. The mitigation strategy implemented in version 0.143.0 addresses these issues by enforcing a mandatory requirement for a JWT secret when the jwt provider is selected, thereby preventing the initialization of empty keys. Additionally, the default authentication provider was changed from JWT to opaque tokens, which do not rely on shared secrets for signature verification and thus eliminate this specific class of forgery attacks. Organizations running affected versions must immediately upgrade to v0.143.0 or later, ensure that a strong, randomly generated secret is configured via environment variables if JWT authentication remains in use, and actively rotate all existing refresh tokens to invalidate any potentially compromised sessions established during the period of vulnerability exposure.