Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/rancher/local-path-provisioner < 0.0.36
Fixed in
0.0.36· Vendor fix available
Issue
Impact A malicious user with permission to edit the local-path-config ConfigMap in the local-path-storage namespace can manipulate the helperPod.yaml template used by rancher/local-path-provisioner. The helperPod.yaml template is loaded by the provisioner and used to create HelperPods during PVC provisioning and cleanup operations. However, the template is not sufficiently validated before use. Security-sensitive fields such as securityContext.privileged, hostPath volumes, and Linux capabilities can be injected into the template. Example malicious HelperPod template: ~~~yaml apiVersion: v1 kind: Pod metadata: name: helper-pod spec: containers: - name: helper-pod image: docker.io/kindest/local-path-helper:v20230510-486859a6 imagePullPolicy: IfNotPresent securityContext: privileged: true volumeMounts: - name: host-root mountPath: /host volumes: - name: host-root hostPath: path: / type: Directory ~~~ When a PVC operation triggers HelperPod creation, the provisioner creates the HelperPod…
Recommended action: Upgrade to 0.0.36 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/rancher/local-path-provisioner < 0.0.34
Fixed in
0.0.34· Vendor fix available
Issue
Impact A malicious user can manipulate the parameters.pathPattern to create PersistentVolumes in arbitrary locations on the host node, potentially overwriting sensitive files or gaining access to unintended directories. Example: This produces a PersistentVolume that points to /etc/new-dir, instead of a path under the configured base directory. Expected Behavior: - Paths generated from pathPattern should always resolve under the configured base path. - Relative path elements (e.g., ..) should be normalized or rejected. Patches This vulnerability is addressed by validating and normalizing the parameters.pathPattern to ensure that generated PersistentVolume paths always resolve under the configured base directory. Any path traversal attempts using relative path elements are rejected, preventing PersistentVolumes from being created in arbitrary locations on the host node. Previously, a malicious user could manipulate pathPattern to escape the base path and create volumes pointing to…
Recommended action: Upgrade to 0.0.34 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.