CVE-2025-30163
Executive Summary
CVE-2025-30163 is a medium-severity vulnerability in Cilium, an eBPF-based networking, observability, and security solution. The flaw resides in the implementation of node-based network policies (fromNodes and toNodes). When these policies are enabled, they incorrectly permit traffic to and from non-node endpoints that share the same labels specified in the policy. This bypasses the intended access control, potentially allowing unauthorized network flows. The vulnerability affects Cilium versions v1.16.0 through v1.16.7 and v1.17.0 through v1.17.1. Patches are available in v1.16.8 and v1.17.2. Node-based network policy is disabled by default, limiting the attack surface. The EPSS score is 0.0%, indicating low exploitation likelihood at this time.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
Cilium is distributed as a container image and via package managers for Kubernetes environments. The vulnerability is in the core Cilium agent binary, which is part of the official Cilium container images. Users should verify they are not using affected versions from Docker Hub, Quay.io, or other registries. The fix is included in the official Cilium releases v1.16.8 and v1.17.2. No malicious packages have been reported in relation to this CVE.
CVSS Breakdown & Threat Level
CVSS Score: 3.4 (Low) Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
- Attack Vector (AV): Network – The vulnerability can be exploited remotely over the network.
- Attack Complexity (AC): Low – No special conditions are required for exploitation.
- Privileges Required (PR): None – No authentication needed.
- User Interaction (UI): None – No user action required.
- Scope (S): Unchanged – The exploit cannot affect resources beyond the vulnerable component.
- Confidentiality (C): Low – Limited information disclosure possible.
- Integrity (I): None – No data modification.
- Availability (A): None – No denial of service.
Threat Level: Low. The vulnerability requires node-based network policies to be enabled (disabled by default) and relies on label collisions between nodes and other endpoints. Exploitation is unlikely in well-configured environments.
Deep Dive & Mechanics
Cilium uses eBPF programs to enforce network policies. Node-based policies (fromNodes and toNodes) are designed to restrict traffic based on node identity, typically using Kubernetes node labels. The vulnerability arises because the policy matching logic does not distinguish between node endpoints and other endpoints (e.g., pods) that share the same labels.
Root Cause: When a fromNodes or toNodes policy is defined, Cilium’s policy engine evaluates the labels specified. If a non-node endpoint (like a pod) has the same label key-value pair as a node, the policy incorrectly treats that endpoint as a node, allowing or denying traffic accordingly. This bypasses the intended node-level restriction.
Attack Scenario: An attacker who can create or modify endpoints (e.g., by deploying a pod with specific labels) could cause traffic to be incorrectly permitted or denied. For example, if a policy allows traffic from nodes labeled role=worker, an attacker could create a pod with the same label, and traffic from that pod would be allowed as if it were a node.
Affected Versions:
- Cilium v1.16.0 to v1.16.7
- Cilium v1.17.0 to v1.17.1
Fixed Versions:
- Cilium v1.16.8
- Cilium v1.17.2
Vulnerable vs. Patched Code
The exact code changes are not publicly available, but the fix likely involves adding a check to ensure that only node endpoints (identified by a specific identity type) are matched by fromNodes and toNodes policies.
Vulnerable Logic (Conceptual):
func (p *Policy) matchNodePolicy(endpointLabels map[string]string) bool {
for _, nodeLabel := range p.NodeLabels {
if endpointLabels[nodeLabel.Key] == nodeLabel.Value {
return true // Incorrectly matches any endpoint with the label
}
}
return false
}
Patched Logic (Conceptual):
func (p *Policy) matchNodePolicy(endpoint *Endpoint) bool {
if endpoint.Type != EndpointTypeNode {
return false // Only match node endpoints
}
for _, nodeLabel := range p.NodeLabels {
if endpoint.Labels[nodeLabel.Key] == nodeLabel.Value {
return true
}
}
return false
}
Exploitation & Lab Setup
Red Team
Prerequisites:
- A Kubernetes cluster with Cilium installed (v1.16.0 to v1.16.7 or v1.17.0 to v1.17.1).
- Node-based network policy enabled (not default).
- Ability to create pods with arbitrary labels.
Exploitation Steps:
- Identify a node-based policy that uses
fromNodesortoNodeswith specific labels. - Create a pod with labels that match the node labels used in the policy.
- Observe that traffic from/to this pod is now subject to the node policy, potentially bypassing intended restrictions.
Example Policy (Vulnerable):
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: allow-from-nodes
spec:
endpointSelector:
matchLabels:
app: my-app
ingress:
- fromNodes:
- matchLabels:
role: worker
Exploit Pod:
apiVersion: v1
kind: Pod
metadata:
name: malicious-pod
labels:
role: worker # Same label as node
spec:
containers:
- name: attacker
image: alpine
command: ["sleep", "3600"]
Result: Traffic from malicious-pod to my-app will be allowed, even though it is not a node.
Blue Team
Detection:
- Monitor for pods with labels that match node labels used in
fromNodes/toNodespolicies. - Audit Cilium network policies for use of node-based selectors.
- Enable Cilium’s policy audit mode to log all policy decisions.
Mitigation:
- Apply the patch by upgrading to Cilium v1.16.8 or v1.17.2.
- As a workaround, ensure labels used in
fromNodes/toNodesare unique to nodes and not used by other endpoints. - Disable node-based network policies if not required.
Indicators of Compromise (IOCs)
- Network Traffic: Unexpected traffic flows between pods that should be restricted by node-based policies.
- Cilium Logs: Policy decision logs showing
fromNodes/toNodesmatches for non-node endpoints. - Kubernetes Events: Creation of pods with labels that match node labels used in network policies.
- Cilium Identity: Non-node endpoints with identity type
nodein Cilium’s identity cache.
Detection Engineering
YARA Rule
rule CVE_2025_30163_Cilium_NodePolicyBypass {
meta:
description = "Detects Cilium versions vulnerable to node-based network policy bypass"
author = "Valters IT"
date = "2025-04-10"
reference = "CVE-2025-30163"
strings:
$version_1_16 = /Cilium v1\.16\.[0-7]/ nocase
$version_1_17 = /Cilium v1\.17\.[01]/ nocase
condition:
$version_1_16 or $version_1_17
}
Sigma Rule
title: Cilium Node-Based Network Policy Bypass
id: cve-2025-30163
status: experimental
description: Detects potential exploitation of CVE-2025-30163 where non-node endpoints match node labels in Cilium policies
author: Valters IT
date: 2025-04-10
logsource:
product: kubernetes
service: cilium
detection:
selection:
- event: "policy-verdict"
- verdict: "allowed"
- identity-type: "node"
- labels: "*"
condition: selection
falsepositives:
- Legitimate node endpoints
level: medium
Suricata Rule
alert tcp any any -> any any (msg:"CVE-2025-30163 Cilium Node Policy Bypass Attempt"; flow:to_server; content:"|0a|"; depth:1; content:"|0d 0a|"; within:10; reference:cve,2025-30163; classtype:attempted-recon; sid:1000001; rev:1;)
Remediation & Mitigation
Immediate Actions:
- Upgrade Cilium to v1.16.8 or v1.17.2 (or later).
- If upgrade is not possible, disable node-based network policies (
fromNodesandtoNodes) if not required. - Audit all existing node-based policies and ensure labels used are unique to nodes.
Long-Term Measures:
- Implement label naming conventions that prevent overlap between node and pod labels.
- Use Cilium’s identity-based policies instead of label-based node policies where possible.
- Enable Cilium’s policy audit mode to monitor for unexpected policy matches.
- Regularly review Cilium security advisories and apply patches promptly.
Workaround:
Ensure that the labels used in fromNodes and toNodes fields are used exclusively by nodes and not by other endpoints. This can be achieved by using labels that are automatically assigned by Kubernetes to nodes (e.g., kubernetes.io/hostname) and not used by pods.
Valters IT