Understanding CVE-2025-13281: Half Blind SSRF in Kubernetes Portworx

A half‑blind Server‑Side Request Forgery (SSRF) has been disclosed in the Kubernetes kube‑controller‑manager that specifically affects clusters using the in‑tree Portworx StorageClass; the flaw can be triggered by any actor who can create pods that request Portworx volumes and can leak data from services visible only to the control plane’s host network (including link‑local and loopback endpoints).

Background​

Kubernetes historically included several vendor storage drivers as “in‑tree” volume plugins. Over the last few releases the project has moved those drivers toward out‑of‑tree CSI implementations and introduced the CSIMigration feature gates as an opt‑in/out mechanism during the migration window. The newly assigned CVE‑2025‑13281 concerns the legacy Portworx in‑tree path and a logic flaw in kube‑controller‑manager that leads to a half‑blind SSRF when certain preconditions are met. The Kubernetes Security Response Committee rated the issue Medium (CVSS 5.8) and published details and remediation guidance alongside the coordinated fix. This is not a generic remote SSRF that any internet attacker can execute; the practical attack model requires privileges to create pods that request Portworx volumes (a common capability in multi‑tenant or misconfigured clusters). When the kube‑controller‑manager processes provisioning events for such volumes it may perform GET requests from the control plane host network and then surface the response body as part of event text, turning otherwise internal endpoints into exfiltration targets.

---

Overview: what CVE‑2025‑13281 is and why it matters​

• What it is: A half‑blind SSRF in kube‑controller‑manager triggered by use of the in‑tree Portworx StorageClass; the server issues GET requests from the control plane host network and then places the returned body into event objects.
• Scope and severity: Medium (CVSS 5.8) with a confidentiality impact; exploitation requires namespace‑scoped pod creation privileges and the presence of unprotected host‑network endpoints.
• Primary risk: Information disclosure of internal services accessible only from the control plane host (metadata services, unauthenticated localhost APIs, or private control‑plane management endpoints).

The combination of a privileged control plane process (kube‑controller‑manager) and an operation that surfaces returned content in events turns a normally benign provisioning workflow into a channel for local exfiltration. This is a textbook SSRF pattern adapted to the Kubernetes control plane context.

---

Technical anatomy — how the bug works​

The vulnerable flow​

At a high level the bug arises when kube‑controller‑manager handles a provisioning operation for Portworx-backed volumes and treats untrusted user input as a URL (or URL‑like path) that it will fetch from the host‑network context. The controller issues a GET request from the control plane host network; because the requesting code path does not restrict the target hostname/IP nor sanitize it thoroughly, the controller can be induced to reach link‑local, loopback, or otherwise internal services. The HTTP response body is then included in the controller’s ProvisioningFailed or related event messages, making the data visible to any actor who can read events for the namespace. Key characteristics of the flaw:

• The request initiated by the controller is half‑blind: the attacker can control the request target but cannot fully control request headers or body content generated by kube‑controller‑manager; GET is the primary method used, and the controller returns the response body via an API‑level artifact (events).
• The request executes from the control plane host network, not from a pod network namespace; this means services reachable only from the host (for example, metadata endpoints or management webhooks bound to localhost) can be accessed.
• The exploit requires some privilege: the attacker needs rights to create pods that request the affected Portworx volume type or otherwise influence provisioning requests. This is a common capability in multi‑tenant clusters where RBAC is permissive or CI/CD runners are misconfigured.

Why “half‑blind” matters​

Classic SSRF categories include blind, half‑blind, and full SSRF depending on whether the attacker sees the response content, only timing, or nothing at all. In this case the attacker gains a reliable path to retrieve response bodies because kube‑controller‑manager writes returned content into event messages, which are readable by authorized actors with namespace‑level read access. That elevates the confidentiality impact relative to a fully blind SSRF where the attacker only observes side‑effects.

---

Affected versions and the CSIMigration gating nuance​

The Kubernetes advisory spells out the affected versions and emphasizes the interaction with the CSIMigrationPortworx feature gate:

• Potentially affected kube‑controller‑manager versions: <= v1.30.14, <= v1.31.14, <= v1.32.9, <= v1.33.5, <= v1.34.1.
• Fixed in: kube‑controller‑manager >= v1.32.10, >= v1.33.6, >= v1.34.2. Operators should upgrade to one of these or later versions.
• Important operational note: the in‑tree Portworx StorageClass is disabled by default starting in v1.31 via the CSIMigrationPortworx feature gate. Clusters running v1.31+ that have not explicitly overridden this gate are not affected; vulnerable clusters are those that either run older control plane versions or have manually disabled the migration feature.

