Centrifugo: SSRF via unverified JWT claims interpolated into dynamic JWKS endpoint URL

Vulnerability

Overview

CVE-2026-32301 is a Server-Side Request Forgery (SSRF) vulnerability in Centrifugo, an open-source real-time messaging server, affecting versions prior to 6.7.0. The flaw occurs when Centrifugo is configured with a dynamic JWKS endpoint URL that uses 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 [1][2].

Root

Cause and Exploitation

The root cause lies in the order of operations in the token verification process. In internal/jwtverify/token_verifier_jwt.go, the functions VerifyConnectToken and VerifySubscribeToken parse the token without verification using jwt.ParseNoVerify, decode the claims, and then call validateClaims() which extracts named regex capture groups from issuer_regex/audience_regex into a tokenVars map using attacker-controlled iss/aud claim values. This tokenVars map is then passed to verifySignatureByJWK, which in internal/jwks/manager.go interpolates the variables directly into the JWKS URL via m.url.ExecuteString(tokenVars). Centrifugo then makes an HTTP GET request to the attacker-controlled URL. Signature verification occurs only after the SSRF has already been triggered [2].

Impact

An unauthenticated attacker can exploit this vulnerability to force the Centrifugo server to make arbitrary outbound HTTP requests to destinations of their controlled destination. This can be used to probe internal network services, access cloud metadata endpoints (e.g., AWS/ GCP metadata endpoints), or interact with other internal systems, potentially leading to further compromise. The attack requires no authentication and can be executed remotely [1][2].

Mitigation

The vulnerability is fixed in Centrifugo version 6.7.0. Users are strongly advised to upgrade immediately. As a workaround, administrators should avoid using dynamic JWKS endpoint URLs with template variables derived from unverified JWT claims until the upgrade can be applied [1][2].