CVE-2026-32301

Summary

Summary Centrifugo is vulnerable to Server-Side Request Forgery (SSRF) when configured with a dynamic JWKS endpoint URL using template variables (e.g. {{tenant}}). An unauthenticated attacker can craft a JWT with a malicious iss or aud claim value that gets interpolated into the JWKS fetch URL before the token signature is verified, causing Centrifugo to make an outbound HTTP request to an attacker-controlled destination. Details In internal/jwtverify/tokenverifierjwt.go, the functions VerifyConnectToken and VerifySubscribeToken follow this flawed order of operations: Token is parsed without verification: jwt.ParseNoVerify([]byte(t)) Claims are decoded from the unverified token validateClaims() runs, extracting named regex capture groups from issuerregex/audienceregex into tokenVars map using attacker-controlled iss/aud claim values verifySignatureByJWK(token, tokenVars) is called, passing attacker-controlled tokenVars to the JWKS manager In internal/jwks/manager.go, fetchKey() interpolates tokenVars directly into the JWKS URL: jwkURL := m.url.ExecuteString(tokenVars) Centrifugo makes an HTTP GET request to the attacker-controlled URL Suppressed the security linter on this line with an incorrect comment: //nolint:gosec // URL is from server configuration, not user input. The URL is NOT purely from server configuration, it is partially constructed from unverified user-supplied JWT claims. Signature verification happens too late, after the SSRF has already fired. PoC Required config (config.json): Step 1, Start listener on attacker machine: Step 2, Generate malicious unsigned JWT: Step 3, Connect to Centrifugo WebSocket with the malicious token: Step 4, Observe incoming HTTP request on attacker listener: Malicious token being crafted with suppressorigin=True bypassing the 403, and the token sent to Centrifugo: Centrifugo Server Log: netcat terminal: Impact Unauthenticated SSRF, No valid credentials required Attacker can probe and access internal network services not exposed externally On cloud deployments: access to metadata endpoints (AWS: 169.254.169.254, GCP: metadata.google.internal) to steal IAM credentials Attacker can serve a malicious JWKS response containing their own public key, causing Centrifugo to accept attacker-signed tokens as legitimate, leading to full authentication bypass Exploitation requires jwkspublicendpoint to contain {{...}} template variables combined with issuerregex or audienceregex, a configuration pattern explicitly documented and promoted by Centrifugo Suggested Fix Verify signature BEFORE extracting tokenVars (critical fix): In tokenverifier_jwt.go, swap the order of operations: Fix the incorrect nolint comment in manager.go: Remove //nolint:gosec // URL is from server configuration, not user input The URL IS partially constructed from user input via JWT claims. Alternative mitigation: Restrict template variables to only the kid header field (which is not claim data) rather than allowing arbitrary claim values to influence the JWKS URL. ```

Impact

Affected versions

Security releases

Remediation advice