Cilium is a widely used Kubernetes networking, observability, and security platform powered by eBPF. If you’re relying on network segmentation between namespaces, a critical vulnerability discovered in 2023—CVE-2023-41333—shows those assumptions might have been wrong unless you’ve patched recently.
With this post, I’ll explain in simple terms what went wrong, show you a code example of the exploit, link you to original references, and share mitigation details.
What is Cilium?
Cilium provides advanced networking and security capabilities for Kubernetes clusters, leveraging eBPF for performance and flexibility. Cilium lets you write policies (CiliumNetworkPolicy) to allow or deny traffic between pods, services, and namespaces.
The Vulnerability: Namespace Isolation Can Be Broken
CVE-2023-41333 is a flaw in how Cilium enforces network policies, specifically around the use of endpointSelector in CiliumNetworkPolicy objects.
An attacker, with permissions to create or modify CiliumNetworkPolicy objects in any namespace, can write a policy that uses the DoesNotExist operator with the reserved:init label. This allows the policy to match endpoints across all namespaces, not just the one it’s defined in.
This bypasses namespace boundaries, meaning a tenant in one Kubernetes namespace could impact or even control network access cluster-wide.
What’s Required for the Attack?
- API server access: The attacker must be able to create or modify CiliumNetworkPolicy objects. This typically means they have some permissions in the API server.
- No cluster admin needed—this could happen if a user or service account is compromised or too broadly permissioned.
*(Cilium itself documents this risk in its Threat Model.)*
The trick is to create a network policy with the following pattern in the endpointSelector
endpointSelector:
matchExpressions:
- key: "reserved:init"
operator: DoesNotExist
By using the DoesNotExist operator on this special reserved label, the policy unexpectedly matches endpoints across all namespaces, not just those in the current namespace.
Example Exploit Policy: Allow All Traffic Cluster-Wide
Suppose you’re an attacker in namespace dev. Here’s an example of a malicious policy that (depending on what’s in the egress/ingress section) could allow or block all traffic for the whole Cilium cluster:
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: evil-policy
namespace: dev
spec:
endpointSelector:
matchExpressions:
- key: "reserved:init"
operator: DoesNotExist
ingress:
- fromEndpoints:
- matchLabels: {} # Match everything
egress:
- toEndpoints:
- matchLabels: {} # Match everything
Effect:
Instead of affecting only pods in dev, this policy could allow or deny all ingress and egress globally on the cluster, depending on the rules inside.
Why Is This Bad?
- Breaks tenant isolation: Projects, teams, or businesses relying on Kubernetes namespaces for isolation could have traffic hijacked or blocked.
- Escalates access: A user with limited policy permissions in one namespace could control network access for other tenants.
Update immediately if you’re on an older version. Check your version
cilium version
Workaround: Admission Webhook
If you can’t upgrade right away, block risky policies at admission. You can write a simple Kubernetes validating webhook to reject any CiliumNetworkPolicy using the dangerous endpointSelector.
Example (pseudo-code for webhook logic)
def admit_policy(policy):
for expr in policy.spec.endpointSelector.get('matchExpressions', []):
if expr['key'] == 'reserved:init' and expr['operator'] == 'DoesNotExist':
return reject("Use of 'DoesNotExist' with 'reserved:init' is forbidden!")
return accept()
- See a real-world webhook here in the Cilium advisory.
References and Further Reading
- Cilium Security Advisory: GHSA-8fx6-gw7q-7qgg
- NVD Entry for CVE-2023-41333
- Cilium Threat Model
- Kubernetes Admission Webhooks
This vulnerability is a strong reminder that
- Kubernetes doesn’t always enforce perfect isolation across namespaces—especially with powerful CRDs and extensions like Cilium.
Admission control and quick patching are critical.
- Principle of Least Privilege: Never give tenants in shared clusters broad policy privileges without careful review.
Bottom line: If you’re running Cilium, update now. If you can’t, add a webhook to block this pattern, and audit who can create/modify network policies.
Timeline
Published on: 09/27/2023 15:19:00 UTC
Last modified on: 09/30/2023 02:01:00 UTC