signoz: Initialization of a Resource with an Insecure Default
CVE-2026-97055 is a high-severity initialization of a resource with an insecure default vulnerability in signoz, with a CVSS 3.1 base score of 8.1 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists version 0.143.0 as the first without the flaw, so updating signoz to that release or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.53% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update signoz to 0.143.0 or a later version.
- Read the advisory on github.com for workarounds and exact fixed builds.
- Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.
Affected products and versions
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- NetworkCan be exploited remotely over a network, including the internet.
- Attack complexity
- HighSuccess depends on conditions outside the attacker's control.
- Privileges required
- NoneNo account or login is needed.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- HighData or code can be modified at will.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Scored by CNA (vulncheck.com).
| Scoring system | Score | Severity | Scored by |
|---|---|---|---|
| CVSS 4.0 | 9.2 | Critical | CNA (vulncheck.com) |
| CVSS 3.1 | 8.1 | High | CNA (vulncheck.com) |
Official 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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Initialization of a Resource with an Insecure Default
The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.
More Initialization of a Resource with an Insecure Default vulnerabilities (CWE-1188)
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: poc, automatable: no, technical impact: total).
References
Patches and release notes
Other references
Other vulnerabilities in signoz
- 8.5 High severity
- 8.5 High severity
- 8.2 High severity
- 8.1 High severity
- 8.5 High severity
Recent Initialization of a Resource with an Insecure Default vulnerabilities
- 8.1 High severity
- 9.1 Critical severity
- 9.1 Critical severity
- 10.0 Critical severity
- 7.5 High severity
- 8.6 High severity
Spotted an error? Tell us.