Database/Container, Kubernetes & orchestration

Skipper routesrv: cluster-wide route and Redis/Valkey shard data served with no authentication

CVSS 5.7CVE-2026-54246Container, Kubernetes & orchestrationcurated

Impact

routesrv exposes /routes, /routes/{zone}, /swarm/redis/shards and /swarm/valkey/shards with only HTTP method restrictions and no caller authentication. Any pod that can reach routesrv on the cluster network reads the aggregated routing state across every namespace - Ingress and RouteGroup backend URLs, filter chains, and OAuth/OIDC path configuration - plus the Redis or Valkey shard addresses Skipper uses for rate limiting. That sidesteps the namespace-scoped RBAC the tenant was given: a compromised workload in one namespace gets a map of internal service endpoints belonging to every other tenant, which is exactly the reconnaissance step before lateral movement. The established impact is confidentiality only; there is no direct write or availability path through these handlers. NetworkPolicy reduces who can reach the port but does not add the missing authentication.

Who can reach it

Any pod or host on the Kubernetes cluster network that can open a connection to the routesrv port. No credentials required.

What to do

Upgrade Skipper to 0.27.13 and restart the routesrv deployment; this is a control-plane component, so no node drain or workload disruption is involved. As defence in depth, add a NetworkPolicy allowing only Skipper proxy pods to reach routesrv, and treat any backend URLs or OIDC paths already disclosed as known to tenants.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-54246 https://github.com/zalando/skipper/security/advisories/GHSA-5587-2x54-jj6h https://github.com/zalando/skipper/commit/fb3d5f98ee749d9a1dfc5df2d51ac9b82fab92aa https://github.com/zalando/skipper/releases/tag/v0.27.13

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.