Advisory · CVE-2026-97055
SigNoz shipped an empty default JWT secret
SigNoz before 0.143.0 signed session tokens with an empty key when no JWT secret was configured, letting unauthenticated attackers forge admin session tokens.
- Vendor
- SigNoz
- Product
- SigNoz
- Identifier / CWE
- CVE-2026-97055
CWE-1188 - Action timing
- Immediate
Explain it like I’m five
SigNoz locks its session doors with a combination lock, but shipped with the combination left blank and never complained about it. Anyone who knows a username can turn the blank dial and walk in as the admin.
- 01Empty default secret
SigNoz defaults the JWT tokenizer signing secret to an empty string, and Config.Validate() does not reject the empty value, so an unconfigured deployment starts up normally.
- 02Tokens signed with empty key
Because the JWT tokenizer was the default provider, the deployment signs and verifies session tokens with an empty HMAC key.
- 03Attacker reconnaissance
An unauthenticated attacker learns a user ID and the organization ID from the /api/v2/sessions/context endpoint without authenticating.
- 04Forged session token
The attacker signs id, orgId, and email claims with the empty key, producing a valid session token for that user, including an administrator.
- 05Refresh token rotation
A forged refresh token can be exchanged at /api/v2/sessions/rotate for a new token pair that cannot be revoked and stays usable for its full lifetime of 30 days by default.
What happened
SigNoz published a security advisory for an authentication bypass in its open-source observability platform. From v0.8.0 to before v0.143.0, the JWT tokenizer signing secret (tokenizer::jwt::secret, set via SIGNOZ_TOKENIZER_JWT_SECRET or the deprecated SIGNOZ_JWT_SECRET) defaulted to an empty string, and the configuration validator accepted the empty value. Since the JWT tokenizer was the default provider, any deployment that never configured a secret both signed and verified session tokens with an empty HMAC key.
An unauthenticated attacker who knows the ID of an existing user, which along with the organization ID can be obtained without authentication from /api/v2/sessions/context, could forge a valid session token for that user, including an administrator, simply by signing the claims with the empty key. A forged refresh token could then be exchanged at /api/v2/sessions/rotate for a fresh token pair that cannot be revoked. The fix ships in v0.143.0 (commits 67895d366d and b02aae2db3), which requires a JWT secret when the jwt provider is selected and changes the default provider to opaque.
What to do
- Upgrade SigNoz to v0.143.0 or later on every deployment.
- Set a strong SIGNOZ_TOKENIZER_JWT_SECRET in your deployment configuration before or during the upgrade.
- Force re-authentication for all users after patching; any tokens issued before the fix should be treated as potentially compromised.
- Review audit logs for unexpected admin logins or token usage, especially tokens that were rotated repeatedly and never expired through normal sessions.
- If admin access was abused, rotate any credentials, API keys, or alerting integrations reachable from the SigNoz deployment.
Management note
This is a full admin takeover of a platform that watches your whole stack, and it affects every deployment that took the defaults. The upgrade plus a configured secret is the fix; the harder part is checking whether someone already walked through the unlocked door.