CVE-2026-53935: 
Cilium vulnerability analysis and mitigation

CVE-2026-53935 is an incorrect authorization vulnerability in Cilium, a Kubernetes networking, observability, and security solution, that allows users with CiliumLocalRedirectPolicy (CLRP) creation privileges to hijack cluster service traffic across namespaces and corrupt internal service state. Affected versions include all Cilium releases prior to 1.17.16, versions 1.18.2 through 1.18.9, and versions 1.19.0 through 1.19.3. The vulnerability was published on July 6, 2026, with patches released in versions 1.17.16, 1.18.10, and 1.19.4. It carries a CVSS v3.1 base score of 6.9 (Medium/High) (GitHub Advisory).

The root cause is an incorrect authorization flaw (CWE-863) combined with improper URL redirection behavior (CWE-601) in Cilium's CiliumLocalRedirectPolicy controller. When a CLRP uses addressMatcher with an arbitrary ClusterIP, it installs a LocalRedirect pseudo-service at the same frontend and overwrites the ClusterIP entry in Cilium's service map — bypassing the namespace-scoping guarantees that serviceMatcher enforces. A secondary bug compounds the issue: when the LRP's backing pods are not yet Ready, the len(pods)==0 code path runs an unconditional DeleteFrontend that wipes the frontend before the override guard can inspect it, allowing the hijack to succeed silently once pods become ready. On policy deletion, the original ClusterIP is not restored (unlike serviceMatcher, which calls svcCache.EnsureService), leaving the affected Service with no service-map entry and breaking service translation entirely (GitHub Advisory, PR #45412, PR #45584).

A user with RBAC permission to create CiliumLocalRedirectPolicies in any namespace can redirect traffic destined for Kubernetes Services in other namespaces to attacker-controlled backends, enabling interception of sensitive inter-service communications (confidentiality impact). Deleting the malicious policy permanently corrupts Cilium's internal service state for the targeted Service, causing service translation to stop working and resulting in a denial of service for that Service — including critical cluster infrastructure such as cluster DNS (GitHub Advisory, PR #45412). The scope is changed, meaning the impact extends beyond the namespace of the attacker's policy to affect Services cluster-wide.

No public proof-of-concept exploit code or in-the-wild exploitation has been reported for this vulnerability. The EPSS score is approximately 0.34%, indicating a low probability of exploitation in the near term. The attack vector is Adjacent Network, requires High privileges (CLRP creation rights), and no user interaction, making it primarily a threat from malicious or compromised tenants within a multi-tenant Kubernetes cluster. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and NVD's SSVC assessment classifies exploitation as "none" (GitHub Advisory).

1. Obtain CLRP creation privileges: Gain RBAC permissions to create CiliumLocalRedirectPolicy resources in at least one namespace of the target Kubernetes cluster running a vulnerable Cilium version.
2. Identify target Service: Enumerate ClusterIP addresses of Services in other namespaces (e.g., kube-dns at 10.96.0.10) using standard Kubernetes API calls (kubectl get svc -A).
3. Craft malicious CLRP: Create a CiliumLocalRedirectPolicy in your namespace using addressMatcher specifying the target Service's ClusterIP and port, with redirectBackend pointing to attacker-controlled pods.
4. Trigger the override: Apply the policy while the redirect backend pods are not yet Ready. The len(pods)==0 code path will unconditionally delete the legitimate frontend. Once pods become Ready, the LocalRedirect entry silently takes ownership of the ClusterIP frontend.
5. Intercept traffic: Traffic from any pod in the cluster destined for the hijacked Service's ClusterIP is now redirected to the attacker's pods, enabling credential harvesting or data interception.
6. Cause denial of service (optional): Delete the malicious CLRP. Because the original ClusterIP entry is not restored, the legitimate Service loses its service-map entry and service translation breaks permanently for that Service until Cilium is restarted or the Service is recreated (GitHub Advisory, PR #45412, PR #45584).

• Kubernetes API Audit Logs: Unexpected CREATE or UPDATE events for CiliumLocalRedirectPolicy resources, especially from non-administrative service accounts or in namespaces that do not typically use LRP; audit entries where addressMatcher specifies a ClusterIP belonging to a Service in a different namespace.
• Cilium Agent Logs: Log entries indicating a LocalRedirect frontend being installed at an address matching an existing ClusterIP Service; absence of expected service-map entries for critical Services (e.g., kube-dns) after a CLRP deletion event.
• Network: Unexpected traffic flows from cluster pods to non-standard backend pods when communicating with well-known ClusterIP addresses; DNS resolution failures or timeouts cluster-wide following deletion of a suspicious CLRP.
• Kubernetes Resources: Presence of CiliumLocalRedirectPolicy objects with addressMatcher fields containing ClusterIPs of Services in other namespaces; CLRPs created by service accounts that do not have a legitimate operational need for redirect policies.

Upgrade Cilium to one of the patched versions: 1.17.16, 1.18.10, or 1.19.4. The fix adds a guard that prevents addressMatcher from overriding an existing Service's frontend in the service map; for v1.17, a temporary compatibility flag --enable-lrp-address-matcher-override=true is available to restore legacy behavior during migration, but this flag is not present in v1.18+ which always refuse such conflicts. There is no configuration-based workaround available for unpatched versions; the Cilium security advisory explicitly states no workaround exists. As a compensating control, administrators should audit and restrict RBAC permissions for CiliumLocalRedirectPolicy creation to only fully trusted, administrative service accounts (GitHub Advisory, PR #45412).

The fix was investigated and developed by Cilium community member @ysksuzuki (Yusuke Suzuki) from Isovalent, with the security advisory published by @ferozsalam. During the patch review process, Cilium maintainer @joestringer initially questioned whether the cross-namespace hijacking was intentional behavior given that LRP has historically been treated as a cluster-scoped resource, but the fix author clarified it was an unintentional bug — particularly because CLRP deletion could break cluster DNS, making the behavior dangerous even for cluster administrators (PR #45412). No significant broader media coverage or social media discussion has been identified beyond the GitHub advisory and patch PRs.