CVE-2026-71485: Centrifugo: Client-forgeable headers emulation lets any client spoof headers forwarded to proxy backends
Centrifugo is an open-source scalable real-time messaging server. Prior to 6.9.0, Centrifugo copies the client-controlled protocol.ConnectRequest.headers map through OnClientConnecting in internal/client/handler.go, ConnectEvent.Headers, and SetEmulatedHeadersToContext. The requestHeaders path in internal/proxy/http.go, the requestMetadata path in internal/proxy/grpc.go, and the Consume path in internal/unigrpc/grpc.go can forward an allowlisted value as a trusted backend header or metadata value. A remote client can spoof a header such as x-trusted-user for connect, refresh, subscribe, publish, RPC, and related proxy calls when the backend relies on that header for authentication or authorization. The unidirectional gRPC transport has no transport-level HTTP header that can override the emulated value. This issue is fixed in version 6.9.0.
Security readout for executives and security teams
Plain-English summary
Centrifugo before 6.9.0 can mistake client-supplied values for trusted headers sent to backend services. If those services use such headers to identify users or grant permissions, an unauthenticated remote client could impersonate another user or perform unauthorized actions. Impact depends on proxy configuration and backend trust decisions.
Executive priority
Treat as an urgent upgrade and trust-boundary review. The vulnerability can enable impersonation and unauthorized data access or modification without prior authentication when vulnerable forwarding configurations meet trusting backends. Focus first on public deployments and systems where Centrifugo proxies security-sensitive operations.
Technical view
Client-controlled ConnectRequest.headers can reach HTTP, gRPC, and unidirectional gRPC proxy backends through Centrifugo’s header-emulation flow. Allowlisted values may therefore become trusted backend headers or metadata across connect, refresh, subscribe, publish, RPC, and related calls. CVSS 3.1 is 9.1, reflecting unauthenticated network access with high confidentiality and integrity impact.
Likely exposure
Exposure is most likely where Centrifugo earlier than 6.9.0 forwards allowlisted headers or metadata and a backend uses them for authentication or authorization. Internet-accessible client connections increase reachability. Installations that do not trust forwarded client-derived identity headers may have lower practical impact, but still require configuration review.
Exploitation context
The supplied sources describe a remotely reachable, low-complexity issue requiring no privileges or user interaction. The bundle marks it absent from KEV and provides no evidence of active exploitation. This should not be interpreted as evidence that exploitation is impossible or has not occurred.
Researcher notes
The affected flow passes ConnectRequest.headers through OnClientConnecting, ConnectEvent.Headers, and SetEmulatedHeadersToContext. Relevant sinks include HTTP requestHeaders, gRPC requestMetadata, and unidirectional gRPC Consume. The source specifically notes that unidirectional gRPC lacks a transport-level HTTP header capable of overriding the emulated value. Fixed in 6.9.0.
Mitigation direction
Upgrade Centrifugo to version 6.9.0 or later.
Inventory proxy header and metadata allowlists across HTTP, gRPC, and unidirectional gRPC integrations.
Stop backends from authorizing requests solely from client-influenced forwarded headers.
Review vendor guidance and the 6.9.0 security change before deployment.
Prioritize externally reachable systems and sensitive publish, subscribe, or RPC backends.
Validation and detection
Confirm every deployed Centrifugo instance reports version 6.9.0 or later.
Review configurations for allowlisted identity, role, tenant, or authorization headers.
Trace whether backend authentication decisions consume Centrifugo-forwarded headers or metadata.
Verify backend identity derives from authenticated server-side context, not client-provided header maps.
After upgrading, test that client-supplied emulated headers cannot influence trusted backend identity.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-290: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
5Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: yesTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-290 · source CWE mapping
Authentication Bypass by Spoofing
Authentication Bypass by Spoofing represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.