CVE-2026-24470: Skipper Ingress SSRF Vulnerability

CVE-2026-24470 Overview

Skipper, an HTTP router and reverse proxy for service composition developed by Zalando, contains a Server-Side Request Forgery (SSRF) vulnerability in versions prior to 0.24.0. When Skipper operates as a Kubernetes Ingress controller, users with permissions to create Ingress resources and Services of type ExternalName can craft routes that exploit Skipper's network access to reach internal services that should otherwise be inaccessible. This vulnerability affects the fundamental security boundary between external and internal network resources in Kubernetes environments.

Critical Impact

Attackers with limited Kubernetes RBAC permissions can leverage Skipper's privileged network position to access internal services, potentially exposing sensitive data, internal APIs, and backend systems not intended for external access.

Affected Products

• Skipper HTTP Router versions prior to 0.24.0
• Kubernetes deployments using Skipper as an Ingress controller with ExternalName services enabled
• Service mesh configurations where Skipper handles east-west traffic routing

Discovery Timeline

• 2026-01-26 - CVE-2026-24470 published to NVD
• 2026-01-27 - Last updated in NVD database

Technical Details for CVE-2026-24470

Vulnerability Analysis

This vulnerability is classified under CWE-441 (Unintended Proxy or Intermediary), which occurs when a product acts as an intermediary or proxy and performs requests on behalf of a client without sufficient validation that the requests are appropriate. The attack leverages Kubernetes ExternalName services, which provide a mechanism to alias external DNS names to internal service names. When Skipper processes Ingress rules pointing to ExternalName services, it follows the external reference using its own network context—which typically has elevated access to internal cluster resources and services.

The exploitation requires a threat actor with Kubernetes RBAC permissions to create both Ingress and Service objects. While these permissions are often granted to developers or deployment pipelines, they were not designed with the assumption that they could be weaponized to bypass network segmentation. The attacker creates an ExternalName service pointing to an internal target (such as internal-api.cluster.local or metadata services), then configures an Ingress to route traffic through Skipper to that service. Skipper, operating with its privileged network position, resolves and forwards requests to the internal target.

Root Cause

The root cause lies in Skipper's default configuration that allowed Kubernetes ExternalName services without restriction. The Kubernetes ExternalName service type was designed for legitimate use cases such as aliasing external databases or third-party services. However, when combined with an Ingress controller, it creates a proxy chain that can be abused for SSRF attacks. Skipper did not implement adequate validation or restrictions on ExternalName targets by default, trusting that Kubernetes RBAC would prevent malicious configurations.

Attack Vector

The attack is network-based and requires the attacker to have authenticated access to the Kubernetes API with permissions to create Ingress and Service resources. The attack flow involves:

1. Creating an ExternalName Service targeting an internal resource (e.g., kubernetes.default.svc, cloud provider metadata endpoints, or internal microservices)
2. Creating an Ingress resource that routes external traffic through Skipper to the ExternalName service
3. Sending HTTP requests through the Ingress that Skipper forwards to the internal target
4. Receiving responses from internal services that should not be externally accessible

// Security patch in config/config.go - disables kubernetes external name by default
// Source: https://github.com/zalando/skipper/commit/a4c87ce029a58eb8e1c2c1f93049194a39cf6219

 	KubernetesAnnotationPredicates                       []kubernetes.AnnotationPredicates  `yaml:"-"`
 	KubernetesAnnotationFiltersAppend                    []kubernetes.AnnotationFilters     `yaml:"-"`
 	KubernetesEastWestRangePredicates                    []*eskip.Predicate                 `yaml:"-"`
+	EnableKubernetesExternalNames                        bool                               `yaml:"enable-kubernetes-external-names"`
 	KubernetesOnlyAllowedExternalNames                   bool                               `yaml:"kubernetes-only-allowed-external-names"`
 	KubernetesAllowedExternalNames                       regexpListFlag                     `yaml:"kubernetes-allowed-external-names"`
 	KubernetesRedisServiceNamespace                      string                             `yaml:"kubernetes-redis-service-namespace"`

Source: GitHub Commit Update

Detection Methods for CVE-2026-24470

Indicators of Compromise

• Kubernetes Service objects of type ExternalName pointing to internal cluster DNS names, cloud metadata endpoints (e.g., 169.254.169.254), or unexpected internal IP addresses
• Ingress resources routing to ExternalName services created by non-administrative users
• Unusual traffic patterns from Skipper pods to internal services not typically accessed via Ingress
• Audit log entries showing creation of ExternalName services followed by Ingress configurations

Detection Strategies

• Enable Kubernetes audit logging and monitor for Service type ExternalName creations with internal targets
• Implement admission controllers (OPA Gatekeeper, Kyverno) to alert on or block suspicious ExternalName service configurations
• Monitor Skipper access logs for requests targeting internal service endpoints or metadata services
• Deploy network policies and monitor for violations from Skipper pods accessing unexpected destinations

Monitoring Recommendations

• Configure alerts for any new ExternalName Service objects created in production namespaces
• Implement network flow monitoring between Skipper ingress pods and internal services
• Review Skipper configuration regularly to ensure ExternalName services are disabled or properly allowlisted
• Monitor for reconnaissance patterns such as repeated requests to common internal endpoints through the Ingress

How to Mitigate CVE-2026-24470

Immediate Actions Required

• Upgrade Skipper to version 0.24.0 or later, which disables Kubernetes ExternalName services by default
• Audit existing ExternalName services in your cluster and remove any that are not explicitly required
• Implement Kubernetes NetworkPolicies to restrict Skipper's egress traffic to only expected backend services
• Review RBAC permissions and restrict Service and Ingress creation to trusted users and service accounts

Patch Information

The security fix was introduced in Skipper version 0.24.0. The patch adds a new configuration option EnableKubernetesExternalNames which defaults to false, effectively disabling the vulnerable behavior. Organizations requiring ExternalName functionality can re-enable it with proper allowlisting using the KubernetesOnlyAllowedExternalNames and KubernetesAllowedExternalNames configuration options. For detailed patch information, refer to the GitHub Security Advisory and the commit implementing the fix.

Workarounds

• If upgrading is not immediately possible, configure kubernetes-only-allowed-external-names: true and explicitly define safe targets using kubernetes-allowed-external-names with strict regular expressions
• Deploy Kubernetes admission controllers to block creation of ExternalName services cluster-wide or in sensitive namespaces
• Implement NetworkPolicies that restrict Skipper pod egress to only approved backend service IP ranges
• Use Kubernetes RBAC to revoke Service creation permissions from untrusted users and service accounts

# Skipper configuration to restrict ExternalName services
# Add to skipper deployment arguments or config file

# Option 1: Disable ExternalName entirely (recommended for versions < 0.24.0)
skipper \
  -kubernetes-only-allowed-external-names=true \
  -kubernetes-allowed-external-names=""

# Option 2: Allowlist specific safe external targets
skipper \
  -kubernetes-only-allowed-external-names=true \
  -kubernetes-allowed-external-names="^external-db\.example\.com$" \
  -kubernetes-allowed-external-names="^api\.trusted-partner\.com$"