Skip to main content
Vulnerability Database/CVE-2026-97055

CVE-2026-97055: SigNoz Auth Bypass Vulnerability

CVE-2026-97055 is an authentication bypass flaw in SigNoz affecting versions v0.8.0 to v0.142.0 that allows attackers to forge session tokens due to an empty JWT signing secret. This article covers technical details, affected versions, impact, and mitigation steps.

Updated:

CVE-2026-97055 Overview

CVE-2026-97055 is an authentication bypass vulnerability in SigNoz, an open-source observability platform. Affected versions from v0.8.0 before v0.143.0 default the JWT tokenizer signing secret to an empty string. The Config.Validate() function fails to reject the empty value, so deployments start up signing and verifying session tokens with an empty HMAC key. An unauthenticated attacker who knows a user ID can forge valid session tokens for any account, including administrators. The issue is tracked under [CWE-1188] Insecure Default Initialization of Resource.

Critical Impact

Unauthenticated attackers can forge administrator session tokens on any SigNoz deployment that does not explicitly configure a JWT secret, resulting in full account takeover.

Affected Products

  • SigNoz v0.8.0 through v0.142.x
  • Deployments using the default jwt tokenizer provider
  • Instances where SIGNOZ_TOKENIZER_JWT_SECRET or SIGNOZ_JWT_SECRET is unset

Discovery Timeline

  • 2026-09-24 - CVE CVE-2026-97055 published to NVD
  • 2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-97055

Vulnerability Analysis

SigNoz uses a pluggable tokenizer architecture, with the jwt provider configured as the default. The provider reads its signing key from tokenizer::jwt::secret, populated via SIGNOZ_TOKENIZER_JWT_SECRET or the deprecated SIGNOZ_JWT_SECRET. When neither variable is set, the secret defaults to an empty string.

The Config.Validate() routine does not reject this empty value. The service starts normally and uses the empty string as the HMAC-SHA256 key for both signing and verifying session tokens. Any attacker who can mint a JWT with the same empty key produces tokens the server accepts as authentic.

Tokens contain three claims: id, orgId, and email. The /api/v2/sessions/context endpoint returns the organization ID and confirms whether an email is registered without requiring authentication. Combined with a known user ID, this provides every claim needed to forge a valid session.

Root Cause

The root cause is an insecure default configuration combined with missing input validation. The tokenizer package exported Provider: "jwt" as the default and logged a warning when the secret was empty, but did not fail startup. 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 30-day lifetime.

Attack Vector

The attack is remote, unauthenticated, and does not require user interaction. An attacker queries /api/v2/sessions/context to retrieve orgId, then forges a JWT signed with an empty key containing the target user's id, orgId, and email. The forged token is presented to the SigNoz API, which verifies it successfully.

go
// Patch in pkg/tokenizer/config.go — reject empty secret when provider is jwt
// Source: https://github.com/SigNoz/signoz/commit/67895d366d
if c.Provider == "jwt" && c.JWT.Secret == "" {
    return errors.New(
        errors.TypeInvalidInput,
        errors.CodeInvalidInput,
        "jwt::secret must be set when provider is jwt, without a JWT secret, user sessions are vulnerable to tampering and unauthorized access",
    )
}

return nil
go
// Patch in pkg/tokenizer/config.go — change default provider to opaque
// Source: https://github.com/SigNoz/signoz/commit/b02aae2db3
func newConfig() factory.Config {
    return &Config{
        Provider: "opaque",
        Opaque: OpaqueConfig{
            GC: GCConfig{
                Interval: 1 * time.Hour,
            },
        },
    }
}

Detect Identity Attacks the Moment Authentication Fails

Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.

Stop Identity Attacks

Detection Methods for CVE-2026-97055

Indicators of Compromise

  • Unauthenticated requests to /api/v2/sessions/context enumerating organization IDs or email addresses.
  • Successful authentications from unexpected IP addresses or geolocations immediately following sessions/context queries.
  • Token rotation events at /api/v2/sessions/rotate without a preceding login event in audit logs.
  • Administrator actions originating from sessions that lack a corresponding interactive login record.

Detection Strategies

  • Inspect SigNoz process environment for an unset or empty SIGNOZ_TOKENIZER_JWT_SECRET and SIGNOZ_JWT_SECRET.
  • Decode active JWTs and verify the signature with an empty key; successful verification confirms vulnerable configuration.
  • Compare running SigNoz version against the patched release v0.143.0 across all environments.

Monitoring Recommendations

  • Log and alert on all requests to /api/v2/sessions/context and /api/v2/sessions/rotate with source IP correlation.
  • Monitor for new administrative sessions and privilege-sensitive actions in SigNoz audit logs.
  • Forward SigNoz access and audit logs to a centralized analytics platform for anomaly detection.

How to Mitigate CVE-2026-97055

Immediate Actions Required

  • Upgrade SigNoz to v0.143.0 or later, which enforces the JWT secret requirement and defaults to the opaque provider.
  • If immediate upgrade is not possible, set a strong, random SIGNOZ_TOKENIZER_JWT_SECRET value and restart the service.
  • Rotate the JWT secret after upgrade to invalidate any tokens an attacker may have forged.
  • Audit SigNoz user accounts, API tokens, and recent administrative actions for signs of unauthorized access.

Patch Information

The fix is delivered in SigNoz v0.143.0 across two commits. Commit 67895d366d adds validation that rejects an empty jwt::secret when the provider is jwt. Commit b02aae2db3 changes the default tokenizer provider to opaque. See the GitHub Security Advisory GHSA-c26w-g4j8-39m2 and the VulnCheck Advisory on Authentication Bypass for full details.

Workarounds

  • Explicitly configure SIGNOZ_TOKENIZER_JWT_SECRET with a cryptographically random value of at least 32 bytes before exposing SigNoz to any network.
  • Restrict network access to the SigNoz API behind a reverse proxy or VPN until the patched version is deployed.
  • Switch the tokenizer provider configuration from jwt to opaque where supported, aligning with the post-patch default.
bash
# Configuration example — set a strong JWT secret before starting SigNoz
export SIGNOZ_TOKENIZER_JWT_SECRET="$(openssl rand -base64 48)"

# Verify the variable is populated in the running container
docker exec signoz-query-service printenv SIGNOZ_TOKENIZER_JWT_SECRET

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.