Rugvip

**Name of the Vulnerable Software and Affected Versions** Backstage versions prior to 0.12.2 Backstage versions prior to 0.13.2 Backstage versions prior to 0.14.1 Backstage versions prior to 0.15.0 **Description** The `FetchUrlReader` component in Backstage’s `@backstage/backend-defaults` automatically followed HTTP redirects. This allowed an attacker controlling a host listed in `backend.reading.allow` to redirect requests to internal or sensitive URLs not on the allowlist, bypassing URL allowlist security controls. This is a Server-Side Request Forgery (SSRF) condition that could allow access to internal resources, but it does not allow attackers to include additional request headers. The vulnerable component is used by the catalog and other plugins to fetch content from URLs. **Recommendations** Upgrade to Backstage version 0.12.2 or later. Upgrade to Backstage version 0.13.2 or later. Upgrade to Backstage version 0.14.1 or later. Upgrade to Backstage version 0.15.0 or later. Restrict `backend.reading.allow` to only trusted hosts that you control and that do not issue redirects. Ensure allowed hosts do not have open redirect vulnerabilities. Use network-level controls to block access from Backstage to sensitive internal endpoints.

**Name of the Vulnerable Software and Affected Versions** Backstage versions prior to 0.1.17 **Description** The `resolveSafeChildPath` utility function in `@backstage/backend-plugin-api` did not properly validate symlink chains and dangling symlinks, leading to a path traversal issue. An attacker could bypass path validation by creating symlink chains or dangling symlinks that resolve outside the allowed directory. This function is used by Scaffolder actions and other backend components to control file operations within designated directories. **Recommendations** Upgrade to version 0.1.17 or later. Run Backstage in a containerized environment with limited filesystem access. Restrict template creation to trusted users.

**Name of the Vulnerable Software and Affected Versions** Backstage versions prior to 0.12.2, 0.13.2, 0.14.1, and 0.15.0 @backstage/plugin-scaffolder-backend versions prior to 2.2.2, 3.0.2, and 3.1.1 @backstage/plugin-scaffolder-node versions prior to 0.11.2 and 0.12.3 **Description** The software is susceptible to symlink-based path traversal attacks. An attacker who can create and execute Scaffolder templates can exploit symlinks to read arbitrary files via the `debug:log` action, delete arbitrary files via the `fs:delete` action, and write files outside the workspace through archive extraction (tar/zip) containing malicious symlinks. This impacts any deployment where users can create or execute Scaffolder templates. The `debug:log` action can be exploited by creating a symlink pointing to sensitive files such as `/etc/passwd`, configuration files, and secrets. The `fs:delete` action can be exploited by creating symlinks pointing outside the workspace. Archive extraction utilities are vulnerable to malicious symlinks within tar or zip files. **Recommendations** Upgrade `@backstage/backend-defaults` to version 0.12.2, 0.13.2, 0.14.1, or 0.15.0. Upgrade `@backstage/plugin-scaffolder-backend` to version 2.2.2, 3.0.2, or 3.1.1. Upgrade `@backstage/plugin-scaffolder-node` to version 0.11.2 or 0.12.3. Limit access to creating and updating templates. Restrict who can create and execute Scaffolder templates using the permissions framework. Audit existing templates for symlink usage. Run Backstage in a containerized environment with limited filesystem access.

**Name of the Vulnerable Software and Affected Versions** Backstage permission plugin backend versions prior to 0.6.0 **Description** A vulnerability in the Backstage permission plugin backend allows callers to extract some information about the conditional decisions returned by the permission policy installed in the permission backend. If the permission system is not in use or if the installed permission policy does not use conditional decisions, there is no impact. **Recommendations** For versions prior to 0.6.0, update to version 0.6.0 to resolve the issue. As a temporary workaround, administrators of the permission policies should ensure that they are crafted in such a way that conditional decisions do not contain any sensitive information.

Name of the Vulnerable Software and Affected Versions: @backstage/plugin-scaffolder-node versions prior to 0.4.12, 0.5.1, and 0.6.1 Description: A vulnerability is identified in Backstage Scaffolder template functionality where Server-Side Template Injection (SSTI) can be exploited to perform Git config injection. This allows an attacker to capture privileged git tokens used by the Backstage Scaffolder plugin, resulting in unauthorized access to sensitive resources in git. The impact is considered medium severity as the Backstage Threat Model recommends restricting access to adding and editing templates in the Backstage Catalog plugin. Recommendations: For versions prior to 0.4.12, upgrade to version 0.4.12 or later. For versions prior to 0.5.1, upgrade to version 0.5.1 or later. For versions prior to 0.6.1, upgrade to version 0.6.1 or later. As a temporary workaround, ensure that templates do not change git config.

**Name of the Vulnerable Software and Affected Versions** @backstage/plugin-app-backend versions prior to 0.3.75 **Description** The issue concerns the configuration supplied through `APP CONFIG *` environment variables, where the visibility defined in the configuration schema is unexpectedly ignored. This behavior leads to a risk of potentially exposing sensitive configuration details intended to remain private or restricted to backend processes. **Recommendations** For versions prior to 0.3.75, upgrade to version 0.3.75 of the @backstage/plugin-app-backend package to mitigate the issue. 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.

