CVE-2026-56743: 
Cilium vulnerability analysis and mitigation

CVE-2026-56743 is an incorrect authorization vulnerability in Cilium, a Kubernetes networking, observability, and security solution. Affecting versions 1.19.0 through 1.19.4, the flaw causes standard Kubernetes NetworkPolicy specifications using CIDR-based ipBlock rules (without pod or namespace selectors) to erroneously generate a wildcard namespace allow rule when Cilium is configured with a custom clusterName value other than the default any. This misconfiguration allows traffic from other workloads in the same namespace as the policy subject, bypassing intended network segmentation. The vulnerability was disclosed on July 15, 2026, and carries a CVSS v3.1 base score of 5.4 (Medium) (GitHub Advisory, Feedly).

The root cause is classified as CWE-863 (Incorrect Authorization). In the parseNetworkPolicyPeer function within pkg/k8s/network_policy.go, when a NetworkPolicyPeer contains only an IPBlock field (no PodSelector or NamespaceSelector), the parser failed to return early and instead incorrectly instantiated an empty podSelector on the selectorless peer definition. When the cluster is configured with a non-default clusterName, this empty pod selector triggers the addition of a cluster label, which Cilium then interprets as a wildcard namespace label selector — effectively allowing all traffic from workloads in the same namespace. The fix, implemented in PR #46305, adds an early nil return in parseNetworkPolicyPeer when both PodSelector and NamespaceSelector are nil, and also unifies ingress/egress peer parsing logic to eliminate the divergent code paths that enabled this regression (GitHub PR #46305, Commit bacea64).

Successful exploitation allows a low-privileged attacker on the adjacent network to send traffic that bypasses Kubernetes NetworkPolicy restrictions enforced by Cilium. Specifically, workloads in the same namespace as the policy subject can communicate with the protected pod even when such traffic should be blocked by CIDR-based ipBlock rules. The impact is limited to confidentiality and integrity (both rated Low), with no availability impact; however, the scope is changed, meaning the policy bypass can affect resources beyond the directly vulnerable component. This undermines namespace-level network segmentation in multi-tenant or security-sensitive Kubernetes environments (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The vulnerability is not automatable and requires low privileges on the adjacent network, limiting its reach. The EPSS score is approximately 0.00158 (very low probability of exploitation in the near term). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is further constrained by the requirement that the Cilium deployment must use a custom clusterName (not the default any value) and have affected NetworkPolicy configurations in place (GitHub Advisory).

1. Identify target cluster: Confirm the target Kubernetes cluster runs Cilium v1.19.0–v1.19.4 with a custom clusterName configured (not the default any value).
2. Identify vulnerable NetworkPolicies: Enumerate Kubernetes NetworkPolicy objects in the cluster that use CIDR-based ipBlock rules without any podSelector or namespaceSelector in the from/to peer definitions.
3. Position in the same namespace: Gain access to a workload (pod) running in the same namespace as the pod protected by the vulnerable NetworkPolicy — this requires low-privileged access to the adjacent network segment.
4. Send unauthorized traffic: Initiate network connections from the attacker-controlled workload to the protected pod. Due to the wildcard namespace allow rule erroneously generated by Cilium, this traffic will be permitted despite the ipBlock-only policy intending to restrict ingress to specific CIDRs.
5. Achieve policy bypass: Successfully communicate with the target pod, bypassing the intended CIDR-based network segmentation (GitHub Advisory, GitHub PR #46305).

• Network: Unexpected traffic flows between pods within the same namespace that should be restricted by ipBlock-only NetworkPolicies; connections originating from namespace-local workloads to pods that should only accept traffic from specific external CIDRs.
• Logs: Cilium policy audit logs or Hubble flow logs showing allowed ingress traffic from same-namespace pod IPs to pods protected by ipBlock-only NetworkPolicies; absence of expected policy drop events for intra-namespace traffic.
• Configuration: Cilium deployment configured with a non-default clusterName value (verifiable via cilium config or Helm values); presence of Kubernetes NetworkPolicy objects using ipBlock rules without podSelector or namespaceSelector in peer definitions.

Upgrade Cilium to version v1.19.5, which contains the fix for this vulnerability (GitHub Advisory, GitHub PR #46456). As a workaround without upgrading, operators can rewrite affected NetworkPolicies using CiliumNetworkPolicy with fromCIDR expressions instead of standard Kubernetes ipBlock rules, as CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy are not affected by this issue. Alternatively, clusters using the default clusterName value of any are not vulnerable and do not require immediate action. After patching, review all NetworkPolicy configurations to confirm ipBlock-only rules are correctly enforced, and audit Hubble flow logs for any unauthorized intra-namespace traffic that may have occurred during the exposure window.

The vulnerability was reported by community contributor @TheBeeZee, who also prepared the fix; the Cilium security team acknowledged the report and credited @fristonio and @odinuge for their assistance in reviewing the solution (GitHub Advisory). The fix was treated as a release blocker for the v1.19 branch and was fast-tracked through review and backport processes. No significant broader media coverage or social media discussion has been identified beyond standard vulnerability database aggregation.