GHSA-w658-mh9p-ww8f: Path Traversal
Summary
@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://<host>/trusted/%2e%2e/attacker/repo/blob/main/catalog-info.yaml matches a https://<host>/trusted/ pattern as a raw string, but resolves to and is fetched from https://<host>/attacker/repo/... when its content is read.
An authenticated user with permission to register catalog locations (catalog.location.create) can use this to have an entity from an untrusted source admitted as if it originated from a trusted location scope.
Impact
The crossed boundary is the operator-configured catalog ingestion policy: entity content from outside the trusted location scope is ingested as if it were within it. Downstream consequences depend on deployment configuration, for example actions taken with integration credentials by processors or scaffolder when acting on the ingested entity. The assessment of this report found no basis for impact claims beyond the ingestion policy boundary itself.
Patches
This is fixed in @backstage/plugin-catalog-backend 3.9.2 (Backstage release 1.54.10) and 4.0.2 (Backstage release 1.56.1). Version 4.0.1 as published is not fixed.
Workarounds
No complete workaround is available for deployments that rely on URL location patterns to restrict catalog kinds. Restricting location registration permissions reduces exposure.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@backstage/plugin-catalog-backendto a version that resolves this vulnerability.Fixed in 4.0.2 - Upgrade
Upgrade
npm/@backstage/plugin-catalog-backendto a version that resolves this vulnerability.Fixed in 3.9.2 - Upgrade
Upgrade
@backstage/plugin-catalog-backendto a version that resolves this vulnerability.Fixed in 3.9.2 - Upgrade
Upgrade
@backstage/plugin-catalog-backendto a version that resolves this vulnerability.Fixed in 4.0.2 - Compensating control
Restrict permissions to register catalog locations, especially the catalog.location.create permission, to reduce exposure.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments that use catalog.rules location patterns to restrict catalog kinds to trusted URL prefixes are exposed when those rules are evaluated against user-supplied URL locations.
What access does an attacker need?
An attacker needs to be authenticated and have the catalog.location.create permission, which allows them to register catalog locations.
How can the trusted-location restriction be bypassed?
The attacker can submit a URL that raw-string matches a trusted prefix but contains percent-encoded dot segments. URL readers canonicalize those segments when fetching content, causing the fetch to resolve outside the trusted scope.
What is the resulting impact?
An entity from an untrusted source can be admitted to the catalog as though it originated from an allowed location.