Vulnerabilities

The Backstage Scaffolder plugin Houses types and utilities for building scaffolder-related modules. A vulnerability is identified in Backstage Scaffolder template functionality where Server-Side Template Injection (SSTI) can be exploited to perform Git config injection. The vulnerability allows an attacker to capture privileged git tokens used by the Backstage Scaffolder plugin. With these tokens, unauthorized access to sensitive resources in git can be achieved. The impact is considered medium severity as the Backstage Threat Model recommends restricting access to adding and editing templates in the Backstage Catalog plugin. The issue has been resolved in versions `v0.4.12`, `v0.5.1` and `v0.6.1` of the `@backstage/plugin-scaffolder-node` package. Users are encouraged to upgrade to this version to mitigate the vulnerability. Users are advised to upgrade. Users unable to upgrade may ensure that templates do not change git config.

Backstage is an open framework for building developer portals. Configuration supplied through APP_CONFIG_* environment variables, for example APP_CONFIG_backend_listen_port=7007, where unexpectedly ignoring the visibility defined in configuration schema. This occurred even if the configuration schema specified that they should have backend or secret visibility. This was an intended feature of the APP_CONFIG_* way of supplying configuration, but now clearly goes against the expected behavior of the configuration system. This behavior leads to a risk of potentially exposing sensitive configuration details intended to remain private or restricted to backend processes. The issue has been resolved in version 0.3.75 of the @backstage/plugin-app-backend package. As a temporary measure, avoid supplying secrets using the APP_CONFIG_ configuration pattern. Consider alternative methods for setting secrets, such as the environment substitution available for Backstage configuration.

Backstage is an open framework for building developer portals. A malicious actor with authenticated access to a Backstage instance with the catalog backend plugin installed is able to interrupt the service using a specially crafted query to the catalog API. This has been fixed in the `1.26.0` release of the `@backstage/plugin-catalog-backend`. All users are advised to upgrade. There are no known workarounds for this vulnerability.

Backstage is an open framework for building developer portals. When using the AWS S3 or GCS storage provider for TechDocs it is possible to access content in the entire storage bucket. This can leak contents of the bucket that are not intended to be accessible, as well as bypass permission checks in Backstage. This has been fixed in the 1.10.13 release of the `@backstage/plugin-techdocs-backend` package. All users are advised to upgrade. There are no known workarounds for this vulnerability.

Backstage is an open framework for building developer portals. An attacker with control of the contents of the TechDocs storage buckets is able to inject executable scripts in the TechDocs content that will be executed in the victim's browser when browsing documentation or navigating to an attacker provided link. This has been fixed in the 1.10.13 release of the `@backstage/plugin-techdocs-backend` package. users are advised to upgrade. There are no known workarounds for this vulnerability.

`@backstage/backend-common` is a common functionality library for backends for Backstage, an open platform for building developer portals. In `@backstage/backend-common` prior to versions 0.21.1, 0.20.2, and 0.19.10, paths checks with the `resolveSafeChildPath` utility were not exhaustive enough, leading to risk of path traversal vulnerabilities if symlinks can be injected by attackers. This issue is patched in `@backstage/backend-common` versions 0.21.1, 0.20.2, and 0.19.10.

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`.

Backstage is an open platform for building developer portals. `@backstage/catalog-model` prior to version 1.2.0, `@backstage/core-components` prior to 0.12.4, and `@backstage/plugin-catalog-backend` prior to 1.7.2 are affected by a cross-site scripting vulnerability. This vulnerability allows a malicious actor with access to add or modify content in an instance of the Backstage software catalog to inject script URLs in the entities stored in the catalog. If users of the catalog then click on said URLs, that can lead to an XSS attack. This vulnerability has been patched in both the frontend and backend implementations. The default `Link` component from `@backstage/core-components` version 1.2.0 and greater will now reject `javascript:` URLs, and there is a global override of `window.open` to do the same. In addition, the catalog model v0.12.4 and greater as well as the catalog backend v1.7.2 and greater now has additional validation built in that prevents `javascript:` URLs in known annotations. As a workaround, the general practice of limiting access to modifying catalog content and requiring code reviews greatly help mitigate this vulnerability.

@backstage/plugin-scaffolder-backend is the backend for the default Backstage software templates. In affected versions a malicious actor with write access to a registered scaffolder template is able to manipulate the template in a way that writes files to arbitrary paths on the scaffolder-backend host instance. This vulnerability can in some situation also be exploited through user input when executing a template, meaning you do not need write access to the templates. This method will not allow the attacker to control the contents of the injected file however, unless the template is also crafted in a specific way that gives control of the file contents. This vulnerability is fixed in version `0.15.14` of the `@backstage/plugin-scaffolder-backend`. This attack is mitigated by restricting access and requiring reviews when registering or modifying scaffolder templates.

Backstage is an open platform for building developer portals. In affected versions the auth-backend plugin allows a malicious actor to trick another user into visiting a vulnerable URL that executes an XSS attack. This attack can potentially allow the attacker to exfiltrate access tokens or other secrets from the user's browser. The default CSP does prevent this attack, but it is expected that some deployments have these policies disabled due to incompatibilities. This is vulnerability is patched in version `0.4.9` of `@backstage/plugin-auth-backend`.

Backstage is an open platform for building developer portals. In affected versions A malicious actor could read sensitive files from the environment where Scaffolder Tasks are run. The attack is executed by crafting a custom Scaffolder template with a `github:publish:pull-request` action and a particular source path. When the template is executed the sensitive files would be included in the published pull request. This vulnerability is mitigated by the fact that an attacker would need access to create and register templates in the Backstage catalog, and that the attack is very visible given that the exfiltration happens via a pull request. The vulnerability is patched in the `0.15.9` release of `@backstage/plugin-scaffolder-backend`.

Backstage is an open platform for building developer portals, and techdocs-common contains common functionalities for Backstage's TechDocs. In `@backstage/techdocs-common` versions prior to 0.6.3, a malicious actor could read sensitive files from the environment where TechDocs documentation is built and published by setting a particular path for `docs_dir` in `mkdocs.yml`. These files would then be available over the TechDocs backend API. This vulnerability is mitigated by the fact that an attacker would need access to modify the `mkdocs.yml` in the documentation source code, and would also need access to the TechDocs backend API. The vulnerability is patched in the `0.6.3` release of `@backstage/techdocs-common`.

Backstage is an open platform for building developer portals. In versions of Backstage's Techdocs Plugin (`@backstage/plugin-techdocs`) prior to 0.9.5, a malicious internal actor can potentially upload documentation content with malicious scripts by embedding the script within an `object` element. This may give access to sensitive data when other users visit that same documentation page. The ability to upload malicious content may be limited by internal code review processes, unless the chosen TechDocs deployment method is to use an object store and the actor has access to upload files directly to that store. The vulnerability is patched in the `0.9.5` release of `@backstage/plugin-techdocs`.

Backstage is an open platform for building developer portals, and techdocs-common contains common functionalities for Backstage's TechDocs. In versions of `@backstage/tehdocs-common` prior to 0.6.4, a malicious internal actor is able to upload documentation content with malicious scripts. These scripts would normally be sanitized by the TechDocs frontend, but by tricking a user to visit the content via the TechDocs API, the content sanitazion will be bypassed. If the TechDocs API is hosted on the same origin as the Backstage app or other backend plugins, this may give access to sensitive data. The ability to upload malicious content may be limited by internal code review processes, unless the chosen TechDocs deployment method is to use an object store and the actor has access to upload files directly to that store. The vulnerability is patched in the `0.6.4` release of `@backstage/techdocs-common`.