☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
CVSS: 3.2 🐛 CWE-863
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2025-30162

CVE-2025-30162 Supply Chain Attack in Cilium
📅 PUBLISHED: 2025-03-24 18:44 UTC 🔄 UPDATED: 2026-09-23 20:36 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: LIKELY — 2 independent sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.22%
👁️
0.22% probability
5.5× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Patch available — upgrade to latest release
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
3.2
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2025-30162 is a medium-severity vulnerability in Cilium, an eBPF-based networking, observability, and security solution. The flaw allows egress traffic from workloads protected by network policies to bypass those policies when the traffic is destined for LoadBalancer services created via the Gateway API. This occurs because the Gateway API controller does not properly tag or associate the resulting LoadBalancer endpoints with the correct network policy enforcement context. The vulnerability affects Cilium versions 1.15.0 through 1.15.14, 1.16.0 through 1.16.7, and 1.17.0 through 1.17.1. The issue is fixed in versions 1.15.15, 1.16.8, and 1.17.2. A Clusterwide Cilium Network Policy can be used as a workaround for users unable to upgrade immediately.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

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.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Supply Chain & Package Security

This vulnerability is in the Cilium project, which is distributed as container images and Go modules. Users should verify the integrity of their Cilium images using the official checksums and signatures. The fix is available in the upstream repository, and users should update their deployments accordingly.

CVSS Breakdown & Threat Level

  • CVSS Score: 3.2 (Low)
  • Vector: CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
  • Attack Vector (AV): Adjacent Network (AV:A) – The attacker must be on the same network segment as the affected workloads.
  • Attack Complexity (AC): Low (AC:L) – No special conditions are required.
  • Privileges Required (PR): Low (PR:L) – The attacker needs valid credentials to deploy a Gateway resource.
  • User Interaction (UI): None (UI:N) – No user action is required.
  • Scope: Unchanged (S:U) – The vulnerability does not affect other components.
  • Confidentiality Impact (C): Low (C:L) – Limited information disclosure is possible.
  • Integrity Impact (I): None (I:N) – No data modification.
  • Availability Impact (A): None (A:N) – No denial of service.

Threat Level: Low. Exploitation requires an adjacent network position and the ability to create Gateway API resources. The impact is limited to bypassing egress network policies, potentially allowing data exfiltration to unauthorized external services.

Deep Dive & Mechanics

The vulnerability stems from a mismatch in how Cilium’s Gateway API controller and its network policy enforcement engine handle LoadBalancer services. When a user creates a Gateway resource, Cilium’s controller provisions a corresponding LoadBalancer service (using LB-IPAM or BGP). However, the network policy engine does not correctly associate the endpoints of this LoadBalancer service with the namespace or identity of the Gateway resource. As a result, egress network policies that should block traffic from workloads in one namespace to workloads in another namespace are not applied to traffic destined for these Gateway-created LoadBalancers.

Root Cause: The Gateway API controller creates LoadBalancer services with a specific label or annotation that the network policy engine does not recognize as belonging to the same namespace as the Gateway. This causes the policy engine to treat the LoadBalancer endpoints as external or unmanaged, bypassing the egress rules.

Attack Scenario:

  1. An attacker with low privileges in a Kubernetes cluster creates a Gateway resource in a namespace that is not allowed to communicate with other namespaces.
  2. The Gateway controller provisions a LoadBalancer service with an external IP.
  3. A workload in the attacker’s namespace, which should be blocked from egress to other namespaces, can now send traffic to the LoadBalancer IP.
  4. The traffic is forwarded to the backend service (potentially in another namespace), bypassing the egress policy.

Vulnerable vs. Patched Code

Vulnerable Code (Cilium v1.15.0 - v1.15.14, v1.16.0 - v1.16.7, v1.17.0 - v1.17.1): The Gateway API controller creates LoadBalancer services without adding the necessary identity labels that the network policy engine uses for enforcement. The policy engine checks for these labels to determine if a destination endpoint belongs to a specific namespace.

// Vulnerable: Gateway controller creates LB service without namespace identity
func (c *Controller) createLoadBalancer(gateway *gwv1.Gateway) error {
    lbService := &corev1.Service{
        ObjectMeta: metav1.ObjectMeta{
            Name:      gateway.Name + "-lb",
            Namespace: gateway.Namespace,
            // Missing: Labels that tie this service to the Gateway's namespace
        },
        Spec: corev1.ServiceSpec{
            Type: corev1.ServiceTypeLoadBalancer,
            // ...
        },
    }
    _, err := c.client.CoreV1().Services(gateway.Namespace).Create(context.TODO(), lbService, metav1.CreateOptions{})
    return err
}

Patched Code (Cilium v1.15.15, v1.16.8, v1.17.2): The fix adds a specific label to the LoadBalancer service that the network policy engine can recognize. This label ensures that the service endpoints are treated as part of the Gateway’s namespace for policy enforcement.

