CVE-2026-97055: SigNoz before 0.143.0 Authentication Bypass via Empty JWT Secret
SigNoz from v0.8.0 before v0.143.0 defaults the JWT tokenizer signing secret (tokenizer::jwt::secret, set via SIGNOZTOKENIZERJWTSECRET or the deprecated SIGNOZJWTSECRET) 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
SigNozto a version that resolves this vulnerability.Fixed in 0.143.0 - Configuration
When the jwt provider is selected, configure tokenizer::jwt::secret to a non-empty secret via SIGNOZ_TOKENIZER_JWT_SECRET (or the deprecated SIGNOZ_JWT_SECRET).
SigNoz JWT tokenizer tokenizer::jwt::secret = non-empty secret
Event History
Frequently Asked Questions
Which deployments are exposed?
SigNoz deployments from v0.8.0 before v0.143.0 are exposed if they use the JWT tokenizer provider without configuring SIGNOZ_TOKENIZER_JWT_SECRET or the deprecated SIGNOZ_JWT_SECRET. The JWT tokenizer was the default provider, so deployments that left this setting unset are affected.
What does an attacker need to exploit this?
An attacker does not need authentication. They need the ID of an existing user; organization ID and registered-email status can be obtained without authentication from /api/v2/sessions/context, and a token can then be forged with the empty HMAC key.
What access can a forged token provide?
A forged token can impersonate any existing user whose ID is known, including an administrator. A forged refresh token can also be exchanged through /api/v2/sessions/rotate for a new token pair.
What should be done if upgrading cannot happen immediately?
Configure a non-empty JWT signing secret through SIGNOZ_TOKENIZER_JWT_SECRET or, where still applicable, SIGNOZ_JWT_SECRET. Upgrade to v0.143.0 when possible; it requires a secret when the JWT provider is selected and changes the default provider to opaque.
Can forged refresh tokens be invalidated?
No. A forged refresh token cannot be revoked and remains usable for its full lifetime, which is 30 days by default.