Description
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.
Published: 2026-09-24
Score: 9.2 Critical
EPSS: < 1% Very Low
KEV: No
Impact: Authentication Bypass and Privilege Escalation
Action: Immediate Patch
AI Analysis

Impact

SigNoz servers from version 0.8.0 up to but not including 0.143.0 use an empty string as the default key for signing and verifying JWT session tokens. Because the configuration validation does not reject this empty value, an attacker who is able to connect to the API can forge a valid session token for any user, including administrators, by signing the user id, organization id and email claims with an empty HMAC key. This flaw is a CWE‑1188 weakness in the authentication subsystem.

Affected Systems

Any deployment of SigNoz before the 0.143.0 release that does not explicitly set the SIGNOZ_TOKENIZER_JWT_SECRET (or its deprecated counterpart SIGNOZ_JWT_SECRET) is affected. The vulnerability resides in the default JWT tokenizer provider that signs tokens with an empty secret when none is configured.

Risk and Exploitability

The flaw carries a CVSS score of 9.2, indicating high severity. The EPSS score is not available, so the exact exploitation probability is uncertain, and the vulnerability is not listed in the CISA KEV catalogue. An unauthenticated attacker can learn the organization identifier by querying /api/v2/sessions/context, then forge a session token for any known user ID and subsequently exchange it for a refresh token using /api/v2/sessions/rotate. The resulting refresh token grants continued access for its default 30‑day lifespan and cannot be revoked, enabling persistent unauthorized use of the system.

Generated by OpenCVE AI on September 24, 2026 at 03:23 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade to SigNoz v0.143.0 or later, which requires a non‑empty JWT secret and changes the default provider to an opaque token format.
  • If an upgrade is not feasible, set the SIGNOZ_TOKENIZER_JWT_SECRET environment variable to a strong, non‑empty value and apply the configuration change.
  • Ensure that the JWT provider is configured to use the opaque provider rather than the default tokenizer provider to prevent reuse of the insecure default.

Generated by OpenCVE AI on September 24, 2026 at 03:23 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 24 Sep 2026 13:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'poc', 'Technical Impact': 'total'}, 'version': '2.0.3'}


Thu, 24 Sep 2026 04:15:00 +0000

Type Values Removed Values Added
First Time appeared Signoz
Signoz signoz
Vendors & Products Signoz
Signoz signoz

Thu, 24 Sep 2026 02:00:00 +0000

Type Values Removed Values Added
Description 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.
Title SigNoz before 0.143.0 Authentication Bypass via Empty JWT Secret
Weaknesses CWE-1188
References
Metrics cvssV3_1

{'score': 8.1, 'vector': 'CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H'}

cvssV4_0

{'score': 9.2, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N'}


cve-icon MITRE

Status: PUBLISHED

Assigner: VulnCheck

Published:

Updated: 2026-09-24T12:58:15.178Z

Reserved: 2026-09-23T23:51:32.670Z

Link: CVE-2026-97055

cve-icon Vulnrichment

Updated: 2026-09-24T12:58:11.487Z

cve-icon NVD

Status : Received

Published: 2026-09-24T02:16:54.333

Modified: 2026-09-24T13:17:18.647

Link: CVE-2026-97055

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-24T04:00:12Z

Weaknesses
  • CWE-1188

    Initialization of a Resource with an Insecure Default