Plugin Kubernetes Backend
Monthly
Improper entity validation in the deprecated Kubernetes services endpoint of @backstage/plugin-kubernetes-backend lets an authenticated Backstage user who already holds Kubernetes read permissions retrieve Kubernetes object metadata beyond their intended scope by submitting crafted entity data in the request body. The vulnerable handler trusted the caller-supplied entity reference instead of resolving it against the Backstage catalog, so the request was processed against an entity the user was not authorized for; the fix (0.21.8) parses the entity reference and performs a catalog lookup, returning 403 when no matching entity exists. Exposure is limited to read-only Kubernetes object metadata across configured clusters with no integrity or availability impact, and no public exploit code has been identified at time of analysis; exploitation is constrained to the legacy deprecated services endpoint and requires a crafted request that evades validation (AC:H).
Sensitive information disclosure in the @backstage/plugin-kubernetes-backend package before version 0.21.9 allows an authenticated Backstage user who holds the standard Kubernetes resource read permission to retrieve Kubernetes Secret values that the plugin is designed to mask. The flaw is specifically reachable through the custom resources query path, where both the `data` and `stringData` fields of Secrets were returned unmasked, potentially exposing credentials and other confidential material held in connected clusters. Exposure is bounded by the Backstage service account's RBAC scope and by the targeted catalog entity's namespace and label selector, so deployments whose cluster credentials cannot read those resources are unaffected; there is no public exploit code identified at time of analysis and the issue carries a moderate CVSS of 5.0.
Information disclosure in the Backstage Kubernetes backend plugin (@backstage/plugin-kubernetes-backend) before 0.21.10 allows an authenticated catalog contributor who can create or modify kubernetes-cluster Resource entities to steer cluster discovery into an unsupported authentication mode, causing the backend to answer Kubernetes API requests using its own local in-cluster service-account identity rather than a catalog-supplied credential. The disclosure is bounded strictly by what that pod service account is already permitted to read via RBAC, and the leaked credential is used only against the local in-cluster API endpoint and is never transmitted to the catalog-supplied endpoint; exploitation requires a non-default catalog cluster discovery deployment, the relevant endpoint permissions, and over-privileged pod RBAC, which is why the assessed severity is low. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in 0.21.10 (shipped in the Backstage release v1.54.6).
Improper entity validation in the deprecated Kubernetes services endpoint of @backstage/plugin-kubernetes-backend lets an authenticated Backstage user who already holds Kubernetes read permissions retrieve Kubernetes object metadata beyond their intended scope by submitting crafted entity data in the request body. The vulnerable handler trusted the caller-supplied entity reference instead of resolving it against the Backstage catalog, so the request was processed against an entity the user was not authorized for; the fix (0.21.8) parses the entity reference and performs a catalog lookup, returning 403 when no matching entity exists. Exposure is limited to read-only Kubernetes object metadata across configured clusters with no integrity or availability impact, and no public exploit code has been identified at time of analysis; exploitation is constrained to the legacy deprecated services endpoint and requires a crafted request that evades validation (AC:H).
Sensitive information disclosure in the @backstage/plugin-kubernetes-backend package before version 0.21.9 allows an authenticated Backstage user who holds the standard Kubernetes resource read permission to retrieve Kubernetes Secret values that the plugin is designed to mask. The flaw is specifically reachable through the custom resources query path, where both the `data` and `stringData` fields of Secrets were returned unmasked, potentially exposing credentials and other confidential material held in connected clusters. Exposure is bounded by the Backstage service account's RBAC scope and by the targeted catalog entity's namespace and label selector, so deployments whose cluster credentials cannot read those resources are unaffected; there is no public exploit code identified at time of analysis and the issue carries a moderate CVSS of 5.0.
Information disclosure in the Backstage Kubernetes backend plugin (@backstage/plugin-kubernetes-backend) before 0.21.10 allows an authenticated catalog contributor who can create or modify kubernetes-cluster Resource entities to steer cluster discovery into an unsupported authentication mode, causing the backend to answer Kubernetes API requests using its own local in-cluster service-account identity rather than a catalog-supplied credential. The disclosure is bounded strictly by what that pod service account is already permitted to read via RBAC, and the leaked credential is used only against the local in-cluster API endpoint and is never transmitted to the catalog-supplied endpoint; exploitation requires a non-default catalog cluster discovery deployment, the relevant endpoint permissions, and over-privileged pod RBAC, which is why the assessed severity is low. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in 0.21.10 (shipped in the Backstage release v1.54.6).