CVE-2023-39347
Cilium ≤ 1.12.14
Raw vector
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:HCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2023-39347 is a high-severity Insufficient Verification of Data Authenticity (CWE-345) vulnerability in Cilium Cilium. Its CVSS base score is 7.6 (High).
Operationally, ranked at the 46th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2023-2509
Vulnerability Data
Cilium is a networking, observability, and security solution with an eBPF-based dataplane. An attacker with the ability to update pod labels can cause Cilium to apply incorrect network policies. This issue arises due to the fact that on pod update,…
more
Cilium incorrectly uses user-provided pod labels to select the policies which apply to the workload in question. This can affect Cilium network policies that use the namespace, service account or cluster constructs to restrict traffic, Cilium clusterwide network policies that use Cilium namespace labels to select the Pod and Kubernetes network policies. Non-existent construct names can be provided, which bypass all network policies applicable to the construct. For example, providing a pod with a non-existent namespace as the value of the `io.kubernetes.pod.namespace` label results in none of the namespaced CiliumNetworkPolicies applying to the pod in question. This attack requires the attacker to have Kubernetes API Server access, as described in the Cilium Threat Model. This issue has been resolved in: Cilium versions 1.14.2, 1.13.7, and 1.12.14. Users are advised to upgrade. As a workaround an admission webhook can be used to prevent pod label updates to the `k8s:io.kubernetes.pod.namespace` and `io.cilium.k8s.policy.*` keys.
- CWE(s)
Related Threats
CVEs Like This One
Affected Assets
Mitigating Controls
Likely Mitigating Controls AI
Per-CVE control mapping for this CVE has not run yet; the list below is derived from the weakness types (CWEs) cited in the NVD entry.
Directly requires independent verification of matching output before adverse decisions, mitigating insufficient authenticity checks on data from external sources.
Use of approved PKI certificates provides verifiable data authenticity and origin for communications and artifacts.
Mandates provision of authenticity and integrity artifacts that enable verification of name/address resolution data.
Requires explicit verification of data authenticity from authoritative sources, preventing acceptance of unauthenticated resolution responses.
Control requires verification of data authenticity/integrity (e.g., checksums) after aggregation/packing, directly reducing exploitation of insufficient verification before transmission.
Time synchronization supports reliable freshness verification when checking data authenticity across systems or components.
Mandates verification of data authenticity for software, firmware, and information.
Provenance documentation and monitoring directly enables verification of authenticity for components and data throughout their history.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
A.8.24's guidance on identifying protection levels, selecting algorithms/strength for authenticity/integrity (items b,f), using cryptography for transmitted/stored data (c), and key management directly stops many CWE-345 exploits by ensuring verifiable authenticity; however, it leaves a bounded remainder where verification logic itself is flawed or absent (e.g. accepting unverified signatures or weak schemes), as the control depends on correct implementation in other mechanisms.
Secure SDLC incorporates authenticity verification requirements throughout development.
Application security requirements can mandate data authenticity verification mechanisms.
Secure coding practices include implementing proper data authenticity checks.
Security testing can detect missing or weak data authenticity verification.
Secure authentication of data sources ensures only valid, authentic data is accepted.
Hardening callouts derived
DISA STIG baselines are authored against specific weaknesses. Where this CVE cites a broad weakness class, the mapping is not asserted at that abstraction (owner ruling, 2026-09-25: grade only at Base and below), so no rule is shown here rather than a rule shown against the wrong grain.