CVE-2026-97056 in SigNoz
Summary
by MITRE • 09/24/2026
SigNoz versions from v0.98.0 up to (but not including) v0.143.0, when configured to use the opaque session tokenizer (which was not the default before v0.143.0), do not revoke a user's existing login sessions when the user's password is reset with a reset token (UpdatePasswordByResetPasswordToken, reachable via POST /api/v2/factor_password/reset) or when the user is deleted (DeleteUser, reachable via DELETE /api/v2/users/{id}). Neither code path calls the tokenizer's DeleteTokensByUserID, so cached tokens and identities are left in place. An attacker who already holds a session token for the account — for example from a stolen browser session or from a user being offboarded — retains the account's full access, up to administrator, after a password reset until the token reaches its configured maximum lifetime (30 days by default), and after user deletion until the token next rotates (30 minutes by default). This defeats password reset and user deletion as a means of terminating access. The issue is fixed in v0.143.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in SigNoz versions ranging from v0.98.0 to just before v0.143.0 represents a critical authentication and session management flaw rooted in the improper handling of opaque session tokens during administrative account lifecycle events. This issue specifically affects deployments that have configured the system to use an opaque session tokenizer, which was not the default configuration prior to version 0.143.0. The core technical deficiency lies in the failure of two specific API endpoints to invalidate existing active sessions for a targeted user. These endpoints are UpdatePasswordByResetPasswordToken, accessible via POST /api/v2/factor_password/reset, and DeleteUser, reachable through DELETE /api/v2/users/{id}. In both scenarios, the application logic neglects to invoke the tokenizer's internal method responsible for revoking tokens associated with the affected user ID. Consequently, any cached session tokens and identity data remain valid in memory or storage despite the administrative intent to terminate access.
From an operational perspective, this flaw severely undermines fundamental security controls designed to revoke unauthorized or compromised access. If a password is reset using a token-based mechanism, typically employed when a user reports their credentials are compromised, the attacker who possesses the original stolen session token retains full access to the account without interruption. Similarly, if an administrator deletes a user's account as part of offboarding procedures or security remediation, the deleted user’s active sessions continue to function until they naturally expire based on configured lifetime parameters. By default, opaque tokens have a maximum lifetime of thirty days for password resets and rotate every thirty minutes in other contexts, meaning access could persist for up to half an hour after deletion. This effectively nullifies the immediate security benefit of these administrative actions, allowing persistent unauthorized access even after the system believes it has revoked privileges.
This vulnerability aligns with CWE-613, which describes insufficient session expiration, and more critically CWE-284, improper access control, as well as CWE-798, use of hardcoded credentials if static tokens were involved, though here the issue is dynamic token persistence. In terms of the MITRE ATT&CK framework, this flaw facilitates Persistence (T1078) by allowing an attacker to maintain foothold in a system after defensive measures like password resets or account deletions are enacted. It also relates to Credential Access and Session Hijacking scenarios where stolen tokens remain valid despite credential changes. The lack of immediate token revocation means that incident response procedures relying on these API calls for rapid containment are rendered ineffective, requiring manual intervention such as restarting services or manually clearing session stores to achieve the desired security outcome.
The resolution for this vulnerability was implemented in SigNoz version 0.143.0 and later releases. To mitigate the risk in affected environments prior to upgrading, administrators should ensure that opaque token lifetimes are configured to be as short as operationally feasible to limit the window of opportunity for attackers. Additionally, organizations relying on these versions should implement compensating controls such as monitoring for unusual activity from long-lived sessions or manually invalidating user tokens through database-level operations if immediate upgrade is not possible. Upgrading to v0.143.0 or newer is the definitive remediation strategy, as it ensures that both password reset and user deletion workflows correctly trigger the necessary token revocation logic, thereby restoring the integrity of session management and access control mechanisms within the application.