// Patched: Gateway controller adds namespace identity label
func (c *Controller) createLoadBalancer(gateway *gwv1.Gateway) error {
    lbService := &corev1.Service{
        ObjectMeta: metav1.ObjectMeta{
            Name:      gateway.Name + "-lb",
            Namespace: gateway.Namespace,
            Labels: map[string]string{
                "cilium.io/gateway-namespace": gateway.Namespace,
            },
        },
        Spec: corev1.ServiceSpec{
            Type: corev1.ServiceTypeLoadBalancer,
            // ...
        },
    }
    _, err := c.client.CoreV1().Services(gateway.Namespace).Create(context.TODO(), lbService, metav1.CreateOptions{})
    return err
}

Exploitation & Lab Setup

Red Team

Prerequisites:

  • Access to a Kubernetes cluster with Cilium installed (vulnerable version).
  • Ability to create Gateway API resources (requires networking.x-k8s.io CRDs).
  • A workload in a namespace that has an egress network policy blocking traffic to other namespaces.

Exploitation Steps:

  1. Create a Gateway resource in the attacker’s namespace:
    apiVersion: gateway.networking.k8s.io/v1
    kind: Gateway
    metadata:
      name: malicious-gateway
      namespace: attacker-ns
    spec:
      gatewayClassName: cilium
      listeners:
      - name: http
        port: 80
        protocol: HTTP
    
  2. The Gateway controller creates a LoadBalancer service (e.g., malicious-gateway-lb).
  3. From a pod in attacker-ns, send traffic to the LoadBalancer’s external IP:
    curl http://<LOADBALANCER_IP>
    
  4. Observe that the traffic reaches the backend service (e.g., in victim-ns), bypassing the egress policy.

Blue Team

Detection:

  • Monitor for unexpected creation of Gateway resources, especially in namespaces with restrictive egress policies.
  • Alert on LoadBalancer services that are created without the cilium.io/gateway-namespace label (in patched versions).
  • Use network flow logs to detect traffic from namespaces to LoadBalancer IPs that should be blocked.

Mitigation:

  • Apply a Clusterwide Cilium Network Policy as a workaround:
    apiVersion: "cilium.io/v2"
    kind: ClusterwideCiliumNetworkPolicy
    metadata:
      name: "block-gateway-bypass"
    spec:
      endpointSelector:
        matchLabels:
          io.kubernetes.pod.namespace: attacker-ns
      egress:
      - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": victim-ns
        action: deny
    
  • Upgrade to the patched version.

Indicators of Compromise (IOCs)

  • Network: Unexpected traffic from a namespace to a LoadBalancer IP that is not part of the allowed egress destinations.
  • Kubernetes Events: Creation of Gateway resources in namespaces with restrictive network policies.
  • Cilium Logs: Entries showing policy enforcement bypass for LoadBalancer services created by the Gateway API controller.
  • Service Anomalies: LoadBalancer services without the cilium.io/gateway-namespace label (in patched versions).

Detection Engineering

YARA Rule

rule CVE_2025_30162_Cilium_Gateway_Bypass {
    meta:
        description = "Detects Cilium Gateway API egress policy bypass"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-30162"
    strings:
        $s1 = "cilium.io/gateway-namespace" ascii wide nocase
        $s2 = "Gateway" ascii wide nocase
        $s3 = "LoadBalancer" ascii wide nocase
    condition:
        all of ($s1, $s2, $s3) and #s1 < 1
}

Sigma Rule

title: Cilium Gateway API Egress Policy Bypass
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects creation of Gateway resources that may bypass egress network policies in Cilium
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-30162
logsource:
    product: kubernetes
    service: audit
detection:
    selection:
        verb: "create"
        objectRef.resource: "gateways"
        objectRef.apiGroup: "gateway.networking.k8s.io"
    condition: selection
falsepositives:
    - Legitimate use of Gateway API for ingress
level: medium
tags:
    - attack.t1190

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-30162 Cilium Gateway Egress Bypass"; flow:to_server; content:"|48 54 54 50|"; http_method; content:"Host|3a 20|"; http_header_names; pcre:"/^Host\x3a\s+[a-zA-Z0-9.-]+$/"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Mitigation:

  • Apply a Clusterwide Cilium Network Policy to block egress traffic from affected namespaces to any LoadBalancer IPs that are not explicitly allowed.
  • Restrict the ability to create Gateway resources to trusted users only (RBAC).

Long-Term Fix:

  • Upgrade Cilium to v1.15.15, v1.16.8, or v1.17.2 (or later).
  • After upgrade, verify that all LoadBalancer services created by the Gateway API controller have the cilium.io/gateway-namespace label.

Validation:

  • After applying the fix, test egress policies by attempting to send traffic from a restricted namespace to a Gateway-created LoadBalancer. The traffic should be blocked.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2025-30162/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.