Impact
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.
Patches
This has been fixed in the 1.26.0 release of the @backstage/plugin-catalog-backend package.
References
If you have any questions or comments about this advisory:
Open an issue in the Backstage repository Visit our Discord, linked to in Backstage README
Impact
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.
Patches
This has been fixed in the 1.10.13 release of the @backstage/plugin-techdocs-backend package.
References
If you have any questions or comments about this advisory:
Open an issue in the Backstage repository Visit our Discord, linked to in Backstage README
Impact
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.
Patches
This has been fixed in the 1.10.13 release of the @backstage/plugin-techdocs-backend package.
References
If you have any questions or comments about this advisory:
Open an issue in the Backstage repository Visit our Discord, linked to in Backstage README
A flaw was found in Red Hat Developer Hub (RHDH) in the catalog-import function. The vulnerability is that the catalog-import function leaks GitLab access tokens on the frontend. This leakage occurs when the base64 encoded GitLab token includes a newline at the end of the string. The sanitized error displayed on the frontend inadvertently includes the raw access token, which should never be exposed to frontend users.
The impact of this vulnerability is significant. An attacker, upon gaining access to this token, could potentially execute a range of malicious activities depending on the token's permissions. These activities could include pushing malicious code to repositories, deleting resources in Git, revoking or generating new keys, or even signing code illegitimately.
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 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 docsdir 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.