CVE-2026-33726

What it actually does

CVE-2026-33726 is an authorization bypass in Cilium’s eBPF dataplane policy enforcement. In affected versions before 1.17.14, 1.18.8, and 1.19.2, Cilium may fail to enforce Ingress Network Policies for pod-to-service traffic targeting L7 Services such as Envoy or GAMMA when the service backend is local to the same node. The issue requires a specific configuration combination: Per-Endpoint Routing enabled and BPF Host Routing disabled. Per-Endpoint Routing is disabled by default, but is automatically enabled in several cloud IPAM modes, including Cilium ENI on Amazon EKS, AlibabaCloud ENI, Azure IPAM, and some GKE configurations. The result is that a pod that should be blocked by ingress policy may be able to connect to a protected L7 service if the backend is on the same node, potentially exposing service endpoints that operators expected to be isolated.

Why it matters to the business

Organizations using Cilium for Kubernetes network segmentation may have a gap in policy enforcement that allows workloads to communicate with services they are supposed to be denied from reaching. This can weaken tenant, namespace, or application isolation and may allow a compromised pod to access internal APIs, service gateways, or application paths protected primarily by Cilium ingress policies. The risk is most relevant to cloud Kubernetes deployments using cloud IPAM, especially Amazon EKS with Cilium ENI mode, and less relevant to tunneled or chaining deployments. The CVSS score is moderate and EPSS is currently low with no known KEV listing or ransomware association, but the operational impact can be significant where network policy is a key control boundary.

How an attack unfolds

An attacker first needs the ability to run code from a pod or compromise an existing pod in a Kubernetes cluster using an affected Cilium version and the vulnerable routing configuration. The attacker then identifies L7 Services backed by Envoy, GAMMA, or similar Cilium-managed service paths that are protected by ingress network policies. If the attacker’s source pod and the targeted backend pod are scheduled on the same node, and Per-Endpoint Routing is enabled while BPF Host Routing is disabled, traffic that should be denied may instead reach the service. The attacker can then interact with internal endpoints, APIs, or application routes that were intended to be unreachable from that workload. Exploitation does not require user interaction, but it is constrained to adjacent network access from inside the cluster and depends on node locality and Cilium configuration.

How to fix it

Upgrade Cilium to a patched release: 1.17.14, 1.18.8, 1.19.2, or any later fixed version in the applicable release branch. This is the primary recommended remediation. There is no officially verified comprehensive workaround. Disabling Per-Endpoint Routing may reduce exposure, but it can disrupt active connections and may conflict with cloud-provider IPAM requirements, so it should only be considered after careful testing and operational review. Prioritize upgrades for clusters using Cilium ENI on EKS, AlibabaCloud ENI, Azure IPAM, or GKE configurations where Per-Endpoint Routing is enabled. As defense in depth, ensure sensitive services enforce application-layer authentication and authorization rather than relying solely on network policy boundaries.

How to confirm the fix worked

Confirm the running Cilium version on every cluster and node, and verify it is 1.17.14, 1.18.8, 1.19.2, or later. Review Cilium Helm values, ConfigMaps, and agent arguments for Per-Endpoint Routing and BPF Host Routing settings. Validate whether cloud IPAM modes such as eni.enabled, alibabacloud.enabled, azure.enabled, or gke.enabled are in use. After upgrading, run a controlled network policy test: create or use a pod that should be denied by an ingress policy, target an L7 Service with a backend on the same node, and confirm the connection is blocked. Repeat the test across representative node pools and cloud IPAM configurations. Review Hubble, Cilium monitor, Envoy, and application access logs to confirm denied sources are no longer able to reach protected services.

Typical attack path

1. Gain execution in a Kubernetes pod or obtain permission to deploy a pod in a cluster using affected Cilium versions.
2. Identify that the cluster uses a vulnerable configuration, such as cloud IPAM with Per-Endpoint Routing enabled and BPF Host Routing disabled.
3. Discover internal L7 Services or service gateways protected by Cilium Ingress Network Policies.
4. Place or wait for the source pod to run on the same node as a local backend for the target service.
5. Send traffic from the source pod to the protected L7 Service.
6. Access service endpoints that should have been blocked by ingress policy enforcement.

How to detect it

To determine whether this was already exploited, focus on evidence of unauthorized service access rather than a unique exploit signature, because the flaw manifests as policy bypass in normal-looking pod-to-service traffic. Review Cilium Hubble flow logs, Cilium monitor output, Envoy access logs, Kubernetes audit logs, and application access logs for requests from pods, namespaces, or service accounts that should have been denied by ingress policy. Pay special attention to traffic where the source pod and destination backend were on the same node and the destination was an L7 Service using Envoy or GAMMA. Correlate allowed or forwarded flows against the intended CiliumNetworkPolicy or Kubernetes NetworkPolicy rules in effect at the time. Also review cluster configuration history for affected Cilium versions combined with Per-Endpoint Routing enabled and BPF Host Routing disabled. Kubernetes audit logs can help identify suspicious pod creation, exec, or deployment events that preceded unexpected access to protected services. Because there are no public threat actors or campaigns reported for this issue and it is not listed in KEV, detection should be based on policy-intent violations and anomalous internal service access rather than known malware indicators.

• eni.enabled=true
• alibabacloud.enabled=true
• azure.enabled=true
• gke.enabled=true
• enable-endpoint-routes: "true"
• enable-endpoint-routes=true
• bpf.hostRouting=false
• enable-host-routing: "false"
• cilium-agent
• hubble-relay
• hubble observe
• CiliumNetworkPolicy
• to-services
• Ingress

What your security team should do

• Inventory all Kubernetes clusters running Cilium and identify versions earlier than 1.17.14, 1.18.8, or 1.19.2.
• Prioritize remediation for clusters using cloud IPAM modes, especially Amazon EKS with Cilium ENI mode.
• Upgrade Cilium to a patched version rather than relying on configuration workarounds.
• Identify sensitive L7 Services protected by Cilium Ingress Network Policies and verify they also enforce application-layer authorization.
• Use Hubble, Envoy access logs, and application logs to hunt for traffic from pods or namespaces that should have been denied by network policy.
• Review recent pod deployments, compromised workload indicators, and unusual service access patterns on affected clusters.
• Avoid disabling Per-Endpoint Routing in production without testing because it may disrupt cloud networking behavior and active connections.
• Add regression tests for network policy enforcement against same-node service backends after Cilium upgrades or networking configuration changes.