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
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact An authenticated user with Kubernetes read permissions could access Kubernetes workload data beyond their intended scope by supplying crafted entity data to the deprecated services endpoint. The exposure is limited to read-only access to Kubernetes object metadata across configured clusters. Patches Patched in @backstage/plugin-kubernetes-backend version 0.21.8. Workarounds - Disable the deprecated /services/:serviceId route by deploying a custom Kubernetes router that omits it. - Restrict access to the kubernetes.resources.read permission to limit the set of users who can reach the endpoint.
Recommended action: Upgrade to 0.21.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated user holding the standard Kubernetes resource read permission could retrieve sensitive values that the Kubernetes plugin is designed to mask, potentially exposing credentials and other confidential material held in the connected clusters. Exposure is limited to resources that the Backstage service account is permitted to read and that match the targeted catalog entity's namespace and label selector. Deployments whose cluster credentials do not grant read access to these resources are unaffected. Patches Fixed in @backstage/plugin-kubernetes-backend version 0.21.9 One behavior change is worth noting for adopters who expose custom resources: a custom resource whose list kind is reported by the API server as SecretList now has the values of its data field masked, matching how core Kubernetes Secrets have always been handled on other query paths. Workarounds - Enable the permission framework and restrict kubernetes.resources.read to trusted users. - Scope the RBAC…
Recommended action: Upgrade to 0.21.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Deployments using catalog cluster discovery may be affected when catalog contributors can create or modify kubernetes-cluster Resource entities. With the required endpoint permissions and pod RBAC, the backend can use its local in-cluster identity, potentially exposing Kubernetes resources readable by that identity. The credential is used only with the local in-cluster API endpoint and is not sent to the catalog-supplied endpoint. Patches Patched in @backstage/plugin-kubernetes-backend version 0.21.10 Workarounds - Do not configure service account authentication through catalog-provided clusters; use the supported static configuration method when service account authentication is required. - Restrict catalog ingestion so untrusted users cannot create or alter Kubernetes cluster Resource entities.
Recommended action: Upgrade to 0.21.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.