Kubernetes kube-apiserver NetworkPolicy bypass via race condition during namespace deletion

A security issue was discovered in Kubernetes where a malicious or compromised pod could bypass network restrictions enforced by network policies during namespace deletion. The order in which objects are deleted during namespace termination is not defined, and it is possible for network policies to be deleted before the pods that they protect. This can lead to a brief period in which the pods are running, but network policies that should apply to connections to and from the pods are not enforced.

• The Kubernetes advisory identifies kube-apiserver >= v1.3 as potentially affected when the cluster relies on the NetworkPolicy API.
• The supplied structured record marks 1.3.0 as affected and sets the default status to unaffected, but it does not enumerate every later release branch. Because the CNA advisory states >= v1.3, later branches should not be treated as safe without separate verification.
• The Kubernetes advisory states that there are no fixed versions. The input record sets patch_available to true but provides no solution or exact fixed release, so no confirmed upgrade target can be named.
• The advisory identifies ordered namespace deletion enhancement as a longer-term remediation direction, not as a confirmed fixed release for this issue.

Kubernetes kube-apiserver contains a race condition during namespace termination. Object deletion order is undefined, so network policies can be deleted before the pods they protect.

The high-level sequence is:

1. A cluster uses the NetworkPolicy API and begins deleting a namespace.
2. One or more network policies are deleted while pods or workload resources are still running.
3. For a short period, policies that should govern connections to and from those pods are no longer enforced.
4. A malicious or compromised pod can use that window to bypass network restrictions.

The record describes adjacent network reachability, no required user interaction, and classifies the issue as CWE-362. The exact race window, traffic that can pass, and concrete scope of exposure depend on how the cluster enforces network policy; those implementation details are not established by the advisory.

Exploitation depends on a malicious or compromised pod being present in a cluster that uses the NetworkPolicy API, together with timing during namespace deletion. The record characterizes reachability as adjacent and complexity as high because exploitation depends on the deletion timing; it lists no required user interaction.

The record also lists no privileges required, while the advisory describes the actor as a malicious or compromised pod. The practical attacker position in a cluster should therefore be assessed separately rather than inferred only from the scoring fields.

No public exploit is identified in the supplied data. The consulted enrichment records an exploitation status of none and automatable status of no, but that does not prove that every cluster is unexploited. No specific campaign, victim, or exploit is named by the sources.

The direct technical outcome is temporary loss of NetworkPolicy enforcement for pods in a namespace being deleted. A malicious or compromised pod may use that window to establish or receive connections that the policy should have restricted, creating a potential confidentiality impact within the affected cluster context.

The record does not establish an integrity or availability impact. The scope depends on timing, which pods remain running, and which policies protect them; not every namespace deletion will expose the same traffic.

During namespace termination, a pod may remain running after the network policies protecting it have been deleted. Connections that the policies were intended to restrict may then be allowed, creating a potential confidentiality exposure within the affected policy scope.

The consequence depends on the pod, policy, and traffic present during the race window. The sources do not establish data theft, data modification, service disruption, or a specific breach scenario.

1. Immediate mitigation: before starting namespace deletion, manually delete the pods and workload resources that orchestrate those pods.

2. Keep policies in place during deletion: add finalizers to network policies so they cannot be deleted before the pods they protect. The Kubernetes advisory refers to a proof-of-concept controller that automates this approach, but does not identify it as a complete vendor fix.

3. Track the long-term fix: follow Kubernetes' ordered namespace deletion enhancement. The advisory does not name a fixed release, so a specific version should not be treated as a confirmed resolution without direct vendor confirmation.

4. Validate the change: confirm that pods and workload resources are deleted before network policies in the namespace termination workflow, and review network logs around subsequent namespace deletions.

5. If a downstream Kubernetes distribution is in use, consult that vendor's advisory for its support and remediation status. Do not infer that the issue is resolved solely because the record marks a patch as available.

1. Check whether the cluster uses the NetworkPolicy API with the command provided by the Kubernetes advisory:

kubectl get networkpolicies.networking.k8s.io --all-namespaces

1. Inventory the running kube-apiserver deployments and identify clusters with NetworkPolicy resources, especially clusters that frequently delete namespaces.

2. Review namespace deletion workflows to determine whether pods and workload resources are removed before namespace deletion starts.

3. Check whether NetworkPolicy resources use finalizers that delay policy deletion until the protected pods have been deleted. The advisory does not identify a specific finalizer name.

4. Review network logs around namespace termination for connections to or from pods during the period when policy enforcement may have been absent. This is environment-dependent detection guidance, not a specific IOC; absence of suspicious log evidence does not prove safety.