CVE-2023-39347

Executive Summary

CVE-2023-39347 is a network policy bypass vulnerability in Cilium, an eBPF-based networking, observability, and security solution widely deployed in Kubernetes environments. An attacker with the ability to update pod labels — requiring Kubernetes API Server access — can cause Cilium to apply incorrect network policies, rendering existing policy enforcement ineffective. The vulnerability affects all Cilium versions prior to 1.12.14, 1.13.7, and 1.14.2, and can lead to unauthorized network access between workloads, lateral movement, and data exfiltration within a cluster. The vulnerability has a CVSS score of 7.6 (High) and is not currently listed on the CISA Known Exploited Vulnerabilities (KEV) catalog.

Technical Analysis

The root cause of CVE-2023-39347 lies in Cilium's policy selection logic during pod updates. When a pod is updated in the Kubernetes cluster, Cilium's agent components process the update event and recompute the set of network policies that apply to that workload. The flaw is that Cilium incorrectly uses the user-provided pod labels — rather than the authoritative state stored in the Kubernetes API — to select which policies apply to the workload.

Specifically, Cilium relies on Kubernetes identity labels to associate a pod with namespaces, service accounts, and other constructs. On the initial pod creation, the kubelet and API server populate these labels correctly. However, on pod update, Cilium reads the labels directly from the pod object as supplied by the user (or an attacker with API access) without validating that they match the authoritative source. This allows an attacker to manipulate the following label keys:

• io.kubernetes.pod.namespace — used to associate a pod with its namespace
• io.cilium.k8s.policy.* — used to associate a pod with Cilium policy constructs (service accounts, clusters)

By supplying a non-existent namespace name as the value of io.kubernetes.pod.namespace, the pod is effectively excluded from all namespaced CiliumNetworkPolicies that would otherwise apply. Similarly, by providing non-existent service account or cluster names, the pod bypasses CiliumClusterwideNetworkPolicies that use those constructs to select pods, and Kubernetes NetworkPolicies that rely on namespace labels.

The attack surface includes:

1. CiliumNetworkPolicies that use namespace, service account, or cluster constructs to restrict traffic
2. CiliumClusterwideNetworkPolicies that use Cilium namespace labels for pod selection
3. Kubernetes NetworkPolicies

The vulnerability is triggered entirely within the control plane — no eBPF programs are modified, and no network-level exploitation is required. The attack requires the ability to update pod label fields, which is granted to users with pods/update permission in RBAC. In a typical environment, this includes users with edit or admin roles, but could also include compromised pods with service account tokens granting broader Kubernetes API permissions.

The impact is a complete bypass of network segmentation policies. A compromised workload can gain unrestricted network access to other namespaces, bypassing all intended restrictions. This defeats the core security purpose of the Cilium policy engine.

Exploitation Scenarios

No public exploit code or PoC is available at the time of writing. The attack chain is inferred from the NVD description and vulnerability class.

Step 1 — Reconnaissance/Target Identification The attacker must first obtain Kubernetes API Server access with permission to update pod labels. This can be achieved through:

• Compromising a service account with pods/update RBAC permissions
• Exploiting another application vulnerability to obtain API credentials
• Legitimate access as an operator or developer with broad permissions

The attacker identifies target pods running sensitive services (databases, internal APIs, admin panels) and maps the existing network policies to understand which restrictions apply.

Step 2 — Flaw Class Trigger The attacker submits a PATCH or PUT request to the Kubernetes API server to update the target pod's labels. The malicious payload includes modified values for label keys such as:

• io.kubernetes.pod.namespace set to a non-existent namespace (e.g., a random string)
• io.cilium.k8s.policy.serviceaccount set to a non-existent service account name
• io.cilium.k8s.policy.cluster set to a non-existent cluster name

The attack is successful because Cilium trusts these user-supplied labels over authoritative API data when recomputing policy mappings.

Step 3 — Payload/Execution Method The label update itself is the payload — no code execution or network-based exploit is required. The Kubernetes API accepts the update (the attacker has legitimate write permission), and Cilium's agent picks up the update event from the API watch stream. During policy recomputation, Cilium looks up policies matching the modified label values and finds none (since the construct names do not exist), so no namespaced policies are applied. The pod becomes effectively "policy-less."

Step 4 — Post-Exploitation Impact Once the pod is exempt from network policy enforcement, the attacker can:

