CVE-2023-39347 - How Manipulating Pod Labels in Cilium Can Bypass Network Policies

Cilium has become a core building block for cloud native networking, observability, and security, powered by eBPF. Many Kubernetes clusters use Cilium to apply fine-grained network policies, isolate workloads, and visualize traffic. But a recently disclosed vulnerability, CVE-2023-39347, threatens the security boundaries provided by Cilium—especially if you have users or processes with the ability to update pod labels.

In this post, we'll break down how this CVE works, what the real risk is, and what you should do right now. We include a minimal example of how the bug can be exploited, plus actionable mitigation steps.

What is CVE-2023-39347?

CVE-2023-39347 is a vulnerability in Cilium that lets an attacker manipulate a pod’s labels in a specific way to bypass network policies. Basically, if you can update the labels on your pod, you can confuse Cilium into making the pod "invisible" to certain Cilium or Kubernetes network policies—including ones that are supposed to restrict traffic using the pod's namespace, service account, cluster, or other constructs.

> The root cause is that, on pod updates, Cilium trusted *user-provided* labels—such as the pod's namespace label (io.kubernetes.pod.namespace)—to determine which policies applied. If you give a pod a label that names a non-existent namespace, Cilium will literally ignore all policies that are supposed to apply to that namespace for your pod.

If you have the ability to change labels via the Kubernetes API (as described in Cilium's Threat Model), you can exploit this bug.

You allow pods’ labels to be updated by users or controllers outside your trust boundary.

3. You use Cilium or Kubernetes network policies with selectors based on namespace, service account, or similar constructs.

Exploiting CVE-2023-39347: A Simple Scenario

Let’s say you have a network policy that only allows pods in the dev namespace to communicate with a sensitive database.

The expected (secure) behavior:

Cilium uses this user-provided label to filter the applicable policies.

3. Because there are no policies referencing the namespace "nonexistent", all the real network policies are ignored for that pod!

Here’s a minimal curl example using the Kubernetes API to exploit this

# Current pod info
kubectl get pod attacker-pod -n dev -o yaml

# Patch the pod's namespace label to a non-existent value
kubectl patch pod attacker-pod -n dev \
  --type='merge' \
  -p '{"metadata":{"labels":{"io.kubernetes.pod.namespace":"bypasser"}}}'

You could also do this via the Kubernetes API directly with a JSON Patch.

What’s the Result?

- The pod attacker-pod in the dev namespace “claims” to be in namespace bypasser as far as Cilium is concerned.
- Any CiliumNetworkPolicy or K8s NetworkPolicy that uses namespace selectors will not match this pod.

All protections are gone!

> In short: By spoofing the pod’s namespace label, an attacker can opt-out of all namespace-scoped policies.

References

- Security Advisory: CVE-2023-39347
- Cilium Threat Model
- Upstream Issue

1.12.14

> Upgrade immediately if you’re on an affected version.

Workarounds

If you can’t upgrade right now, you can prevent exploitation by blocking changes to sensitive pod labels. Use a Kubernetes admission webhook to reject modifications to labels like:

Example: Admission Webhook Policy

You can use Kyverno or OPA Gatekeeper to do this.

Kyverno Example Policy

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-namespace-label-patch
spec:
  rules:
    - name: block-manipulation-of-pod-namespace-label
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Updating io.kubernetes.pod.namespace is forbidden"
        pattern:
          metadata:
            labels:
              # Deny updates to this label.
              "io.kubernetes.pod.namespace": "?*"

This will block changes to the sensitive label, closing the exploit avenue.

Control pod label updates. Never allow untrusted users or workflows to change critical labels.

- Review your Cilium/network policies. If you use namespace-based selectors, you’re at higher risk.

In Summary

CVE-2023-39347 shows that even well-architected cloud-native tools like Cilium can have subtle trust boundary issues. By learning about how user input can be misused—especially in critical selectors or labels—you can better secure your Kubernetes deployments.

If you're using Cilium, upgrade now, or implement the suggested workarounds. For defenders: watch audit logs for suspicious pod label changes targeting io.kubernetes.pod.namespace or related labels.

Stay safe, and keep your clusters patched!

Further reading:
- Full Standup Disclosure on GitHub
- Cilium Documentation: Network Policy
- Kubernetes: Admission Controllers

Timeline

Published on: 09/27/2023 15:18:00 UTC
Last modified on: 09/29/2023 15:54:00 UTC