CVE-2026-33726: 
Cilium vulnerability analysis and mitigation

CVE-2026-33726 is a network policy bypass vulnerability in Cilium, an eBPF-based Kubernetes networking and security solution, where Ingress Network Policies are not enforced for pod-to-pod traffic targeting L7 Services (Envoy, GAMMA) with a local backend on the same node. It affects all Cilium versions prior to 1.17.14, versions 1.18.0–1.18.7, and versions 1.19.0–1.19.1, and is triggered only when Per-Endpoint Routing is enabled and BPF Host Routing is disabled. The vulnerability was reported by @sudeephb and @Champ-Goblem, disclosed on March 24, 2026, and patched in versions 1.17.14, 1.18.8, and 1.19.2. The GitHub Advisory Database assigns a CVSS v3.1 score of 5.4 (Moderate), while the NVD/Feedly data reflects a base score of 4.3 (Medium) (GitHub Advisory, Cilium Advisory).

The root cause is improper access control (CWE-284) and incorrect authorization (CWE-863) in Cilium's eBPF datapath. The bug was introduced in commit d1d8e7a ("datapath: Add support for re-entering LXC egress path after L7 LB"), which enabled re-entry into the LXC egress path after L7 load balancer processing. When Per-Endpoint Routing (ENDPOINT_ROUTES) is enabled, packets destined for a local backend are handled directly in the cil_to_container path; returning CTX_ACT_OK at this point bypasses ingress policy checks entirely, as the packet never traverses the policy enforcement hook in bpf_host. The fix (PR #44693) hairpins the packet back to the cil_to_container ingress path so that ingress policies are correctly evaluated before delivery to the backend pod (Cilium PR #44693, GitHub Advisory).

Exploitation allows a pod on the same Kubernetes node to send traffic to L7 Services (Envoy or GAMMA) bypassing configured Ingress Network Policies, resulting in unauthorized access to services that should be restricted. The impact is limited to confidentiality (low) and integrity (low) — there is no availability impact — but the scope change means a compromised or malicious pod could reach services on the same node beyond its intended security boundary. This creates a risk of lateral movement within a cluster and potential data exfiltration from services that rely on Cilium network policies for access control, particularly in Amazon EKS with Cilium ENI mode, AlibabaCloud ENI, Azure IPAM, and some GKE deployments (GitHub Advisory, Cilium Advisory).

No public exploit code or in-the-wild exploitation has been reported for CVE-2026-33726. The EPSS score is approximately 0.006–0.011%, placing it in the 1st percentile for exploitation likelihood. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an attacker to have access to a pod on the same Kubernetes node as the target L7 Service backend, limiting the practical attack surface to insider threats or already-compromised workloads within the cluster (GitHub Advisory, Feedly).

1. Identify a vulnerable environment: Confirm the target Kubernetes cluster uses Cilium with Per-Endpoint Routing enabled (e.g., Amazon EKS with eni.enabled, AlibabaCloud ENI with alibabacloud.enabled, Azure IPAM with azure.enabled, or GKE with gke.enabled) and BPF Host Routing disabled, running Cilium versions prior to 1.17.14, 1.18.8, or 1.19.2.
2. Gain pod-level access: Obtain execution within a pod on the target node — either through a compromised workload, a misconfigured deployment, or legitimate access to a low-privilege pod.
3. Identify a co-located L7 Service backend: Enumerate services on the same node that use L7 proxying (Envoy or GAMMA), which would normally be restricted by Ingress Network Policies.
4. Send traffic directly to the L7 Service: Initiate connections from the attacker-controlled pod to the L7 Service's local backend. Due to the policy bypass, Cilium's eBPF datapath will deliver the traffic without enforcing the configured Ingress Network Policy.
5. Access restricted services: Interact with the target service as if no network policy restrictions exist, potentially reading sensitive data or performing unauthorized actions (GitHub Advisory, Cilium PR #44693).

• Network: Unexpected or unauthorized traffic flows between pods on the same Kubernetes node targeting L7 Services (Envoy/GAMMA backends) that should be blocked by Ingress Network Policies; connections that bypass expected policy drop logs.
• Logs: Absence of Cilium policy drop events (cilium monitor --type drop) for traffic that should be denied by Ingress Network Policy; Envoy access logs showing requests from source pods not permitted by policy.
• Cilium Metrics: Unexpected increase in allowed connections to L7 service endpoints on the same node without corresponding policy permit entries; review cilium policy get output against observed traffic in cilium monitor.

Upgrade Cilium to one of the patched versions: 1.17.14, 1.18.8, or 1.19.2, which contain the fix from PR #44693. There is no officially verified or comprehensive workaround; the only partial mitigation is to disable per-endpoint routes (--enable-endpoint-routes=false), but this will likely disrupt ongoing connections and may cause conflicts in cloud provider environments (EKS, AlibabaCloud, Azure, GKE). Organizations running Amazon EKS with Cilium ENI mode should treat this as the highest-priority upgrade target (GitHub Advisory, Cilium Advisory).

The vulnerability was coordinated between the Cilium community, Northflank, and Isovalent teams, with reporters @sudeephb and @Champ-Goblem credited for responsible disclosure. The fix was developed by @smagnani96 and reviewed by @julianwiedmann, with the patch merged on March 13, 2026, and the advisory published on March 24, 2026. Community reaction has been measured given the moderate severity and the requirement for same-node pod access; no significant media coverage or widespread social media discussion has been observed (Cilium Advisory).