Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.7",
  "pubDate": "2026-09-14T20:16:45.697Z",
  "pubdate": "2026-09-14T20:16:45.697Z",
  "executiveSummary": "Skipper versions prior to 0.27.13 contain an authentication bypass vulnerability within the routesrv component.\nThe vulnerability arises from the total absence of application-layer authentication for critical control-plane data endpoints, including /routes, /routes/{zone}, /swarm/redis/shards, and /swarm/valkey/shards.\nAny pod with network reachability to the routesrv component within a Kubernetes cluster can query these endpoints to exfiltrate sensitive configuration data.\nThe impact includes the exposure of Ingress and RouteGroup backend URLs, filter-chain details, OAuth/OIDC path configurations, and internal Redis or Valkey shard addresses.\nWhile network-level controls like Kubernetes NetworkPolicies can mitigate reachability, they do not resolve the underlying missing authentication logic.\nThis vulnerability leads to significant confidentiality loss, potentially exposing infrastructure metadata that facilitates further lateral movement or deeper reconnaissance of the cluster environment.",
  "technicalDetails": "The root cause of this vulnerability is the lack of identity verification and authorization checks within the routesrv component's HTTP handler registration logic. Specifically, the handlers defined in routesrv/routesrv.go, eskipBytes.ServeHTTP (routesrv/eskipbytes.go), RedisHandler.ServeHTTP (routesrv/redishandler.go), and ValkeyHandler.ServeHTTP (routesrv/valkeyhandler.go) perform strictly method-based filtering (e.g., restricting HTTP verbs) without implementing any layer-7 authentication or RBAC validation.\nBecause the routesrv component is designed to serve cluster-wide control-plane data, it is expected to require robust authentication to prevent unauthorized access. However, the current implementation implicitly trusts any caller within the network perimeter. An attacker-controlled pod with access to the Kubernetes cluster network can initiate direct HTTP requests to these endpoints without providing credentials or tokens.\nThe attack flow involves: 1) Identification of the routesrv service address within the cluster network. 2) Crafting GET requests targeting the exposed routes or shard endpoints. 3) Intercepting the returned raw cluster-wide data, which includes sensitive routing and infrastructure backend details.\nThe vulnerability allows for the leakage of metadata that is typically protected by namespace-scoped RBAC policies. By querying the /routes endpoint, an attacker can bypass these namespace boundaries to map the internal structure of the Ingress and RouteGroup resources. Furthermore, the exposure of OAuth or OIDC paths provides attackers with potential entry points to identify authentication service configurations, while the leakage of Redis or Valkey shard addresses provides internal topology data that may be leveraged in subsequent service-specific attacks.\nThe absence of authentication effectively turns the routesrv service into an open directory of internal service configurations. Although the vulnerability is restricted to the internal network, it poses a severe risk in multi-tenant or compromised environments where lateral movement is a primary goal. The fix in version 0.27.13 involves the integration of necessary authentication middleware to validate callers before serving control-plane data."
}