CVE-2026-54246 in skipper
Summary
by MITRE • 09/14/2026
Skipper is an HTTP router and reverse proxy for service composition. Prior to 0.27.13, the routesrv component serves cluster-wide control-plane data without application-layer authentication through /routes, /routes/{zone}, /swarm/redis/shards, and /swarm/valkey/shards. The handlers registered in routesrv/routesrv.go, eskipBytes.ServeHTTP in routesrv/eskipbytes.go, RedisHandler.ServeHTTP in routesrv/redishandler.go, and ValkeyHandler.ServeHTTP in routesrv/valkeyhandler.go only restrict HTTP methods and do not authenticate callers. A compromised or otherwise attacker-controlled pod that can reach routesrv on the Kubernetes cluster network can bypass its namespace-scoped RBAC and read Ingress and RouteGroup backend URLs, filter-chain and OAuth or OIDC path details, and Redis or Valkey shard addresses across namespaces. NetworkPolicy can restrict reachability but does not remove the missing-authentication condition, and the established impact is confidentiality exposure rather than direct integrity or availability loss. This issue is fixed in version 0.27.13.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/19/2026
Skipper serves as a critical HTTP router and reverse proxy within Kubernetes environments, facilitating service composition by managing traffic routing based on defined rules. The vulnerability identified affects the routesrv component of Skipper prior to version 0.27.13, which is responsible for serving cluster-wide control-plane data. This component exposes several endpoints including /routes, /routes/{zone}, /swarm/redis/shards, and /swarm/valkey/shards that are designed to provide configuration details necessary for routing decisions across the entire cluster rather than being scoped to individual namespaces. The core technical flaw lies in the authentication mechanisms implemented within these handlers. Specifically, the functions eskipBytes.ServeHTTP, RedisHandler.ServeHTTP, and ValkeyHandler.ServeHTTP rely solely on HTTP method restrictions to limit access but completely lack application-layer authentication checks. This architectural oversight means that any request reaching these endpoints is processed without verifying the identity or authorization of the caller, effectively bypassing the namespace-scoped Role-Based Access Control (RBAC) policies that typically govern resource visibility in Kubernetes clusters.
The operational impact of this vulnerability is significant for organizations relying on Skipper for ingress management and service mesh configurations. An attacker who has compromised a pod within the cluster network or otherwise gained access to the internal network segment where routesrv resides can exploit these unauthenticated endpoints. By doing so, they can extract sensitive control-plane data that includes Ingress and RouteGroup backend URLs, which reveal the underlying services and their locations. Furthermore, the exposure of filter-chain configurations and OAuth or OIDC path details allows an attacker to understand the security mechanisms in place, potentially identifying weaknesses in authentication flows or token validation logic. The disclosure of Redis or Valkey shard addresses also provides valuable reconnaissance information about the infrastructure's data storage layer. This scenario aligns with CWE-287 Improper Authentication, as the system fails to adequately verify the identity of users attempting to access sensitive resources. Additionally, this behavior maps to MITRE ATT&CK technique T1046 Network Service Discovery, where an adversary uses discovered services and their associated data to map out the environment for further exploitation.
While network policies can be configured to restrict reachability to these endpoints from unauthorized pods, such measures do not eliminate the fundamental flaw of missing authentication at the application layer. If a compromised entity manages to bypass network segmentation or if legitimate traffic is routed through untrusted paths due to misconfiguration, the data remains exposed. The primary consequence of this vulnerability is confidentiality exposure rather than direct integrity or availability loss, as the attacker gains read-only access to configuration details without an immediate mechanism to modify them directly through these specific endpoints. However, the intelligence gained can facilitate more sophisticated attacks such as targeted phishing via revealed OAuth paths or lateral movement by identifying internal service dependencies. To mitigate this risk, organizations must upgrade Skipper to version 0.27.13 or later where proper authentication checks have been implemented for these handlers. In addition to upgrading, it is advisable to implement strict network policies that limit access to the routesrv component only from trusted control-plane components and to monitor logs for any unauthorized access attempts to these endpoints as a defensive measure against potential exploitation in environments where upgrades may be delayed.