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
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
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
Impact A path traversal vulnerability in the TechDocs local generator allows attackers to read arbitrary files from the host filesystem when Backstage is configured with techdocs.generator.runIn: local.
When processing documentation from untrusted sources, symlinks within the docs directory are followed by MkDocs during the build process. File contents are embedded into generated HTML and exposed to users who can view the documentation.
Patches This vulnerability is fixed in @backstage/plugin-techdocs-node version X.X.X. Users should upgrade to this version or later.
Workarounds - Switch to runIn: docker in your app-config.yaml: yaml techdocs: generator: runIn: docker - Restrict write access to TechDocs source repositories to trusted users only
References - https://backstage.io/docs/features/techdocs/configuration
Impact
When TechDocs is configured with runIn: local, a malicious actor who can submit or modify a repository's mkdocs.yml file can execute arbitrary Python code on the TechDocs build server via MkDocs hooks configuration.
Patches
Upgrade to @backstage/plugin-techdocs-node version 1.13.11, 1.14.1 or later. The fix introduces an allowlist of supported MkDocs configuration keys. Unsupported configuration keys (including hooks) are now removed from mkdocs.yml before running the generator, with a warning logged to indicate which keys were removed.
Note: Users of @techdocs/cli should also upgrade to the latest version, which includes the fixed @backstage/plugin-techdocs-node dependency.
Workarounds
If you cannot upgrade immediately:
1. 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. 2. Restrict repository access: Limit who can modify mkdocs.yml files in repositories that TechDocs processes. Only allow trusted contributors. 3. Manual review: Implement PR review requirements for changes to mkdocs.yml files to detect malicious hooks configurations before they are merged. 4. Downgrade MkDocs: Use MkDocs < 1.4.0 (e.g., 1.3.1) which does not support hooks. Note: This may limit access to newer MkDocs features.
Note: Building documentation in CI/CD pipelines using @techdocs/cli does not mitigate this vulnerability, as the CLI uses the same vulnerable @backstage/plugin-techdocs-node package.
References
MkDocs Hooks Documentation MkDocs 1.4 Release Notes TechDocs Architecture
Backstage is an open platform for building developer portals. The Backstage scaffolder-backend plugin uses a templating library that requires sandbox, as it by design allows for code injection. The library used for this sandbox so far has been vm2, but in light of several past vulnerabilities and existing vulnerabilities that may not have a fix, the plugin has switched to using a different sandbox library. A malicious actor with write access to a registered scaffolder template could manipulate the template in a way that allows for remote code execution on the scaffolder-backend instance. This was only exploitable in the template YAML definition itself and not by user input data. This is vulnerability is fixed in version 1.15.0 of @backstage/plugin-scaffolder-backend.