Put simply: if your cluster runs a supported release and you have not overridden the CSIMigrationPortworx gate, you are probably not exposed — but you must verify configuration to be sure.

---

Exploitation model and prerequisites​

An attacker needs the following environment to exploit CVE‑2025‑13281 in practice:

• Namespace‑scoped ability to create pods that request Portworx volumes (or otherwise can influence a provisioning request processed by kube‑controller‑manager). This typically means a user, CI job, or service account with pod creation rights in a namespace where Portworx volumes are accepted.
• A kube‑controller‑manager that is running an affected version and where the CSIMigrationPortworx gate is disabled (explicitly or because the cluster is older than v1.31).
• Presence of internal/unprotected endpoints on the control plane host network that the attacker wants to reach (for instance, cloud metadata endpoints, internal health endpoints, or misconfigured admin interfaces).

Attack complexity is rated high in the advisory’s CVSS vector because the attacker needs privileges that are commonly restricted; however, in many real‑world multi‑tenant and CI/CD environments those privileges are granted more broadly than operators expect, so the operational risk can be significant.

---

Detection: signals and indicators​

Detecting attempted or successful exploitation requires monitoring several cluster artifacts:

• ProvisioningFailed and related kube‑controller‑manager events: the advisory explicitly warns that such events may contain internal response bodies when the controller was induced to make the SSRF call. Audit any events that contain unexpected host‑network content or long payloads.
• API server audit logs: review pod creation requests that include Portworx volume types; correlate these with subsequent controller events. Look for pod creators that are non‑standard service accounts, CI runner identities, or external integrations.
• Controller logs: kube‑controller‑manager logs may show provisioning calls or error messages around volume provisioning; these logs can help reconstruct the target URLs or request patterns the controller performed.
• RBAC anomalies: runtime checks for recently granted pod‑create rights and unexpected RoleBindings/ClusterRoleBindings in namespaces that host VM workloads or Portworx volumes. Tight RBAC reduces the chance an attacker can reach this code path.

Operators should instrument event parsing and add alerting rules for unusually large event messages from kube‑controller‑manager, or for events that contain IP addresses pointing to internal host ranges.

---

Immediate mitigations and hardening — practical checklist​

If you cannot apply the fixed kube‑controller‑manager versions immediately, apply compensating controls to minimize risk:

• Enable or do not override CSIMigrationPortworx in clusters running v1.31+; leaving the migration gate enabled prevents in‑tree Portworx codepaths from being used. This is the simplest short‑term mitigation for many clusters.
• Restrict who can create pods that reference Portworx volumes:
• Audit RoleBindings and ServiceAccounts to identify principals that can create pods in namespaces that accept Portworx volumes.
• Use Admission Controllers (e.g., Gatekeeper or Kyverno) to deny pod specs that reference in‑tree Portworx volume types unless explicitly approved.
• Tighten access to events and namespace objects: ensure least privilege for read access to events; many teams treat events as benign, but this disclosure shows events can carry sensitive content. Limit cluster‑wide visibility where feasible.
• Network hardening for control plane hosts:
• Block or filter host‑only endpoints that should never be reachable from the control plane processes (where practical).
• Use host‑level firewalling and listen‑only‑on‑localhost for management endpoints where possible. Note that this may not be feasible in all managed control planes.
• Monitor for suspicious event content: create automated checks that flag event bodies containing IP addresses from link‑local ranges (169.254.169.254), localhost, or internal service CIDRs. Such artifacts are strong indicators of SSRF activity.

These mitigations are practical stopgaps; they do not replace upgrading to a fixed control plane version but buy time for patch scheduling and testing.

---

Fixed versions and upgrade guidance​

The Kubernetes Security Response Committee published the fix and the following fixed kube‑controller‑manager version thresholds:

• Upgrade to >= v1.32.10, >= v1.33.6, or >= v1.34.2 for the respective release tracks.

Upgrade guidance for operators:

