CVE-2025-13281: 
NixOS vulnerability analysis and mitigation

CVE-2025-13281 is a half-blind Server-Side Request Forgery (SSRF) vulnerability in Kubernetes' kube-controller-manager component when using the in-tree Portworx StorageClass. It allows authorized users with high privileges to leak arbitrary information from unprotected endpoints in the control plane's host network, including link-local or loopback services. The vulnerability was reported by Xingyu Liu and Jinku Li of Xidian University, disclosed publicly on December 1, 2025 via the oss-security mailing list, and assigned CVE-2025-13281 with a CVSS v3.1 score of 5.8 (Medium) (Kubernetes GitHub Issue, oss-security). Affected versions include kube-controller-manager ≤ v1.30.14, ≤ v1.31.14, ≤ v1.32.9, ≤ v1.33.5, and ≤ v1.34.1 (Kubernetes GitHub Issue).

The vulnerability is classified as CWE-918 (Server-Side Request Forgery) and stems from the in-tree Portworx StorageClass provisioner in kube-controller-manager failing to restrict outbound HTTP GET requests to attacker-influenced endpoints — a gap that was previously patched for other in-tree StorageClasses (GlusterFS, Quobyte, StorageOS, ScaleIO) under CVE-2020-8555 (Kubernetes GitHub Issue). An attacker with permissions to create a pod using the built-in Portworx StorageClass can cause kube-controller-manager to issue GET requests from within the control plane's host network; the HTTP response body is then exposed in ProvisioningFailed event objects created by kube-controller-manager, making this a "half-blind" SSRF (response visible, but no attacker-controlled request body) (oss-security). Exploitation requires three concurrent conditions: running a vulnerable version with CSIMigrationPortworx feature gate disabled, the presence of unprotected endpoints on the control plane's host network, and the ability for untrusted users to create pods with the Portworx volume type (Kubernetes GitHub Issue). The CSIMigrationPortworx feature gate was enabled by default starting in v1.31, meaning versions ≥ v1.32 are only affected if the gate is explicitly overridden (oss-security).

Successful exploitation allows an authorized attacker to exfiltrate sensitive information from the Kubernetes control plane's host network, including responses from link-local metadata endpoints (e.g., cloud instance metadata services), unauthenticated services listening on localhost, or other services in the control plane's private network (Kubernetes GitHub Issue). The impact is limited to confidentiality — there is no integrity or availability impact — but the exposed data could include cloud credentials, internal service tokens, or other sensitive configuration details that could facilitate lateral movement or privilege escalation within the cluster environment (Red Hat CVE). Clusters running end-of-life versions ≤ v1.30 are at higher risk because CSIMigrationPortworx is disabled by default in those versions (oss-security).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Red Hat CVE). The EPSS score is approximately 0.025% (0.000250), reflecting a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires high privileges (ability to create pods with Portworx volume types) and a specific misconfiguration (disabled CSIMigrationPortworx feature gate), significantly limiting the practical attack surface (Kubernetes GitHub Issue).

1. Reconnaissance: Identify a Kubernetes cluster running a vulnerable kube-controller-manager version (≤ v1.30.14, ≤ v1.31.14, ≤ v1.32.9, ≤ v1.33.5, or ≤ v1.34.1) with the CSIMigrationPortworx feature gate disabled.
2. Verify preconditions: Confirm that untrusted or attacker-controlled accounts have RBAC permissions to create pods or PersistentVolumeClaims using the in-tree Portworx StorageClass, and that unprotected endpoints exist on the control plane's host network (e.g., cloud metadata at 169.254.169.254, unauthenticated localhost services).
3. Craft malicious StorageClass/PVC: Create a PersistentVolumeClaim referencing the in-tree Portworx StorageClass with parameters that direct kube-controller-manager to issue a GET request to a target internal endpoint (e.g., the cloud instance metadata service URL).
4. Trigger SSRF: Submit the crafted PVC to the cluster. kube-controller-manager processes the provisioning request and issues an HTTP GET to the attacker-specified endpoint from within the control plane's host network.
5. Harvest response data: Monitor ProvisioningFailed event objects created by kube-controller-manager (e.g., via kubectl get events) — the HTTP response body from the internal endpoint is embedded in these events, exposing sensitive data such as cloud credentials or internal service tokens (Kubernetes GitHub Issue, oss-security).

• Kubernetes Events: ProvisioningFailed events from kube-controller-manager containing unexpected HTTP response bodies, particularly those referencing internal IP ranges (e.g., 169.254.x.x, 127.0.0.1, RFC-1918 addresses) or cloud metadata content.
• Logs: kube-controller-manager logs showing outbound HTTP GET requests to link-local, loopback, or internal control plane network addresses initiated during Portworx StorageClass provisioning.
• API Server Audit Logs: Unusual or repeated creation of PersistentVolumeClaims using the in-tree Portworx StorageClass by accounts that do not normally use this storage type.
• Network: Unexpected HTTP traffic originating from the control plane node to 169.254.169.254 (cloud metadata) or other internal-only endpoints, correlated with PVC provisioning activity (Kubernetes GitHub Issue, oss-security).

The primary remediation is to upgrade kube-controller-manager to a fixed version: ≥ v1.32.10, ≥ v1.33.6, or ≥ v1.34.2 (oss-security). For clusters running v1.31 or later that have manually disabled the CSIMigrationPortworx feature gate, re-enabling the gate (restoring its default value) serves as an effective workaround without requiring an immediate upgrade (Kubernetes GitHub Issue). Additional hardening measures include restricting RBAC permissions to prevent untrusted users from creating pods with Portworx volume types, implementing network segmentation to protect control plane host network endpoints, and auditing ProvisioningFailed events for signs of exploitation. Clusters on EOL versions ≤ v1.30 should prioritize upgrading, as CSIMigrationPortworx is disabled by default in those versions, making them more broadly exposed (Red Hat CVE).

The vulnerability was coordinated and disclosed by the Kubernetes Security Response Committee, with the fix coordinated by Ankit Gohil (@gohilankit) (oss-security). Red Hat published a CVE advisory tracking the issue for their OpenShift and related products (Red Hat CVE). Microsoft also published guidance via the MSRC update guide for affected Azure Kubernetes Service (AKS) components (MSRC Advisory). Community reaction has been measured given the Medium severity rating and the significant preconditions required for exploitation; the vulnerability was noted in the Last Week in Kubernetes (LWKD) newsletter as part of routine security tracking.