Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
`@backstage/plugin-catalog-backend` matches URL-type locations against `catalog.rules` location patterns using the raw URL string submitted by the user, while URL readers resolve that same string in canonical form when fetching the location's content. A URL can therefore be crafted so that it appears to belong to a trusted location scope during rule evaluation, but is fetched from a different scope. Details When a deployment restricts catalog kinds to trusted URL prefixes using `catalog.rules` location patterns, `DefaultCatalogRulesEnforcer` applies glob matching directly to the raw `location.target` string. The URL readers used for ingestion resolve the same target in canonical form, including normalizing percent-encoded dot segments. A registered location such as `https:// /trusted/%2e%2e/attacker/repo/blob/main/catalog-info.yaml` matches a `https:// /trusted/**` pattern as a raw string, but resolves to and is fetched from `https:// /attacker/repo/...` when its…
Recommended action: Upgrade to 4.0.2 or 3.9.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 3.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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
Recommended action: Upgrade to 1.26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches This vulnerability has been patched in both the frontend and backend implementations. The default Link component from @backstage/core-components will now reject javascript: URLs, and there is a global override of window.open to do the same. In addition the catalog model as well as the catalog backend now has additional validation built in that prevents javascript: URLs in known annotations. Workarounds The general practice of limiting access to modifying catalog content and requiring code reviews greatly helps mitigate this vulnerability. For more information If you have any questions or comments about this advisory: Open an issue in the Backstage repository Visit our chat, linked to in the Backstage…
Recommended action: Upgrade to 1.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.