CVE-2026-106510

Backstage is an open framework for building developer portals. Prior to versions 3.3.1, 3.4.1, 4.0.3 and 4.1.0, the @backstage/plugin-scaffolder-backend package is affected by sensitive information exposure in scaffolder. An authenticated Backstage user who can read another user's Scaffolder task may receive internal execution data.

The @backstage/backend-defaults package prior to 0.17.8 is affected by improper access control in backend action invocation. An authenticated user could invoke actions that an operator had excluded through action configuration. Existing action permissions and downstream authorization remain enforced.

The @backstage/plugin-kubernetes-backend package prior to 0.21.9 allows an authenticated user with standard Kubernetes resource read permission to retrieve sensitive values that the plugin is designed to mask. This can expose credentials and other confidential material held in connected clusters, limited to resources the Backstage service account is permitted to read.

The @backstage/plugin-scaffolder-backend-module-confluence-to-markdown package prior to 0.3.25 is affected by improper input validation in the Confluence to Markdown scaffolder module. This could allow an attacker to influence file write operations during template execution if a Backstage user runs a template that processes attacker-influenced Confluence content.

Backstage before version 4.1.0 in the @backstage/plugin-scaffolder-backend package could expose secret-derived values in Scaffolder task logs. Deployments that configure sensitive scaffolder.defaultEnvironment.secrets and allow an attacker to create or modify Scaffolder templates are affected. A template author could cause secret-derived values used during template iteration to be persisted and exposed to users who can access the resulting task logs.

Backstage before version 3.9.1 in the @backstage/plugin-catalog-backend package has inconsistent catalog property permission evaluation. In deployments that use affected value-based catalog permission conditions as a confidentiality boundary, an authenticated user could receive catalog entity data that policy authors intended to restrict.

The @backstage/plugin-catalog-backend package in Backstage before 3.9.1 inconsistently enforces allowed location types during catalog processing. Under certain configurations, the backend could process location types that were not intended to be allowed, potentially leading to unintended file access on the backend host.

Backstage before version 0.17.8 in the @backstage/backend-defaults package has improper input validation in cloud storage url readers. An attacker with write access to a cloud storage bucket used by Backstage could craft object names that could collide with protected files in the output directory. In certain deployment configurations, this could lead to content injection.

Cloud storage catalog providers in Backstage before 1.54.6 did not sufficiently validate object paths. A principal able to create or rename objects in a configured Azure Blob Storage or AWS S3 catalog source could cause catalog descriptors to be read from outside the intended storage boundary, limited to locations reachable with the backend's configured credentials.

Backstage before version 0.6.17 in the @backstage/plugin-proxy-backend package has improper input validation in proxy-backend. An authenticated Backstage user could craft a request URL that causes the proxy-backend to forward the request to a path outside the configured base path on the target server. This is limited to target servers already configured as proxy endpoints and requires Backstage authentication by default.