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.
Impact
An authenticated Backstage user subject to a DENY policy for search document types could receive search results they were not authorized to view. This affects deployments with permission.enabled: true and an Elasticsearch or OpenSearch search backend.
Patches
- Upgrade @backstage/plugin-search-backend to 2.1.6 - Upgrade @backstage/plugin-search-backend-module-elasticsearch to 1.8.7
Workarounds
If you are unable to upgrade immediately:
- Temporarily modify permission policies to use CONDITIONAL decisions with per-result filtering rather than blanket DENY for search document types - Restrict Elasticsearch/OpenSearch index access at the cluster level so that the search service account can only reach expected Backstage indices, limiting the blast radius if the authorization bypass is triggered.
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 of the service account used to reach each cluster so that it cannot read sensitive resource types. The recommended ClusterRole in the Kubernetes plugin configuration documentation does not grant this access.
Impact
An authenticated user who can execute an affected template and control its repository file location may cause generated content to be written outside the task workspace, within locations writable by the Backstage backend process.
Patches
Patched in @backstage/plugin-scaffolder-backend-module-confluence-to-markdown version 0.3.25
Workarounds
- Restrict execution of templates using the affected action to trusted users. - Remove or disable the affected action until the patched package is deployed.
Impact
Insufficient input validation in the Confluence to Markdown scaffolder module could allow an attacker to influence file write operations during template execution. Exploitation requires a Backstage user to run a template that processes attacker-influenced Confluence content.
Patches
Patched in @backstage/plugin-scaffolder-backend-module-confluence-to-markdown version 0.3.25
Workarounds
If unable to update immediately:
- Restrict Confluence edit access to trusted users. - Review Confluence page content before running scaffolder templates against untrusted pages.
Impact
An attacker who can provide configuration to a TechDocs build may execute code in the generator runtime. Impact is greatest when documentation generation runs with backend credentials or host access.
Patches
Patched in @backstage/plugin-techdocs-node version 1.15.4.
Workarounds
Use external TechDocs generation in an isolated environment without sensitive credentials or host access. Restrict and review changes to documentation configuration before generation.
Backstage is an open framework for building developer portals. Prior to 1.14.6, the @backstage/plugin-techdocs-node package is affected by configuration bypass in techdocs mkdocs.yml sanitization. Insufficient validation of MkDocs configuration during TechDocs generation could allow an authenticated user who can register or modify documentation sources to execute arbitrary commands in the build environment. Impact is limited to resources accessible to the TechDocs backend or build container. This issue is fixed in versions 1.14.6 and 1.15.4.
Impact
An authenticated user who can register catalog entities can provide a crafted mkdocs.yml causing arbitrary OS command execution on the TechDocs build host when the docs are built.
Patches
Patched in @backstage/plugin-techdocs-node, version 1.15.4.
Workarounds
If you cannot upgrade immediately:
- Switch to techdocs.builder: external to isolate TechDocs builds in a container. - Restrict who can register catalog entities with TechDocs annotations. - Audit existing catalog entities for suspicious markdownextensions values in their mkdocs.yml files.
Impact
When TechDocs is configured to build documentation locally or in a container, a user with write access to a registered repository can include configuration values in mkdocs.yml that cause arbitrary code execution during the documentation build process.
Patches
Patched in @backstage/plugin-techdocs-node version 1.15.4
Workarounds
- Configure TechDocs with techdocs.generator.runIn: 'docker' instead of 'local' to provide container isolation, though this does not fully mitigate the risk. - Restrict write access to repositories registered in the Backstage catalog to trusted users.
Impact
When using the local TechDocs publisher (techdocs.publisher.type: 'local'), it was possible for the documentation serving endpoint to follow filesystem references outside the intended documentation tree, potentially exposing host files to authenticated users.
This is mitigated by the fact that exploration requires preconditions that do not arise through normal MkDocs operation. Cloud-based publishers (S3, GCS, Azure Blob Storage) are not affected.
Patches
Patched in @backstage/plugin-techdocs-node version 1.15.4
Workarounds
If you cannot upgrade immediately, consider switching to an external store for published TechDocs content (e.g. awsS3, googleGcs, or azureBlobStorage publishers)
Backstage is an open framework for building developer portals. Prior to 1.15.4, the @backstage/plugin-techdocs-node package is affected by techdocs arbitrary file read via mkdocs snippets. Unsafe path resolution in TechDocs source tree handling allows an authenticated user who can register documentation sources to include content from outside the intended documentation boundary. Depending on deployment, this may expose files readable by the build process. This issue is fixed in version 1.15.4.
Impact
An authenticated Backstage user with permission to create and read relevant scaffolder tasks may be able to infer confidential task data under specific conditions. Successful exploitation requires retained task secrets, visibility of a target task, knowledge of the secret structure, and repeated requests.
Patches
Patched in @backstage/plugin-scaffolder-backend version 4.1.0
Workarounds
- At the gateway or reverse proxy, reject task-list requests that specify custom ordering, or allow ordering only by createdat, status, and createdby. - Restrict scaffolder task creation and task read permissions to trusted users, preferably using owner-based task-read conditions. - Disabling task recovery can reduce secret retention after a task is claimed, but it does not protect secrets in queued tasks and should not be treated as complete mitigation.
Impact
Users with the ability to commit changes to a repository that uses TechDocs can circumvent the MkDocs configuration file sanitizer introduced in response to CVE-2026-25153 and execute arbitrary code on the TechDocs backend host during documentation generation.
Patches
Patched in@backstage/plugin-techdocs-node version 1.15.4
Workarounds
If you cannot upgrade immediately:
- Use Docker mode with restricted access: Configure TechDocs with runIn: docker instead of runIn: local. This provides container isolation, though it does not fully mitigate the risk. - Limit repository write access to trusted parties, since exploitation requires the ability to commit files to a repository with TechDocs enabled. - Review incoming changes to MkDocs configuration files as part of your code review process.
Impact
An authenticated user who can create and read scaffolder tasks may be able to observe sensitive values in task logs in deployments with restrictive action permissions and affected templates. Exploitation requires a denied action whose input contains such a value.
Patches
Patched in @backstage/plugin-scaffolder-backend version 4.1.0
Workarounds
- Restrict scaffolder task creation and task-log reading to trusted users. - Avoid placing centrally managed sensitive values in inputs to actions that may be denied until upgrading.
References
- Backstage threat model - Backstage permissions overview
Impact
An authenticated user with access to affected Scaffolder templates could bypass configured action restrictions. Depending on integration credentials, this could grant unauthorized access to repositories and related source-control resources.
Patches
Patched in @backstage/plugin-scaffolder-backend version 4.1.0
Workarounds
- Restrict affected Scaffolder actions to trusted users and configure source-control integrations with least-privilege credentials.
Impact
Under specific template and failure conditions, an authenticated user may be able to retrieve sensitive values from Scaffolder task events. This can expose backend-managed credentials used during task execution.
Patches
Patched in @backstage/plugin-scaffolder-backend version 4.1.0
Workarounds
- Restrict Scaffolder template execution and task-event access to trusted users until the patched version is deployed.
Impact
An authenticated Backstage user who can read another user's Scaffolder task may receive internal execution data. In deployments where that data contains credentials for an external service, this may permit disclosure and unauthorized changes in that external service.
Patches
Patched in @backstage/plugin-scaffolder-backend version 4.1.0
Workarounds
- Configure scaffolder.task.read with the isTaskOwner condition so users can only read tasks they created. - Restrict affected integrations and workflows to trusted operators until an upgrade is available.
Impact
An authenticated user with permission to create and access Scaffolder tasks may, under specific timing and deployment conditions, affect files accessible to the Backstage backend. If backend application files are writable, the confidentiality, integrity, and availability of the backend may be compromised.
Patches
Patched in @backstage/plugin-scaffolder-backend version 4.1.0
Workarounds
- Restrict Scaffolder task creation and task-read permissions to trusted users through the permission policy. - Limit who can register or modify templates and which Scaffolder actions may execute. - Run backend application files read-only outside a dedicated, least-privilege Scaffolder working directory.
References
- Authorizing Scaffolder tasks, parameters, steps, and actions
Impact
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 in task logs, exposing those values to users with access to the resulting task logs.
Patches
Patched in @backstage/plugin-scaffolder-backend version 4.1.0
Workarounds
- Restrict permission to create or update Template entities to fully trusted parties, as recommended by the Backstage threat model. - If that restriction cannot be guaranteed, remove sensitive values from scaffolder.defaultEnvironment.secrets until a patched version is available.
No complete workaround is known that preserves both untrusted template authoring and access to sensitive default-environment secrets.
Impact
An authenticated Backstage user could craft a catalog entity with placeholder directives that reference resources outside the entity's source repository. Under certain configurations, this could allow access to data not intended to be available to the user.
Patches
Patched in @backstage/plugin-catalog-backend version 3.9.1
Workarounds
If you're not able to update immediately:
- Limit the scope of integration credentials (e.g., GitHub tokens) to only the repositories that Backstage needs to access.
Backstage is an open framework for building developer portals. Prior to 3.9.1, the @backstage/plugin-catalog-backend package is affected by 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. This issue is fixed in version 3.9.1.
Impact
Under certain configurations, the catalog backend could process location types that were not intended to be allowed, potentially leading to unintended file access on the backend host.
Patches
Patched in @backstage/plugin-catalog-backend version 3.9.1
Workarounds
No practical workarounds are available. Upgrade to the patched version.
Impact
Several Passport-based authentication providers use shared OAuth profile normalization from @backstage/plugin-auth-node. Affected versions may pass an email to email-based sign-in resolvers even when verification metadata supplied for that same address is explicitly negative. The ID-token-only fallback likewise did not consistently respect emailverified: false.
Exploitation requires a deployment where an admitted identity-provider user can supply or change an email address without verification and Backstage uses that profile email to resolve catalog identities. In that configuration, the user may be able to assume another catalog identity and obtain its associated access and permissions.
An absent emailverified claim is not by itself considered an affected condition. Some providers rely on authoritative organizational provisioning and intentionally omit the optional claim. Operators using email-based sign-in resolution must ensure that the configured provider restricts sign-in to the intended user population and supplies an authoritative email address, either through provider verification or trusted immutable provisioning.
This advisory covers the shared Passport profile normalization path when the selected profile email itself carries verified: false, when a matching raw provider email carries emailverified: false, or when an email obtained only from an ID token carries emailverified: false. It does not apply verification metadata from a different address or from a separate ID token to an independently fetched provider-profile email.
The generic OIDC provider follows a separate profile transform and is covered by GHSA-826h-28h9-65hg. The two advisories are complementary; deployments using both affected paths should apply both package updates. VMware Cloud uses a separate custom token transformation and is not changed by this patch.
Patches
Fixed in @backstage/plugin-auth-node versions 0.6.15 and 0.7.5. Users remaining on the 0.6.x line should upgrade to at least 0.6.15; users on 0.7.x should upgrade to at least 0.7.5.
The patched packages were released with Backstage v1.49.7 and Backstage v1.54.7, respectively. The fix is also present on master in commit 507e65a.
Workarounds
- Require the identity provider to verify user-controlled email addresses before allowing sign-in. - Ensure profile emails are immutable and provisioned from a trusted organizational source. - Use a sign-in resolver that does not depend on the profile email. - Use a custom profile transform that omits an email when matching provider metadata explicitly marks it as unverified.
Impact
An authenticated internal user who can execute the affected actions may cause the backend to contact unintended destinations and disclose Sentry integration credentials. Subsequent impact depends on network reachability and the privileges granted to the configured token.
Patches
Upgrade @backstage/plugin-scaffolder-backend-module-sentry to version 0.3.8 or later. The fixed package is available in Backstage v1.54.8 and Backstage v1.55.0.
The update removes custom action-level apiBaseUrl values. Move any such value to scaffolder.sentry.apiBaseUrl before upgrading.
Workarounds
- Disable the affected actions until the patched package is deployed. - Restrict scaffolder.action.execute permission for the affected Sentry actions to trusted users and templates.
Impact
Deployments using event-driven updates in the Bitbucket Server catalog provider may ingest catalog locations from repositories that are excluded by the provider's configured project, repository, or archived-repository filters.
An authenticated Bitbucket Server user who can push to a filtered-out repository that remains readable by the configured Backstage integration can trigger a legitimate repository event. The affected event path may then add a Location for that repository even though scheduled discovery excludes it. This can cause catalog entities and metadata to be ingested from a repository that the operator did not intend to trust.
Deployments that do not enable event support for the Bitbucket Server catalog provider, do not configure repository filters, or whose integration credentials cannot read the filtered-out repositories are not affected.
Patches
Upgrade @backstage/plugin-catalog-backend-module-bitbucket-server to version 0.5.15 or later. The fixed package is available in Backstage v1.55.0.
Workarounds
- Disable event-driven updates for the Bitbucket Server catalog provider and rely on scheduled discovery until the patched package is deployed. - Restrict the configured Bitbucket Server integration credentials so that they cannot read repositories that must remain outside the catalog trust boundary.
Impact
The Cloudflare Access auth provider verifies a token's signature and team issuer, but affected versions do not verify that the token was issued for the Backstage application. A user holding a valid token for another Access application in the same Cloudflare Zero Trust team may therefore be able to authenticate to Backstage if that token reaches the auth endpoint without the Backstage application's audience already being enforced upstream.
Cloudflare Access normally evaluates the protected application before forwarding requests. The reported reproduction exercises the provider directly and does not demonstrate bypass through the ordinary Cloudflare-protected Backstage URL. Relevant deployment topologies include direct origin access, alternate routes around the intended Access application, or another proxy forwarding the assertion unchanged.
A successful sign-in also depends on the deployment's sign-in resolver mapping the presented identity to a Backstage user. The resulting impact depends on the permissions assigned to that identity.
Patches
Upgrade @backstage/plugin-auth-backend-module-cloudflare-access-provider to version 0.5.0 or later. The fixed package is available in Backstage v1.55.0.
This is a breaking configuration change. Before upgrading, set auth.providers.cfaccess.audience to the Audience (AUD) tag for the Backstage application in Cloudflare Zero Trust:
yaml auth: providers: cfaccess: teamName: example audience: ${AUTHCFACCESSAUDIENCE}
Workarounds
- Restrict access to the Backstage auth endpoint to the intended Cloudflare Access application. - Use a custom authenticator that validates the application audience. - Disable the provider until the patched package can be deployed.
Impact
An operator can configure overlapping proxy paths with different credential requirements. When a parent path permits unauthenticated access and a nested path requires credentials, the parent exemption can also cover requests handled by the nested proxy. An unauthenticated caller may therefore reach the nested upstream through Backstage, including with static upstream credentials configured for that proxy.
Exploitation requires this specific overlapping route configuration. The resulting confidentiality and integrity impact depends on the capabilities exposed by the nested upstream.
Patches
Upgrade @backstage/plugin-proxy-backend to version 0.6.18 or later. The fixed package is available in Backstage v1.55.0.
Workarounds
- Avoid nesting a credential-protected proxy path below a path configured with dangerously-allow-unauthenticated. - Apply the same credential requirement to overlapping proxy paths. - Restrict direct network access to the Backstage backend until the patched package is deployed.
Impact
An authenticated attacker with control over a TechDocs source repository could cause a documentation build to retrieve and publish data from network locations reachable by the build environment. Exposure depends on deployment topology, build mode, and target endpoint protections. Modern cloud metadata services that require tokens or special headers are not directly accessible through the affected behavior.
Patches
Upgrade @backstage/plugin-techdocs-node to a patched version for the applicable release line:
- 1.14.x: upgrade to 1.14.7 or later in that line, available in Backstage v1.50.6. - 1.15.x: upgrade to 1.15.5 or later, available in Backstage v1.54.8. - Current mainline: upgrade to 2.0.0 or later, available in Backstage v1.55.0.
The update removes MkDocs plugins outside the built-in allowlist. To retain additional plugins, review them and configure techdocs.generator.mkdocs.dangerouslyAllowAdditionalPlugins, or supply dangerouslyAllowAdditionalPlugins when creating the generator directly. Plugins supplied through defaultPlugins remain permitted.
Workarounds
- Restrict control of TechDocs source repositories and catalog registration to trusted maintainers. - Run documentation builders with outbound access to private and link-local networks denied. - Require token- or header-protected cloud instance metadata services.
Impact A Server-Side Request Forgery (SSRF) vulnerability exists in @backstage/plugin-auth-backend when auth.experimentalClientIdMetadataDocuments.enabled is set to true. The CIMD metadata fetch validates the initial clientid hostname against private IP ranges but does not apply the same validation after HTTP redirects. The practical impact is limited. The attacker cannot read the response body from the internal request, cannot control request headers or method, and the feature must be explicitly enabled via an experimental flag that is off by default. Deployments that restrict allowedClientIdPatterns to specific trusted domains are not affected.
### Patches
Patched in @backstage/plugin-auth-backend version 0.27.1. The fix disables HTTP redirect following when fetching CIMD metadata documents.
### Workarounds
Disable the experimental CIMD feature by removing or setting auth.experimentalClientIdMetadataDocuments.enabled to false in your app-config. This is the default configuration. Alternatively, restrict allowedClientIdPatterns to specific trusted domains rather than using the default wildcard pattern.
### References
- IETF Client ID Metadata Document draft - MCP Authorization Specification - Client ID Metadata Documents
Impact
The experimental OIDC provider in @backstage/plugin-auth-backend is vulnerable to a redirect URI allowlist bypass. Instances that have enabled experimental Dynamic Client Registration or Client ID Metadata Documents and configured allowedRedirectUriPatterns are affected.
A specially crafted redirect URI can pass the allowlist validation while resolving to an attacker-controlled host. If a victim approves the resulting OAuth consent request, their authorization code is sent to the attacker, who can exchange it for a valid access token.
This requires victim interaction and that one of the experimental features is explicitly enabled, which is not the default.
Patches
Upgrade to @backstage/plugin-auth-backend version 0.27.1 or later.
Workarounds
Disable experimental Dynamic Client Registration and Client ID Metadata Documents features if they are not required.
References
- RFC 6749 Section 3.1.2 - Redirection Endpoint