CVE-2026-53935

What it actually does

The flaw allows a Kubernetes principal that already has permission to create CiliumLocalRedirectPolicy resources to bypass intended namespace scoping. By using addressMatcher, the principal can specify arbitrary Service ClusterIP addresses, including Services in other namespaces, instead of being constrained by serviceMatcher namespace rules. This can redirect or hijack traffic intended for those Services. Separately, deleting a malicious or malformed policy can corrupt Cilium internal service state, causing service translation to stop for the affected Service and creating a denial-of-service condition. The issue affects Cilium versions prior to 1.17.16, 1.18.2 through 1.18.9, and 1.19.0 through 1.19.3, and is fixed in 1.17.16, 1.18.10, and 1.19.4.

Why it matters to the business

An attacker or over-privileged workload operator inside a cluster could redirect traffic meant for applications in other namespaces, potentially exposing sensitive service traffic, breaking application communication, or causing outages for affected Services. Because Cilium is often part of the cluster networking and security control plane, exploitation can have broad operational impact even though the attacker needs elevated Kubernetes permissions. The CVSS score is moderate-high, EPSS is currently low, it is not listed in CISA KEV, and no public exploit maturity is reported, so remediation should be prioritized for clusters where CiliumLocalRedirectPolicy creation is delegated beyond tightly trusted administrators.

How an attack unfolds

An attacker first obtains Kubernetes credentials or workload permissions that allow creating CiliumLocalRedirectPolicy resources. Instead of using serviceMatcher as intended, the attacker defines a policy using addressMatcher and provides the ClusterIP of a target Service, including a Service in another namespace. Cilium accepts the policy and applies local redirect behavior to traffic for that ClusterIP, allowing the attacker to steer traffic toward an attacker-controlled backend or otherwise interfere with normal service routing. If the attacker later deletes the policy, the deletion path can corrupt Cilium internal service state, causing service translation for the affected Service to fail and resulting in application connectivity loss. Exploitation is most plausible from a malicious insider, compromised CI/CD identity, compromised operator account, or tenant with overly broad custom-resource permissions in a shared cluster.

How to fix it

Upgrade Cilium to a fixed release: 1.17.16 for the 1.17 branch, 1.18.10 for the 1.18 branch, or 1.19.4 for the 1.19 branch. If immediate upgrade is not possible, restrict RBAC permissions for CiliumLocalRedirectPolicy creation, update, patch, and deletion to a minimal set of highly trusted administrators or automation identities. Audit and remove any unnecessary permissions granted on ciliumlocalredirectpolicies resources. Review existing CiliumLocalRedirectPolicy objects for addressMatcher usage that references ClusterIPs outside the policy namespace or outside explicitly approved service ownership boundaries. Consider temporarily disabling or tightly controlling use of CiliumLocalRedirectPolicy in multi-tenant clusters until all nodes run a fixed Cilium version.

How to confirm the fix worked

Confirm the running Cilium version on every cluster and node is 1.17.16, 1.18.10, 1.19.4, or later, depending on the deployed branch. Verify Kubernetes RBAC no longer grants broad create, update, patch, or delete permissions on CiliumLocalRedirectPolicy resources. Enumerate all CiliumLocalRedirectPolicy objects and check whether any use addressMatcher with ClusterIP values belonging to Services in another namespace or to Services that are not explicitly approved for local redirect. After upgrade, test normal Service connectivity and confirm Cilium service translation remains healthy after creating and deleting legitimate redirect policies in a controlled environment. Review Cilium agent health, service maps, and kube-proxy replacement status where applicable.

Typical attack path

1. Gain access to a Kubernetes identity with permission to create CiliumLocalRedirectPolicy resources.
2. Enumerate Services and ClusterIP addresses, including Services outside the attacker's namespace.
3. Create a CiliumLocalRedirectPolicy that uses addressMatcher to target an arbitrary ClusterIP rather than relying on namespace-scoped serviceMatcher behavior.
4. Redirect or hijack traffic intended for the selected Service to attacker-controlled or unintended local endpoints.
5. Optionally delete the policy, triggering Cilium internal service-state corruption and disrupting service translation for the affected Service.
6. Use the redirected traffic or resulting outage to exfiltrate data, degrade service availability, or support further lateral movement.

How to detect it

To determine whether this was already exploited, review Kubernetes audit logs for create, update, patch, and delete operations on CiliumLocalRedirectPolicy resources. Focus on events where requestObject includes addressMatcher, especially if the specified IP matches the ClusterIP of a Service in a different namespace or a sensitive namespace. Correlate those events with Cilium agent logs showing policy reconciliation, local redirect policy changes, service translation errors, service map changes, or endpoint regeneration around the same time. Build a timeline of any CiliumLocalRedirectPolicy deletion events followed by application connection failures, DNS/service reachability incidents, or Cilium service lookup/translation errors. Review existing policies in the cluster for unexpected addressMatcher entries and compare the creating user, service account, source IP, and user agent from audit logs against expected platform automation. Because exploitation requires legitimate Kubernetes permissions and may not leave malware-like artifacts, the strongest evidence is an unauthorized or anomalous CiliumLocalRedirectPolicy referencing an arbitrary ClusterIP, followed by redirected traffic or service translation disruption.

• CiliumLocalRedirectPolicy
• ciliumlocalredirectpolicies
• addressMatcher
• serviceMatcher
• requestObject.spec.redirectFrontend.addressMatcher
• verb=create objectRef.resource=ciliumlocalredirectpolicies
• verb=update objectRef.resource=ciliumlocalredirectpolicies
• verb=patch objectRef.resource=ciliumlocalredirectpolicies
• verb=delete objectRef.resource=ciliumlocalredirectpolicies
• cilium.io/v2 CiliumLocalRedirectPolicy
• LocalRedirectPolicy
• local redirect policy
• service translation
• ClusterIP

What your security team should do

• Upgrade affected Cilium deployments to 1.17.16, 1.18.10, 1.19.4, or later as the primary fix.
• Immediately audit Kubernetes RBAC for principals with create, update, patch, or delete access to CiliumLocalRedirectPolicy resources and remove unnecessary grants.
• Hunt Kubernetes audit logs for recent CiliumLocalRedirectPolicy create, update, patch, or delete events, especially those using addressMatcher.
• Compare addressMatcher IPs in existing policies against the Service ClusterIP inventory and flag references to Services in other namespaces or unexpected application boundaries.
• Investigate any service outages, service translation failures, or sudden traffic path changes following CiliumLocalRedirectPolicy deletion events.
• Add admission-control policy to block or require approval for CiliumLocalRedirectPolicy objects that specify arbitrary addressMatcher ClusterIPs.
• Increase monitoring on shared or multi-tenant clusters where non-platform teams have permissions over Cilium custom resources.