Kubernetes kube-controller-manager Portworx SSRF enables control-plane data disclosure

A half-blind Server Side Request Forgery (SSRF) vulnerability exists in kube-controller-manager when using the in-tree Portworx StorageClass. This vulnerability allows authorized users to leak arbitrary information from unprotected endpoints in the control plane’s host network (including link-local or loopback services).

Kubernetes identifies the following branches as affected when the in-tree Portworx StorageClass can be used:

• kube-controller-manager from v1.30.0 through v1.30.14.
• kube-controller-manager from v1.31.0 through v1.31.14.
• kube-controller-manager from v1.32.0 through v1.32.9.
• kube-controller-manager from v1.33.0 through v1.33.5.
• kube-controller-manager from v1.34.0 through v1.34.1.

Configuration determines whether the affected code path is usable. CSIMigrationPortworx is enabled by default starting with v1.31, which disables in-tree Portworx by default; deployments from v1.32 onward are not impacted in that default state but can be affected if the feature gate is overridden to disable migration. End-of-life v1.30 deployments are more likely to be exposed because the feature gate is disabled by default.

The advisory lists v1.32.10, v1.33.6, and v1.34.2 as fixed versions for the corresponding branches. The supplied record and inspected advisory do not establish a specific fixed release for the v1.30 and v1.31 branches.

Kubernetes kube-controller-manager contains a half-blind Server-Side Request Forgery (SSRF) flaw in processing the in-tree Portworx StorageClass. The attack requires a user authorized to create a pod using the affected Portworx volume type. When the conditions are met, kube-controller-manager can issue HTTP GET requests from the control plane host network without an attacker-controlled request body, and the corresponding response body can become visible in events created by the controller.

This can expose data from unprotected endpoints that are normally reachable only from the control plane host network, including link-local services, loopback services, and services on the control plane's private network. The exact endpoint set depends on services listening in the deployment and the cluster's network configuration. Available evidence does not establish an ability to modify data or disrupt services.

The flaw is reachable through the network-facing Kubernetes management path, but exploitation requires high-level authorization to create a pod with the affected Portworx volume type. No separate user interaction is required after the attacker has the necessary privileges and the relevant configuration; exploitation still depends on in-tree Portworx being usable, an unprotected endpoint being reachable from the control plane host network, and an untrusted user having the required pod-creation permission.

The supplied record marks a public exploit as false and does not provide a known-exploited status. That does not prove that exploitation has not occurred, because the available evidence only records the documented public-exploit and known-exploitation fields.

An attacker who meets the authorization requirements can cause kube-controller-manager to send a GET request from the control plane host network and expose the response body through a provisioning event. The technical result is disclosure of data from unprotected internal endpoints, including link-local, loopback, or private control-plane services.

The demonstrated impact is primarily confidentiality loss and crosses from the pod-creation context into the control plane host-network context. The exposed data could include administrative or internal service information, depending on which endpoints are available in the environment. Available evidence does not establish direct endpoint modification, direct privilege escalation, or an availability impact.

The flaw can disclose HTTP response content from services that should be reachable only inside the control plane host network. Depending on the deployment, exposed data may come from link-local endpoints, loopback services, or services on the control plane's private network.

The primary operational consequence is loss of confidentiality for control-plane or internal service data. Leaked information could support further reconnaissance, but the available evidence does not identify a specific intrusion scenario, campaign, victim, or breach. No evidence establishes direct data modification or service disruption through this vulnerability.

1. Upgrade kube-controller-manager. Use the branch-specific fixed release identified by Kubernetes: v1.32.10, v1.33.6, or v1.34.2. For branches without a specific fixed release established by the available evidence, upgrade Kubernetes to a branch with a confirmed fix rather than assuming a fix level.
2. Enable CSIMigrationPortworx if the feature gate has been overridden from its default state and enabling migration is compatible with the deployment. Under the advisory's conditions, this prevents use of the in-tree Portworx path.
3. During remediation, recheck pod-creation permissions for the affected Portworx volume type and the effective feature-gate state on every control-plane instance. Do not treat the absence of ProvisioningFailed events as a substitute for patching or exposure reduction.

Use the following checks:

1. Inventory kube-controller-manager versions and determine whether each cluster falls within the affected branches.
2. Inspect the effective state of CSIMigrationPortworx, including whether the feature gate has been overridden to permit in-tree Portworx.
3. Review RBAC and admission policy to determine whether untrusted users can create pods with the affected Portworx volume type.
4. Identify link-local, loopback, and internal services that are reachable only from the control plane host network and do not require authentication.
5. Review ProvisioningFailed events created by kube-controller-manager for response content or sensitive data originating from the control plane host network. This is an investigation lead, not a standalone proof of exploitation.
6. If suspicious data is found, preserve the relevant events and logs for investigation; the absence of matching events does not prove that a cluster is safe.