• Inventory control plane versions across clusters and verify whether CSIMigrationPortworx has been overridden. Use the kube‑apiserver and kube‑controller‑manager flags to confirm feature‑gate settings.
• If using vendor or managed Kubernetes distributions, confirm whether the vendor has backported the fix into their builds; do not assume the cloud provider has applied a backport without explicit confirmation. Managed control planes often coordinate fixes faster, but vendor timelines vary.
• Test upgrades in staging: reproduce provisioning workflows that use Portworx volumes and validate no ProvisioningFailed events leak internal content after upgrade.
• After upgrade, re‑audit events and audit logs to confirm there are no lingering incidents and that the controller no longer performs the problematic GET requests in provisioning flows.

---

Risk analysis — strengths, constraints, and residual concerns​

Notable strengths of the fix and disclosure​

• The maintainers coordinated a targeted patch and clearly communicated the interaction with CSIMigrationPortworx; the advisory includes detection guidance that points to a concrete artifact (ProvisioningFailed events) which makes triage actionable.
• The remediation is surgical: disabling or migrating away from the in‑tree Portworx codepath removes the vulnerable flow entirely for most clusters, and the fixed releases are available across multiple active release tracks.

Practical constraints and residual risks​

• Privilege requirement is real but common: while the CVSS vector lists privileges required as high, many platforms delegate pod creation to CI/CD systems, self‑service namespaces, or third‑party integrations — any of these can be abused to reach the vulnerable codepath. Operators with permissive RBAC are at higher risk.
• Event leakage is stealthy: events are an often‑ignored telemetry source; adversaries can use event streams to quietly exfiltrate contents without generating conspicuous network traffic from normal application pods. Detection requires explicit auditing and alerting.
• Vendor/backport latency: downstream distributors and managed services may take time to ship backports for older control plane versions or vendor‑specific images. Relying on vendor timelines without independent verification is risky.

Any claims about active exploitation campaigns in the wild should be treated cautiously until telemetry or incident reports confirm such activity; at disclosure time the advisory did not cite widespread in‑the‑wild exploitation, but the proof‑of‑concept nature of the issue means weaponization is plausible in permissive multi‑tenant environments.

---

Step‑by‑step remediation playbook (priority actions)​

• Immediately determine exposure:
• Query cluster control plane versions and check CSIMigrationPortworx feature‑gate status.
• List namespaces where Portworx volumes can be requested and identify principals with pod creation rights.
• If the cluster is vulnerable and you cannot upgrade immediately:
• Re‑enable CSIMigrationPortworx (if it was manually disabled).
• Apply an admission policy to block pod specs referencing the in‑tree Portworx volume type.
• Restrict event read permissions to a minimum set of principals.
• Schedule and test an upgrade to a fixed kube‑controller‑manager version in a staging environment:
• Validate that provisioning workflows no longer produce events containing host‑network responses.
• Confirm vendor backports if running a vendor or cloud distribution.
• Harden RBAC and CI/CD:
• Remove pod creation rights for untrusted pipelines in namespaces that host Portworx volumes.
• Require dedicated, least‑privileged service accounts for provisioning tasks.
• Implement detection and monitoring:
• Alert on ProvisioningFailed events with payloads containing host‑range addresses or HTTP content.
• Review API server audit logs for unexpected pod creations referencing Portworx volumes.

---

Verification and testing after remediation​

After upgrading or applying mitigation controls:

• Run a controlled test that simulates a provisioning request and confirm no GET requests to internal host addresses are made by kube‑controller‑manager and no internal content appears in events.
• Search cluster events for historical leaks and preserve any suspicious artifacts for forensic review. If you detect evidence of prior exfiltration, treat this as a possible incident and begin a standard investigation and containment process.

---

Conclusion​

CVE‑2025‑13281 is an important reminder that control‑plane code paths which process user‑supplied storage or volume metadata can become SSRF vectors when they are permitted to make network calls from privileged host contexts. The vulnerability is not a universal remote takeover, but it is meaningful in shared, multi‑tenant, or automation‑driven environments where pod creation rights and legacy in‑tree drivers remain in use. Operators should prioritize verifying CSIMigrationPortworx settings, tighten who may create Portworx‑backed pods, and upgrade kube‑controller‑manager to one of the listed fixed releases as soon as operationally feasible. For defenders: treat event bodies as potential sources of sensitive information, harden RBAC and CI pipelines, and instrument audit and event‑monitoring pipelines to detect anomalous provisioning artifacts. These operational controls, together with the fixed control plane releases, close the most direct attack paths exposed by this CVE.
Caveat: any statements about active exploitation campaigns were not corroborated by public incident reports at the time of the advisory and should be treated as unverified until telemetric evidence or CERT reports confirm them.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center