Skipper’s routesrv component exposes multiple API endpoints—/routes, /routes/{zone}, /swarm/redis/shards, and /swarm/valkey/shards—without applying any application‑layer authentication. The request handlers defined in routesrv.go, eskipBytes.ServeHTTP, RedisHandler.ServeHTTP, and ValkeyHandler.ServeHTTP only enforce HTTP method restrictions and fail to authenticate callers. Consequently, any pod that can reach the routesrv service within the Kubernetes cluster network can bypass namespace‑scoped RBAC and read backend routing information, filter chains, OAuth/OIDC path details, and the addresses of Redis or Valkey shards spanning namespaces. The principal effect is the exposure of confidential cluster‑level configuration data rather than a direct loss of integrity or availability.

The vulnerability applies to the Skipper HTTP router and reverse proxy released by Zalando, affecting all Skipper installations prior to version 0.27.13. Any cluster using the routesrv component in these earlier releases is susceptible, regardless of how the application is deployed within the Kubernetes environment.

With a CVSS score of 5.7, the problem presents a moderate severity risk. The EPSS score is < 1% and the vulnerability is not listed in CISA’s KEV catalog. The attack requires that an attacker control a pod or otherwise reach the routesrv component within the cluster network; once reached, the attacker can bypass namespace‑scoped RBAC and read sensitive configuration data. NetworkPolicy can limit reachability, but it does not remove the exposure of confidential cluster‑level information rather than immediate integrity or availability compromise.