SigNoz EUVD-2026-85773

Two concrete prerequisites gate this vulnerability. First, SigNoz must be configured to use the opaque session tokenizer, which was NOT the default before v0.143.0 - default installations in the affected range are not exposed. Second, the attacker must already hold a valid session token for the target account (e.g., a stolen browser session or a token belonging to a user being offboarded); this is not an initial-access flaw. Given those, an attacker retains access after the account's password is reset via POST /api/v2/factor_password/reset (UpdatePasswordByResetPasswordToken) for up to the token's max lifetime (30 days by default), or after the account is deleted via DELETE /api/v2/users/{id} (DeleteUser) until the token next rotates (30 minutes by default). Limiting factors: requires prior possession of a live token, requires the non-default opaque tokenizer, and authenticated access (PR:L); it defeats password-reset and user-deletion as access-termination controls rather than granting new access.

This is a session-management flaw (CWE-613, insufficient session expiration) that is real but conditional, not a drop-everything emergency. Signals largely agree on moderate severity: the vendor CVSS 4.0 base is 7.6 (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N), and my independent 3.1 assessment lands around 6.5 because the AT:P attack-requirement in 4.0 maps to AC:H in 3.1. Exploitation status is 'no public exploit identified at time of analysis' - the references are a GitHub Security Advisory (GHSA-xrgp-3fq4-xg83), four fix commits, and a VulnCheck advisory, but no proof-of-concept, no CISA KEV listing, and no EPSS score were supplied. Two facts materially lower real-world risk below the raw CVSS number: (1) the vulnerable behavior only manifests when SigNoz is configured to use the opaque session tokenizer, which was NOT the default before v0.143.0, so default deployments are unaffected; and (2) the attacker must ALREADY possess a valid session token for the target account (from a stolen browser session or an offboarded user) - this is not a way to gain initial access but a failure to REVOKE existing access. So this is a defense-in-depth/offboarding-integrity issue rather than a widely-automatable remote compromise. There is no conflicting data between description and CVSS; both consistently describe an authenticated, network-reachable, non-default-config weakness. Priority is elevated only for organizations that (a) run the opaque tokenizer and (b) rely on password reset or user deletion to terminate compromised or departing-employee access.

An employee is offboarded and their SigNoz account is deleted, or a user's password is reset after a suspected browser-session theft. Because the opaque-tokenizer code paths for UpdatePasswordByResetPasswordToken and DeleteUser never call DeleteTokensByUserID, the previously captured session token keeps working - retaining full access up to administrator for up to 30 days after a password reset or until the next 30-minute rotation after deletion. No public exploit code is identified; exploitation simply requires replaying the still-valid token against the API.