Signoz
Monthly
SigNoz deployments configured to use the non-default opaque session tokenizer leave existing sessions valid after a password reset or user deletion, so a remote authenticated attacker who already holds a live session token for an account retains that account's full access - up to administrator - for up to the token's configured maximum lifetime (30 days by default) after a reset, and until the token next rotates (30 minutes by default) after deletion. Affected versions run from v0.98.0 up to but not including v0.143.0; default installations in that range never used the opaque tokenizer and are therefore not exposed. The vendor has released v0.143.0 as the fix, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Session token forgery in SigNoz v0.8.0 through v0.142.x allows unauthenticated attackers to impersonate any user, including administrators, when the default JWT tokenizer provider runs without a configured signing secret. The application defaults the JWT HMAC key to an empty string and fails to reject this in Config.Validate(), so tokens are both signed and verified with an empty key; an attacker who knows a target user ID can forge valid access and refresh tokens, and the refresh token can be rotated at /api/v2/sessions/rotate and cannot be revoked. No public exploit identified at time of analysis; deployments that explicitly set a secret or use the opaque provider are not affected, and v0.143.0 eliminates the exposure.
SQL injection in the SigNoz v5 query_range API (versions 0.87.0 through 0.141.x) lets authenticated users with the Viewer role or higher inject backticks and quotes into user-supplied telemetry field-key names, breaking out of ClickHouse identifier and string-literal contexts to execute arbitrary SQL. Successful exploitation allows cross-scope read access to ClickHouse system tables and exfiltration of telemetry data, with limited integrity impact; an attacker needs only valid low-privilege credentials and network access to the SigNoz API, with no user interaction or non-default configuration required. The issue is patched in SigNoz 0.142.0 per the vendor advisory (GHSA-q3h7-gpc9-2rxc), and no public exploit code was identified at time of analysis.
SQL injection in SigNoz's trace-funnel analytics endpoints lets an authenticated user break out of the ClickHouse string literals built from the service_name and span_name fields of funnel step definitions and read the results of arbitrary queries back in the HTTP response. All self-hosted deployments from 0.88.0 up to (but not including) 0.142.1 are affected; exploitation requires a valid SigNoz account with access to the trace-funnel feature, is network-reachable, and needs no user interaction, and no public exploit code was identified at time of analysis. The assessed impact is high confidentiality loss that extends to the underlying ClickHouse store (scope change) with limited integrity impact, which is why the issue carries a high-severity score despite the authentication prerequisite.
Unauthenticated remote attackers can read trace and funnel analytics from SigNoz deployments running versions 0.88.0 through 0.141.0 because the trace-funnel analytics HTTP handlers were registered without any authorization wrapper. A single unauthenticated POST to endpoints under the trace-funnels router (both the /{funnel_id}/analytics/* and /analytics/* payload variants) returns identifiers, durations, span counts, service topology, and error activity, and because the payload-style handlers accept attacker-supplied funnel definitions, no pre-existing funnel or account is required. Exploitation is bounded by network reachability to the query-service listener and is read-only (no modification or code execution), and no public exploit code has been identified at time of analysis.
Session token theft in SigNoz through 0.133.0 lets unauthenticated attackers hijack any user account on instances configured with Google OAuth, SAML, or OIDC single sign-on. Because the unauthenticated sessions-context endpoint accepts an attacker-controlled 'ref' parameter that is embedded unvalidated into the SSO state/redirect, an attacker crafts a login URL that returns the victim's access and refresh tokens to an attacker-controlled host once the victim completes SSO. Reported by VulnCheck (CWE-601, open redirect), publicly available exploit code exists, though it is not listed in CISA KEV and EPSS was not provided.
SigNoz deployments configured to use the non-default opaque session tokenizer leave existing sessions valid after a password reset or user deletion, so a remote authenticated attacker who already holds a live session token for an account retains that account's full access - up to administrator - for up to the token's configured maximum lifetime (30 days by default) after a reset, and until the token next rotates (30 minutes by default) after deletion. Affected versions run from v0.98.0 up to but not including v0.143.0; default installations in that range never used the opaque tokenizer and are therefore not exposed. The vendor has released v0.143.0 as the fix, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Session token forgery in SigNoz v0.8.0 through v0.142.x allows unauthenticated attackers to impersonate any user, including administrators, when the default JWT tokenizer provider runs without a configured signing secret. The application defaults the JWT HMAC key to an empty string and fails to reject this in Config.Validate(), so tokens are both signed and verified with an empty key; an attacker who knows a target user ID can forge valid access and refresh tokens, and the refresh token can be rotated at /api/v2/sessions/rotate and cannot be revoked. No public exploit identified at time of analysis; deployments that explicitly set a secret or use the opaque provider are not affected, and v0.143.0 eliminates the exposure.
SQL injection in the SigNoz v5 query_range API (versions 0.87.0 through 0.141.x) lets authenticated users with the Viewer role or higher inject backticks and quotes into user-supplied telemetry field-key names, breaking out of ClickHouse identifier and string-literal contexts to execute arbitrary SQL. Successful exploitation allows cross-scope read access to ClickHouse system tables and exfiltration of telemetry data, with limited integrity impact; an attacker needs only valid low-privilege credentials and network access to the SigNoz API, with no user interaction or non-default configuration required. The issue is patched in SigNoz 0.142.0 per the vendor advisory (GHSA-q3h7-gpc9-2rxc), and no public exploit code was identified at time of analysis.
SQL injection in SigNoz's trace-funnel analytics endpoints lets an authenticated user break out of the ClickHouse string literals built from the service_name and span_name fields of funnel step definitions and read the results of arbitrary queries back in the HTTP response. All self-hosted deployments from 0.88.0 up to (but not including) 0.142.1 are affected; exploitation requires a valid SigNoz account with access to the trace-funnel feature, is network-reachable, and needs no user interaction, and no public exploit code was identified at time of analysis. The assessed impact is high confidentiality loss that extends to the underlying ClickHouse store (scope change) with limited integrity impact, which is why the issue carries a high-severity score despite the authentication prerequisite.
Unauthenticated remote attackers can read trace and funnel analytics from SigNoz deployments running versions 0.88.0 through 0.141.0 because the trace-funnel analytics HTTP handlers were registered without any authorization wrapper. A single unauthenticated POST to endpoints under the trace-funnels router (both the /{funnel_id}/analytics/* and /analytics/* payload variants) returns identifiers, durations, span counts, service topology, and error activity, and because the payload-style handlers accept attacker-supplied funnel definitions, no pre-existing funnel or account is required. Exploitation is bounded by network reachability to the query-service listener and is read-only (no modification or code execution), and no public exploit code has been identified at time of analysis.
Session token theft in SigNoz through 0.133.0 lets unauthenticated attackers hijack any user account on instances configured with Google OAuth, SAML, or OIDC single sign-on. Because the unauthenticated sessions-context endpoint accepts an attacker-controlled 'ref' parameter that is embedded unvalidated into the SSO state/redirect, an attacker crafts a login URL that returns the victim's access and refresh tokens to an attacker-controlled host once the victim completes SSO. Reported by VulnCheck (CWE-601, open redirect), publicly available exploit code exists, though it is not listed in CISA KEV and EPSS was not provided.