CVE-2026-75886: Openshift/console: openshift/console: unauthenticated reverse proxy to in-cluster catalogd service with session token forwarding
A flaw was found in openshift/console. An unauthenticated remote attacker can exploit a misconfiguration in the CatalogdHandler, which lacks proper authentication, and the forwarding of the openshift-session-token cookie. This allows the attacker to send requests to the in-cluster catalogd service, leading to the disclosure of the internal operator-catalog index and providing a relay into the openshift-catalogd namespace.
Other sources
The CatalogdHandler() in the OpenShift console is registered without authHandler (pkg/server/server.go:340). Furthermore, the CatalogdProxyConfig is the only proxy config that omits HeaderBlacklist: srv.ProxyHeaderDenyList (cmd/bridge/main.go:429-432), so the user's openshift-session-token cookie is forwarded verbatim to the catalogd service.
Any unauthenticated network actor can GET /api/catalogd/<arbitrary-path> and the console pod will issue a TLS request to catalogd-service.openshift-catalogd.svc:443/<arbitrary-path>. This discloses the full operator-catalog index (intended to be cluster-internal) and provides a relay primitive into the openshift-catalogd namespace.
Tested and reproduced on OCP 5.0 nightly cluster.
Upstream: https://github.com/openshift/console File: pkg/server/server.go:340, pkg/server/server.go:859-868, cmd/bridge/main.go:429-432
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Register CatalogdHandler with authHandler instead of leaving it unauthenticated.
OpenShift console CatalogdHandler authHandler = registered - Configuration
Set HeaderBlacklist to srv.ProxyHeaderDenyList so the openshift-session-token cookie is not forwarded to catalogd-service.openshift-catalogd.svc.
OpenShift console CatalogdProxyConfig HeaderBlacklist = srv.ProxyHeaderDenyList
Event History
Frequently Asked Questions
Who is exposed to this issue?
Any deployment where an unauthenticated network actor can reach the OpenShift console endpoint is exposed. The attacker does not need credentials or user interaction.
What can an attacker access or do through the vulnerable endpoint?
An attacker can send GET requests to /api/catalogd/<arbitrary-path>, causing the console pod to make a TLS request to the in-cluster catalogd service. This can disclose the internal operator-catalog index and provide a relay into the openshift-catalogd namespace.
Why does session-token forwarding matter?
The Catalogd proxy configuration does not apply the proxy header deny list, so an openshift-session-token cookie is forwarded verbatim to catalogd. This means requests proxied through the endpoint may carry a user's session token to the in-cluster service.
How was the issue confirmed?
The issue was tested and reproduced on an OCP 5.0 nightly cluster. The affected handler is registered without an authentication handler, and the Catalogd proxy configuration omits the header blacklist used by other proxy configurations.