CVE-2026-53935: Cilium CiliumLocalRedirectPolicy Namespace Isolation Bypass

Technical summary

The vulnerability stems from insufficient input validation in CiliumLocalRedirectPolicy's addressMatcher field. While the serviceMatcher parameter correctly restricts policies to services within the same namespace, the addressMatcher field permits arbitrary ClusterIP specification without equivalent namespace scoping. This allows a policy creator to intercept traffic destined for Services across namespace boundaries by matching on their ClusterIP directly. Additionally, policy deletion can trigger corruption of Cilium's in-memory service translation tables, causing the affected Service to become unreachable even after the malicious policy is removed. The root cause is classified under CWE-863 (Incorrect Authorization), reflecting the breakdown in access control enforcement.

Business impact

For multi-tenant Kubernetes clusters, this vulnerability undermines namespace isolation—a fundamental security boundary. Attackers or compromised applications within a namespace can intercept sensitive traffic destined for services in other namespaces, potentially exposing API calls, database connections, or inter-service credentials. The secondary effect of service-state corruption can trigger operational outages, requiring cluster operator intervention and restart of affected components to restore service translation. Organizations relying on namespace-based RBAC policies for tenant separation should treat this as a control-plane integrity issue.

Affected systems

Cilium versions prior to 1.17.16, from 1.18.2 through 1.18.9, and from 1.19.0 through 1.19.3 are vulnerable. Patched versions are 1.17.16, 1.18.10, and 1.19.4 and later. The vulnerability only affects clusters where at least one user or service account has permissions to create CiliumLocalRedirectPolicies; however, in many deployments, cluster operators or platform-engineering teams hold these permissions, expanding the attack surface.

Exploitability

Exploitation requires prior access to create CiliumLocalRedirectPolicy resources within the cluster, typically granted to cluster administrators or platform teams. The attack surface is not remote or unauthenticated—it requires an authenticated principal with RBAC permissions. However, the attack is straightforward once access exists: an attacker simply creates a policy with an addressMatcher targeting any ClusterIP and lets traffic flow through the redirect. This is not listed on CISA's Known Exploited Vulnerabilities catalog, suggesting limited public exploitation to date, though the ease of exploitation means defenders should not rely on low threat-in-the-wild as assurance.

Remediation

Upgrade to patched versions: 1.17.16, 1.18.10, 1.19.4, or any version 1.20 and later. For organizations unable to patch immediately, apply restrictive RBAC policies to limit CiliumLocalRedirectPolicy creation to only highly trusted principals and regularly audit existing policies. Monitor cluster logs and Cilium agent metrics for unusual redirect policies or service translation failures. Ensure namespace isolation is validated post-patching via network policy testing.

Patch guidance

Plan upgrades in a phased manner, testing in staging clusters first, as Cilium upgrades may require brief network-plane restarts. Verify patch versions against Cilium's official release notes to confirm the specific version you deploy contains the fix. After upgrade, confirm service-to-service connectivity across namespaces and review any existing CiliumLocalRedirectPolicies to identify and remove any suspicious entries. Cilium provides vendor advisories with detailed upgrade procedures; consult those for your specific deployment topology (e.g., kubeadm, Helm, managed services).

Detection guidance

Audit existing CiliumLocalRedirectPolicies for addressMatcher values that reference ClusterIPs outside the policy creator's namespace using kubectl get ciliumlocalredirectpolicies -A and inspecting the addressMatcher field. Enable Cilium's audit logging to detect policy creation events. Monitor Cilium agent logs for entries indicating service-state corruption or translation failures, typically logged as warnings or errors in the cilium-agent pods. On older versions, look for any CiliumLocalRedirectPolicy where the Service referenced in serviceMatcher and the ClusterIP in addressMatcher belong to different namespaces—this is a red flag.

Why prioritize this

Although the CVSS score is moderate (6.9 MEDIUM), the vulnerability breaks a fundamental security boundary in multi-tenant clusters. Namespace isolation is a primary trust assumption in Kubernetes security posture; any compromise of that boundary warrants prompt attention. The high-privilege requirement (administrators with policy-creation rights) limits broad blast radius, but many organizations grant these permissions liberally. The corrupted-state side effect creates operational risk. Prioritize patching for clusters with untrusted or semi-trusted users and for those enforcing compliance frameworks (e.g., SOC 2, PCI) that depend on namespace-level isolation.

Risk score, explained

The CVSS 3.1 score of 6.9 reflects a MEDIUM severity: the vulnerability requires administrative or high-privileged access (PR:H) and runs within an adjacent network context (AV:A), limiting immediate remote threat. However, it achieves scope change (S:C) by breaking namespace boundaries and causes availability impact (A:H) through state corruption. The integrity impact (I) is marked none, as the vulnerability does not modify data in transit but does redirect it, a distinction reflected in the scoring. Organizations with strong RBAC discipline may face lower residual risk; those with permissive policy-creation grants should elevate concern accordingly.

Frequently asked questions