CVE-2026-97055: SigNoz before 0.143.0 Authentication Bypass via Empty JWT Secret

Published Sep 24, 2026
·
Updated

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

1 affected component
SigNoz SigNoz>=0.8.0<0.143.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade SigNoz to a version that resolves this vulnerability.

    Fixed in 0.143.0
  2. 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

Sep 24, 2026
CVE Published
via MITRE·01:53 AM
Data Sourced
via MITRE·01:53 AM
DescriptionSeverityWeakness

Frequently Asked Questions

1

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.

2

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.

3

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.

4

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.

5

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203