• Initiate network connections to pods in other namespaces that were previously blocked
• Access internal services that should be isolated (databases, internal APIs, management interfaces)
• Perform lateral movement across the cluster
• Exfiltrate data from protected services
• Pivot to additional compromised workloads

The attack can be repeated on multiple pods, effectively dismantling the cluster's entire segmentation strategy.

Impact Assessment

The business impact of CVE-2023-39347 is severe for organizations relying on Cilium for network policy enforcement in multi-tenant Kubernetes clusters.

CVSS Breakdown (Score: 7.6, High):

• Attack Vector: Network (AV:N) — attack is delivered via Kubernetes API
• Attack Complexity: Low (AC:L) — straightforward label update
• Privileges Required: High (PR:H) — requires pods/update permission
• User Interaction: None (UI:N)
• Scope: Changed (S:C) — vulnerability in Cilium impacts the broader cluster network
• Confidentiality Impact: High (C:H) — unauthorized data access
• Integrity Impact: High (I:H) — policy state can be manipulated
• Availability Impact: None (A:N)

Affected Systems:

• All Cilium deployments with network policy enforcement enabled, versions < 1.12.14, 1.13.0-1.13.7, 1.14.0-1.14.2
• Multi-tenant clusters where namespace isolation is a security boundary
• Clusters enforcing compliance requirements (PCI-DSS, SOC2) through network segmentation

Blast Radius:

• Compromise of one pod's service account leads to cluster-wide policy bypass
• All namespaced and clusterwide network policies are suspect once exploited
• Downstream impact includes data breach, ransomware, and supply-chain compromise in CI/CD environments

Note that EPSS indicates a low immediate exploitation probability (0.00460; 37.7th percentile), but this is a privilege-escalation-style flaw that becomes highly valuable once any pod compromise occurs.

Detection Guidance

The following detection rules focus on Kubernetes API audit logs, as the exploitation occurs entirely within the control plane. No network-level indicator exists for this attack.

Sigma Rule

title: Cilium Pod Label Manipulation for Policy Bypass
id: c649e3e4-3c3e-4b8c-92ce-0fe9a1f6a350
status: experimental
description: Detects pod label updates targeting Cilium policy labels, indicating attempted network policy bypass
logsource:
    product: kubernetes
    service: audit
detection:
    selection:
        verb: [UPDATE, PATCH]
        objectRef.resource: pods
    condition: selection and filter_labels
filter_labels:
    - Any pod label key matching 'io.kubernetes.pod.namespace' with a value different from the pod's actual namespace
    - Any pod label key matching 'io.cilium.k8s.policy.*'
    - Label update containing 'k8s:io.kubernetes.pod.namespace'
level: high
falsepositives:
    - Legitimate namespace migration or relabeling operations
    - Cluster administrators making intended policy changes
tags:
    - attack.t1548
    - cve.2023-39347

YARA Rule

rule Cilium_Pod_Label_Policy_Bypass
{
    meta:
        author = "Valter Security"
        description = "Detects Kubernetes pod definitions with Cilium policy label manipulation"
        cve = "CVE-2023-39347"
        date = "2024-01-15"
        score = 70
    strings:
        $ns_label = "io.kubernetes.pod.namespace"
        $cilium_sa = "io.cilium.k8s.policy.serviceaccount"
        $cilium_cluster = "io.cilium.k8s.policy.cluster"
        $cilium_ns = "io.cilium.k8s.policy.namespace"
        $k8s_ns = "k8s:io.kubernetes.pod.namespace"
    condition:
        any of ($cilium*) and (any of ($ns_label, $k8s_ns))
}

Suricata IDS Rule

# Note: This vulnerability is control-plane-only (Kubernetes API).
# Network detection is limited to Kubernetes API traffic with malformed pod updates.
# This rule flags anomalous API requests to pod update endpoints.

alert http any any -> $KUBERNETES_API_SERVERS any (msg:"Cilium Pod Label Policy Bypass Attempt"; flow:to_server,established; content:"PATCH"; http_method; content:"/api/v1/namespaces/"; http_uri; content:"/pods/"; http_uri; content:"io.kubernetes.pod.namespace"; http_client_body; content:"metadata"; http_client_body; content:"labels"; http_client_body; reference:cve,2023-39347; classtype:attempted-admin; sid:50090001; rev:1;)