Name of the Vulnerable Software and Affected Versions: @backstage/plugin-techdocs-backend versions prior to 1.10.13 Description: The issue allows an attacker with control of the TechDocs storage buckets to inject executable scripts in the TechDocs content. These scripts will be executed in the victim's browser when browsing documentation or navigating to an attacker-provided link. This can lead to cross-site scripting attacks. Recommendations: For versions prior to 1.10.13, upgrade to the 1.10.13 release of the @backstage/plugin-techdocs-backend package to fix the issue. As a temporary workaround, consider restricting access to the TechDocs content to minimize the risk of exploitation.

Name of the Vulnerable Software and Affected Versions: @backstage/plugin-catalog-backend versions prior to 1.26.0 Description: A malicious actor with authenticated access to a Backstage instance with the catalog backend plugin installed can interrupt the service using a specially crafted query to the catalog API. This issue is related to an uncontrolled modification of object prototype attributes, which can be exploited by a remote attacker to cause a denial of service by sending a specially crafted API request. Recommendations: For versions prior to 1.26.0, upgrade to the 1.26.0 release of the @backstage/plugin-catalog-backend package to fix the issue. As a temporary workaround, consider restricting access to the catalog API to minimize the risk of exploitation. There are no known workarounds for this issue other than upgrading to the fixed version.

**Name of the Vulnerable Software and Affected Versions** @backstage/plugin-scaffolder-backend versions prior to 1.15.0 **Description** The Backstage scaffolder-backend plugin uses a templating library that requires a sandbox, allowing for code injection. A malicious actor with write access to a registered scaffolder template could manipulate the template for remote code execution on the scaffolder-backend instance. This was only exploitable in the template YAML definition itself, not by user input data. **Recommendations** For versions prior to 1.15.0, update to version 1.15.0 of @backstage/plugin-scaffolder-backend to fix the issue. As a temporary workaround, consider controlling access to scaffolder templates and performing manual reviews of changes to these templates, as recommended by the Backstage Threat Model.

**Name of the Vulnerable Software and Affected Versions** @backstage/catalog-model versions prior to 1.2.0 @backstage/core-components versions prior to 0.12.4 @backstage/plugin-catalog-backend versions prior to 1.7.2 **Description** This issue 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. 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. **Recommendations** For `@backstage/catalog-model` versions prior to 1.2.0, update to version 1.2.0 or greater. For `@backstage/core-components` versions prior to 0.12.4, update to version 0.12.4 or greater. For `@backstage/plugin-catalog-backend` versions prior to 1.7.2, update to version 1.7.2 or greater. As a temporary workaround, consider limiting access to modifying catalog content and requiring code reviews to mitigate this issue.

Name of the Vulnerable Software and Affected Versions: @backstage/plugin-scaffolder-backend versions prior to 0.15.14 Description: A malicious actor with write access to a registered scaffolder template can manipulate the template to write files to arbitrary paths on the scaffolder-backend host instance. This issue can also be exploited through user input when executing a template, although this method does not allow control of the injected file's contents unless the template is specifically crafted to provide such control. Recommendations: For versions prior to 0.15.14, update to version 0.15.14 to resolve the issue. As a temporary workaround, consider restricting access and requiring reviews when registering or modifying scaffolder templates to mitigate the attack.

**Name of the Vulnerable Software and Affected Versions** @backstage/plugin-scaffolder-backend versions prior to 0.15.9 **Description** A malicious actor could read sensitive files from the environment where Scaffolder tasks are run 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 issue 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. **Recommendations** For versions prior to 0.15.9, update to the 0.15.9 release of @backstage/plugin-scaffolder-backend to patch the vulnerability. As a temporary workaround, consider restricting access to create and register templates in the Backstage catalog to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** @backstage/techdocs-common versions prior to 0.6.4 **Description** A malicious internal actor can upload documentation content with malicious scripts, which would normally be sanitized by the TechDocs frontend. However, by tricking a user into visiting the content via the `TechDocs API`, the content sanitization 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. **Recommendations** For versions prior to 0.6.4, update to the 0.6.4 release of `@backstage/techdocs-common` to patch the vulnerability. As a temporary workaround, consider restricting access to the `TechDocs API` to minimize the risk of exploitation. Additionally, review internal code review processes and TechDocs deployment methods to limit the ability to upload malicious content.

**Name of the Vulnerable Software and Affected Versions** @backstage/techdocs-common versions prior to 0.6.3 **Description** 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 issue 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. **Recommendations** For versions prior to 0.6.3, update to the 0.6.3 release of @backstage/techdocs-common to patch the vulnerability. As a temporary workaround, consider restricting access to the TechDocs backend API and limiting the ability to modify the `mkdocs.yml` file in the documentation source code.

**Name of the Vulnerable Software and Affected Versions** @backstage/plugin-techdocs versions prior to 0.9.5 **Description** 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. **Recommendations** For versions prior to 0.9.5, update to the 0.9.5 release of @backstage/plugin-techdocs to patch the vulnerability. As a temporary workaround, consider restricting access to upload files directly to the object store and implementing strict internal code review processes to minimize the risk of exploitation.