CVE-2026-106561: 
JavaScript vulnerability analysis and mitigation

CVE-2026-106561 is a sensitive information disclosure vulnerability in the @backstage/plugin-kubernetes-backend npm package, an open framework component for building developer portals. An authenticated user holding the standard Kubernetes resource read permission (kubernetes.resources.read) can retrieve sensitive values — such as Kubernetes Secret data and stringData fields — that the plugin is designed to mask. Affected versions are @backstage/plugin-kubernetes-backend prior to 0.21.9 and Backstage prior to 1.54.2. The vulnerability was published by GitHub Security Advisory on August 28, 2026, and assigned a CVE on October 7, 2026, with a CVSS v3.1 base score of 5.0 (Medium) (Github Advisory, Red Hat).

The root cause is improper removal of sensitive information before transfer (CWE-212) combined with incorrect authorization logic (CWE-863) and exposure of sensitive information to an unauthorized actor (CWE-200). Specifically, the transformResources method in KubernetesFetcher.ts only masked Secret data fields when resources were fetched via the standard secrets object type path; when Kubernetes Secrets were fetched via the custom resources query path (i.e., objectType === 'customresources'), the masking logic was not applied, leaving both data and stringData fields exposed in plaintext. The fix (commit 388926a) extends the redaction condition to also trigger when the API server reports a list kind of SecretList, regardless of the query path used (Github Advisory, Patch Commit).

Successful exploitation allows an authenticated Backstage user to read unredacted Kubernetes Secret values — including credentials, tokens, and other confidential material — from any cluster resource the Backstage service account is permitted to read, scoped to the targeted catalog entity's namespace and label selector. There is no integrity or availability impact; the scope is changed because the vulnerability crosses from the Backstage application boundary into connected Kubernetes cluster resources. Deployments where the Backstage service account lacks read access to sensitive resource types (consistent with the recommended ClusterRole in the plugin documentation) are unaffected (Github Advisory).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time. The vulnerability requires authentication (low privileges) and is not automatable according to SSVC assessment. The EPSS score is approximately 0.197%, indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Github Advisory, Red Hat).

1. Authenticate to Backstage: Obtain valid Backstage credentials for an account that holds the kubernetes.resources.read permission, which is the standard permission for viewing Kubernetes resources in the portal.
2. Identify target catalog entity: Browse the Backstage catalog to identify a software component or entity that is linked to a Kubernetes cluster containing Secrets of interest.
3. Craft a custom resource query: Using the Backstage Kubernetes plugin API, issue a resource query specifying group: '', apiVersion: 'v1', and plural: 'secrets' as a custom resource type (rather than using the standard secrets object type path).
4. Retrieve unredacted Secret values: The backend processes the query via the custom resources path, which (in versions prior to 0.21.9) does not apply Secret masking. The API response returns the data and stringData fields of matching Kubernetes Secrets in plaintext or base64-encoded form, scoped to the entity's namespace and label selector.
5. Exfiltrate credentials: Decode any base64-encoded data values to obtain plaintext credentials, tokens, or other sensitive material stored in the cluster Secrets (Github Advisory, Patch Commit).

• Logs: Backstage backend logs showing authenticated API requests to the Kubernetes plugin's custom resources endpoint with plural: 'secrets', group: '', and apiVersion: 'v1' parameters — particularly from users who do not normally query Kubernetes resources.
• Network: Unusual or repeated Kubernetes API calls from the Backstage service account to /api/v1/secrets (or namespaced equivalents) originating from the Backstage backend, especially with label selectors matching multiple catalog entities in quick succession.
• Logs: Backstage audit logs (if enabled) recording kubernetes.resources.read permission checks for Secret resource types via the custom resources query path from unexpected user accounts or at unusual times.

Upgrade @backstage/plugin-kubernetes-backend to version 0.21.9 or later, or upgrade the Backstage application to version 1.54.2 or later, which includes the patched package (Github Advisory, Backstage Release). If immediate upgrade is not possible, two workarounds are available: (1) enable the Backstage permission framework and restrict the kubernetes.resources.read permission to trusted users only; and (2) scope the RBAC of the Kubernetes service account used by Backstage so it cannot read Secrets or other sensitive resource types — the recommended ClusterRole in the plugin documentation does not grant this access by default. After patching, operators should audit any sensitive values that may have been exposed through the Kubernetes plugin prior to the fix.

The advisory was published by Backstage maintainer freben on GitHub and tracked by Red Hat's Product Security team via Bugzilla. The vulnerability received moderate community attention on social platforms including Bluesky and Mastodon (infosec.exchange), consistent with its medium severity rating. No major vendor statements beyond the GitHub advisory and Red Hat tracking entry have been identified (Red Hat, Github Advisory).