Elastic Detection

sequence by user.name, source.ip
  with maxspan = 5m
  [any where event.action in ("UPDATE", "PATCH") and event.dataset == "kubernetes.audit_logs" and
   kubernetes.audit.objectRef.resource == "pods" and
   kubernetes.audit.requestObject.metadata.labels contains "io.kubernetes.pod.namespace"]

Note: This EQL rule requires Kubernetes audit logs to be shipped to Elasticsearch. Adjust field names to match your ingestion pipeline.

Splunk SPL Query

index=kubernetes sourcetype=kube:audit
  (action=UPDATE OR action=PATCH)
  AND objectRef.resource=pods
  AND (requestObject.metadata.labels{}.io.kubernetes.pod.namespace=*
       OR requestObject.metadata.labels{}.io.cilium.k8s.policy.*=*)
  | eval actual_namespace=mvindex(split(objectRef.name, "-"), 0)
  | where requestObject.metadata.labels{"io.kubernetes.pod.namespace"} != actual_namespace
  | stats count by user.username, sourceIPs{}, objectRef.name, requestObject.metadata.labels{}

Wazuh OSSEC Rule

<group name="kubernetes,">
  <rule id="100803" level="12">
    <decoded_as>json</decoded_as>
    <field name="verb">UPDATE|PATCH</field>
    <field name="objectRef.resource">pods</field>
    <regex>io\.kubernetes\.pod\.namespace|io\.cilium\.k8s\.policy</regex>
    <description>Cilium pod label manipulation detected - possible network policy bypass (CVE-2023-39347)</description>
    <group>cilium_cve_2023_39347</group>
    <mitre><id>T1548</id></mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 2/4 (CLAIMED) — the CNA (Cilium) has claimed the fix in versions 1.14.2, 1.13.7, and 1.12.14. This is a single-source claim and has not been independently confirmed by third-party testing at this time. You should verify the fix after upgrading by testing label-update scenarios.

1) Immediate Mitigations (before patching):

• Deploy an admission webhook (e.g., Kyverno or OPA Gatekeeper) that rejects pod update requests containing modifications to the k8s:io.kubernetes.pod.namespace and io.cilium.k8s.policy.* label keys
• Restrict pods/update permissions in RBAC to only the minimum set of service accounts and users that require it
• Audit all service accounts currently holding pods/update or pods/patch permissions — revoke unnecessary grants
• Enable Kubernetes audit logging and alert on any pod label modification events

2) Patch/Upgrade Steps:

• Upgrade Cilium to version 1.14.2 (latest stable branch) for production clusters
• Upgrade to 1.13.7 for clusters on the 1.13 release train
• Upgrade to 1.12.14 for clusters still on 1.12.x
• Test the upgrade in a staging environment first, validating that network policies are correctly applied after the upgrade
• After upgrade, verify the fix by attempting a label update on a test pod and confirming that namespace policies remain enforced

3) Long-term Hardening:

• Implement the principle of least privilege for Kubernetes RBAC; review pods/update and pods/patch grants quarterly
• Add admission webhooks to prevent unauthorized label mutations on io.kubernetes.pod.namespace and io.cilium.k8s.policy.* keys even after patching
• Enable the Kubernetes NodeRestriction admission controller to limit kubelet label modifications
• Deploy policy-as-code rules to reconcile pod labels against authoritative sources (APIServer, metadata)
• Use network policy monitoring tools to continuously validate policy coverage and detect "policy-less" pods
• Subscribe to Cilium security advisories for future CVE notifications

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2023-39347
2. Cilium Security Advisory: https://github.com/cilium/cilium/security/advisories (related advisory for 2023-39347)
3. Cilium GitHub Security Releases: https://github.com/cilium/cilium/releases (v1.14.2, v1.13.7, v1.12.14)
4. Cilium Threat Model documentation: https://docs.cilium.io/en/stable/security/threat-model/
5. CISA KEV Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2023-39347 not listed — no known in-the-wild exploitation reported as of this report date)

Threat actor campaigns: No campaigns specifically leveraging CVE-2023-39347 have been identified publicly. The EPSS score (0.00460) indicates low current exploitation likelihood, but the attack requires only a modest privilege level and would significantly amplify the impact of any pod compromise, making it attractive to APT groups targeting Kubernetes environments.