The routesrv component exposes the full cluster route topology (Ingress/RouteGroup configurations, backend URLs, filter chains, OAuth/OIDC callback paths) and cache-cluster topology (Redis/Valkey shard addresses) over plain HTTP with zero authentication. Any pod in the Kubernetes cluster can reach routesrv via its predictable DNS name and retrieve sensitive cluster-wide routing and cache infrastructure data.
routesrv/routesrv.go:87-99,114-137 — all handler registrations on the main mux:
mux.Handle("/routes", b) // eskipBytes.ServeHTTP — all route data
mux.Handle("/routes/{zone}", b) // zone-scoped route data
mux.Handle("/swarm/redis/shards", rh) // Redis cluster addresses
mux.Handle("/swarm/valkey/shards", vh) // Valkey cluster addresses
routesrv/eskipbytes.go:134-196 — eskipBytes.ServeHTTP:
func (e *eskipBytes) ServeHTTP(rw http.ResponseWriter, r *http.Request) {
// ... only checks GET/HEAD method, NO auth check
if r.Method != "GET" && r.Method != "HEAD" {
w.WriteHeader(http.StatusMethodNotAllowed)
return
}
// ... serves all route data immediately
}
routesrv/redishandler.go:28-41 — RedisHandler.ServeHTTP:
func (rh *RedisHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
if r.Method != "GET" {
w.WriteHeader(http.StatusMethodNotAllowed)
return
}
// ... serves Redis cluster addresses immediately, NO auth check
}
routesrv/valkeyhandler.go:28-41 — ValkeyHandler.ServeHTTP:
func (vh *ValkeyHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
if r.Method != "GET" {
w.WriteHeader(http.StatusMethodNotAllowed)
return
}
// ... serves Valkey cluster addresses immediately, NO auth check
}
skipper-ingress-routesrv.kube-system.svc.cluster.local:9090 (documented at docs/tutorials/operations.md:108, docs/tutorials/ratelimit.md:137,197)GET http://<routesrv>:9090/routes → All Ingress/RouteGroup configurations across ALL namespacesGET http://<routesrv>:9090/swarm/redis/shards → Redis cache cluster node addressesGET http://<routesrv>:9090/swarm/valkey/shards → Valkey cache cluster node addressesThe routesrv uses a ServiceAccount with cluster-wide RBAC to list Ingress (networking.k8s.io), RouteGroup (zalando.org), Endpoints, and Services across all namespaces (see clusterclient.go:648-653 fetchClusterState). The kube-apiserver requires proper ServiceAccount token + RBAC authorization for the Kubernetes API itself, but routesrv exposes the aggregated data over HTTP with zero authentication.
A compromised pod with limited RBAC (restricted to its own namespace) can bypass Kubernetes RBAC entirely by reading routesrv. This crosses the boundary from "namespace-scoped Kubernetes workload with restricted RBAC" to "full cluster route topology across all namespaces".
No NetworkPolicy manifests exist in the deploy/ directory. The default Kubernetes flat network model allows any pod to reach any service, further widening the attack surface.
| Endpoint | Data Exposed | Impact |
|----------|-------------|--------|
| GET /routes | All ingress/routegroup backends: internal service URLs, filter chains (auth, rate limiting, OAuth, JWT, OPA policies), load balancer group membership | Cluster-wide reconnaissance, targeted backend attacks |
| GET /routes/{zone} | Zone-scoped subset of above route data | Same, scoped |
| GET /swarm/redis/shards | Redis cluster internal IP:port pairs | Direct cache-level attacks, ratelimit data manipulation |
| GET /swarm/valkey/shards | Valkey cluster internal IP:port pairs | Same |
Additionally, the data-plane client (eskipfile/remote.go:190-219) also performs plain HTTP GET with no credentials — only an ETag header is sent — confirming that no auth capability exists in the architecture at all.
-route-server-filters=""Restrictive NetworkPolicies are a valid mitigation, but they are not an application-layer authentication mechanism. The security-relevant defect remains that routesrv serves control-plane-derived data to unauthenticated callers whenever network reachability exists.
This report does not rely on claiming direct integrity or availability impact. The verified issue is a confidentiality-focused control-plane exposure: route definitions, backend topology, filter-chain details, and Redis/Valkey shard addresses become readable to any reachable in-cluster client.
routesrv/routesrv.go:87-99 — handler registration (zero auth)routesrv/eskipbytes.go:134-196 — route data handler (no auth)routesrv/redishandler.go:28-41 — Redis shard handler (no auth)routesrv/valkeyhandler.go:28-41 — Valkey shard handler (no auth)dataclients/kubernetes/clusterclient.go:648-653 — fetchClusterState() — shows cluster-wide RBACeskipfile/remote.go:190-219 — data-plane client also has no auth capabilitydocs/tutorials/operations.md:108, docs/tutorials/ratelimit.md:137,197 — documented routesrv DNS nameA security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.