Backstage Catalog Backend EUVD-2026-110054

Exploitable only in deployments that use catalog.rules with URL-type ('url') location patterns to restrict which catalog kinds may be ingested from which URL prefixes; deployments not relying on URL location patterns are not exposed to the bypass. The attacker must be an authenticated user holding the catalog.location.create permission (per PR:L), so this is not remote-unauthenticated. The technique depends on the mismatch between DefaultCatalogRulesEnforcer matching the raw location.target string and URL readers canonicalizing the same URL (normalizing percent-encoded dot segments, encoded separators/backslashes, default ports) before fetching. No complete workaround exists for deployments that depend on URL location patterns to restrict catalog kinds; the vendor states that restricting location-registration permissions reduces exposure and that upgrading is the fix. Downstream consequences beyond the ingestion-policy boundary (e.g., actions by processors or scaffolder using integration credentials) depend on deployment configuration and were not substantiated by the advisory.

Signals are moderate and internally consistent rather than alarming. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N, base 6.5) describes a network-reachable, low-complexity flaw that requires an authenticated principal holding the catalog.location.create permission (PR:L), with impact limited to integrity (C:N/A:N). This aligns with the GHSA advisory: the only confirmed crossed boundary is the operator-configured catalog ingestion policy, and the advisory explicitly states it found no basis for impact claims beyond that boundary. No EPSS score is provided in the input, so exploitation probability cannot be quantified. KEV status is not indicated, so there is no confirmed active exploitation. No POC/exploit availability is asserted in the input (the references are the vendor advisory, patch commits, and release tags, not exploit code), so there is no public exploit identified at time of analysis - though the advisory does document a concrete example attack URL. The vuln.today decision label is 'this_month', consistent with a real-but-not-emergency issue: it is a genuine authorization-bypass worth patching on a normal cadence, not a high-CVSS-but-illusory problem, but it is gated behind an authenticated, specifically-permissioned user and a deployment that actually relies on catalog.rules URL patterns to restrict kinds. Teams not using URL-pattern-based catalog rules are effectively unaffected.

In a Backstage deployment that restricts catalog kinds to trusted URL prefixes via catalog.rules, an authenticated user holding catalog.location.create registers a URL location such as https://ghe.example.com/trusted/%2e%2e/attacker/repo/blob/main/catalog-info.yaml. The raw string matches the https://ghe.example.com/trusted/** pattern during rule evaluation, but the URL reader canonicalizes the percent-encoded dot segments and fetches content from the attacker-controlled path, admitting untrusted entity content as trusted. No public exploit code is identified, though the advisory documents the exact crafted-URL technique.