Summary
Centrifugo's InsecureSkipTokenSignatureVerify flag silently disables JWT verification with no warning
Centrifugo supports a configuration flag insecure_skip_token_signature_verify that completely disables JWT signature verification. When enabled, Centrifugo accepts any JWT token regardless of signature validity, including tokens signed with wrong keys, random signatures, or no signature at all. Critically, no warning is logged at startup or runtime when this flag is active, making it invisible to operators and security auditors.
Note: This vulnerability requires the operator to have explicitly set insecure_skip_token_signature_verify=true. The core issue is the absence of any warning when this flag is active, making accidental production exposure undetectable.
Details
The flag is defined in internal/configtypes/types.go:
InsecureSkipTokenSignatureVerify bool `mapstructure:"insecure_skip_token_signature_verify"`
It is passed directly to token verification in internal/client/handler.go:
token, err := h.tokenVerifier.VerifyConnectToken(e.Token,
cfg.Client.InsecureSkipTokenSignatureVerify)
In token_verifier_jwt.go, when skipVerify=true the entire signature block is bypassed:
if !skipVerify {
// This block never executes
err = verifier.verifySignature(token)
}
The flag is configurable via multiple vectors making accidental exposure likely:
- Config file:
insecure_skip_token_signature_verify: true - Environment variable:
CENTRIFUGO_INSECURE_SKIP_TOKEN_SIGNATURE_VERIFY=true - YAML, TOML config formats
Despite hmac_secret_key being configured, startup logs show "enabled JWT verifiers", falsely implying verification is active.
PoC
Config with legitimate HMAC key but skip flag enabled:
{
"client": {
"insecure_skip_token_signature_verify": true,
"token": { "hmac_secret_key": "legitimate-production-secret-key" }
}
}
Token signed with completely wrong key is fully accepted:
VULNERABILITY CONFIRMED!
Connected as user: {'client': '899dec73...', 'version': '0.0.0 OSS'}
No security warning emitted when insecure_skip_token_signature_verify=true:
Token signed with wrong key accepted, authentication bypass confirmed:
skipVerify flag propagated from config to all token verification calls:
Impact
- Any unauthenticated user can connect as any arbitrary user ID
- Complete authentication bypass, attacker sets any
subclaim value - No indicators in logs that the server is operating insecurely
- Easily triggered accidentally via environment variable injection
in containerized deployments (e.g. misconfigured Kubernetes secrets) - Affects all connection types: WebSocket, HTTP-streaming, SSE, GRPC
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-Q926-C743-49QJ? GHSA-Q926-C743-49QJ is a low-severity security vulnerability in github.com/centrifugal/centrifugo/v6 (go), affecting versions <= 6.6.2. It is fixed in 6.7.0.
- Which packages are affected by GHSA-Q926-C743-49QJ?
github.com/centrifugal/centrifugo/v6(go) (versions <= 6.6.2)github.com/centrifugal/centrifugo(go) (versions <= 2.4.0)github.com/centrifugal/centrifugo/v3(go) (versions <= 3.2.3)github.com/centrifugal/centrifugo/v4(go) (versions <= 4.1.5)github.com/centrifugal/centrifugo/v5(go) (versions <= 5.4.9)
- Is there a fix for GHSA-Q926-C743-49QJ? Yes. GHSA-Q926-C743-49QJ is fixed in 6.7.0. Upgrade to this version or later.
- Is GHSA-Q926-C743-49QJ exploitable, and should I be worried? Whether GHSA-Q926-C743-49QJ is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-Q926-C743-49QJ is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-Q926-C743-49QJ? Upgrade
github.com/centrifugal/centrifugo/v6to 6.7.0 or later.