GHSA-9468-v6mj-fppw

## Vulnerability Details

**File**: `internal/client/handler.go` (`OnClientConnecting`), `internal/proxy/http.go` (`requestHeaders`), `internal/proxy/grpc.go` (`requestMetadata`), `internal/unigrpc/grpc.go` (`Consume`) **Line**: handler.go:389,548-552 (`e.Headers` -> `SetEmulatedHeadersToContext`), http.go:131-165 (`requestHeaders`), grpc.go:82-114 (`requestMetadata`), unigrpc/grpc.go:46 (`Headers: req.Headers`)

### Root Cause The `http_headers` / `grpc_metadata` proxy config options are documented as "List of incoming HTTP header names to forward to the proxy backend" / "List of incoming gRPC metadata keys to forward to the proxy backend" -- implying the value originates from the underlying transport connection (e.g. set by a trusted reverse proxy/API gateway in front of Centrifugo). Operators commonly use this to forward identity/trust headers to their own backend for access-control decisions.

However, the wire protocol used by every Centrifugo transport (`protocol.ConnectRequest`, field `headers`) includes a `headers` map populated entirely from the connecting client's own message (its JSON `connect` command, or for gRPC, its `ConnectRequest` protobuf field) -- not from real transport-level HTTP headers. Centrifugo copies this client-supplied map verbatim into `ConnectEvent.Headers`, then into an "emulated headers" context value used by every proxy type (connect, refresh, subscribe, publish, rpc, sub_refresh, map_publish, map_remove, shared_poll_refresh) for the entire connection lifetime. Any header name in the operator's allowlist is forwarded to the backend with the client's own chosen value, unless a header of the exact same name also happens to be present on the genuine underlying HTTP request. For the unidirectional gRPC transport specifically there is no HTTP request at all, so there is no possible override -- the client-controlled value always wins.

### Attack Scenario 1. Operator configures a connect proxy with `http_headers: ["x-trusted-user"]` (or any header name their backend uses for caller identity/trust). 2. Attacker connects directly to Centrifugo and sends a connect command containing `"headers": {"x-trusted-user": "<any value>"}`. 3. Centrifugo forwards `X-Trusted-User: <attacker value>` to the backend exactly as if a trusted intermediary had set it. 4. The backend, trusting this header per its own design, grants whatever access/identity it associates with that value.

### Impact Full spoofing of any header value the backend trusts for authentication/authorization, for every proxy call type, for the lifetime of the connection -- up to full account/identity impersonation depending on backend logic. No credentials, JWT, or API key required.

### Vulnerable Code ```go // internal/proxy/http.go func requestHeaders(ctx context.Context, allowedHeaders, allowedMetaKeys []string, staticHeaders map[string]string) http.Header { headers := http.Header{} for k, v := range staticHeaders { headers.Set(k, v) } emulatedHeaders, _ := clientcontext.GetEmulatedHeadersFromContext(ctx) // 100% client-controlled for k, v := range emulatedHeaders { if slices.Contains(allowedHeaders, strings.ToLower(k)) { headers.Set(k, v) // forwarded to backend as a real outgoing HTTP header } } httpHeaders, hasHTTPHeaders := middleware.GetHeadersFromContext(ctx) // real headers, if present for k, vv := range httpHeaders { if slices.Contains(allowedHeaders, strings.ToLower(k)) { headers[k] = vv // only overrides if SAME header name was ALSO on the real request } } ... } ``` ```go // internal/unigrpc/grpc.go -- never goes through HTTP middleware, no competing real-header check at all connectRequest := &protocol.ConnectRequest{ Token: req.Token, Data: req.Data, Name: req.Name, Version: req.Version, Headers: req.Headers, // the gRPC client's own protobuf field } ```

### Recommended Fix Document explicitly that `http_headers`/`grpc_metadata` values can also be supplied by the connecting client itself via "headers emulation" and are not guaranteed to come from a trusted reverse proxy. Provide a separate allowlist (e.g. `trusted_http_headers`) populated only from genuine transport-level HTTP headers, never from client-supplied `ConnectRequest.headers`, for operators who need an unforgeable header. For uniGRPC, consider disabling `http_headers` forwarding entirely since there is no transport-level header concept to fall back on.

### Verification Dynamically confirmed against the official `centrifugo/centrifugo:v6.8.3` Docker image on BOTH the bidirectional WebSocket transport and the unidirectional gRPC transport, using a minimal backend that logs every header it receives: - WS: connecting with `{"connect": {"headers": {"x-trusted-user": "admin-impersonation-via-headers-emulation"}}}` resulted in the backend receiving `X-Trusted-User: admin-impersonation-via-headers-emulation`, despite no such header existing on the real WebSocket upgrade HTTP request. - uniGRPC: calling the `Consume` RPC with `ConnectRequest(headers={"x-trusted-user": "admin-impersonation-via-unigrpc"})` (zero real gRPC metadata set) resulted in the backend receiving `X-Trusted-User: admin-impersonation-via-unigrpc`. - Control tests (no `headers` field / no metadata) confirmed the header is absent from the backend's request in the baseline case.