Kubernetes CVE-2025-13281

Exploitation requires the cluster to use the in-tree Portworx volume provisioner via a Portworx StorageClass - this is a specific, non-default, and now-deprecated storage configuration; clusters not using in-tree Portworx are not affected. The attacker must also be an authorized, privileged user (PR:H) able to define or influence the StorageClass/provisioning parameters so the controller-manager issues the attacker-directed request. Exploitation is further limited by high attack complexity (AC:H) and by the half-blind nature of the SSRF, which yields only inferred/leaked information (confidentiality only) rather than write access or service disruption. No end-user interaction is needed (UI:N).

This is a medium-severity issue (CVSS 5.8) whose real-world priority is low-to-moderate despite the ability to reach control-plane host-network services. The CVSS vector itself tempers the network attack vector (AV:N) with two strong limiting factors: high attack complexity (AC:H) and high privileges required (PR:H), meaning only an already-authorized, privileged user who can define or control an in-tree Portworx StorageClass can trigger it. The scope change (S:C) and C:H/I:N/A:N profile correctly reflect a read-only, half-blind SSRF that crosses a trust boundary into the control plane's host network but cannot write or disrupt. No EPSS score, KEV listing, or public POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the absence of EPSS data means widespread-exploitation probability cannot be quantified here. Signals are internally consistent - nothing conflicts - and all point to a privileged, config-dependent information-disclosure bug rather than a broadly exploitable remote flaw. This is a hardening/defense-in-depth priority (especially for multi-tenant clusters where cluster-admin is not fully trusted), not an emergency patch.

In a cluster that uses the in-tree Portworx storage provisioner, a privileged but non-fully-trusted user (e.g. a tenant with rights to define StorageClasses or provision volumes) supplies a crafted Portworx endpoint value. The kube-controller-manager then issues a server-side request from the control plane's host network to that attacker-chosen target, and the half-blind response allows the user to infer or leak data from otherwise unreachable loopback or link-local services (such as cloud metadata or internal control-plane endpoints). No public exploit code was provided in the input.