CVE-2026-115923: Path Traversal and Catalog Rule Bypass in Backstage Catalog Backend

Backstage is an open-source framework for building developer portals, centrally managing software components, APIs, and software templates through its Software Catalog. The @backstage/plugin-catalog-backend package is responsible for ingesting entity descriptors (typically catalog-info.yaml files) from external sources such as GitHub, GitLab, or Bitbucket repositories and registering them into the catalog database.

To enforce security boundaries during ingestion, administrators configure catalog.rules in app-config.yaml. These rules govern which entity kinds (such as Component, System, or Template) are permitted to be registered from specific URL locations. In enterprise deployments, high-privilege entity kinds like Template—which define scaffolding workflows and execute backend actions—are strictly restricted to trusted repository paths using glob patterns (e.g., https://ghe.example.com/trusted/**).

CVE-2026-115923 (also tracked as GHSA-w658-mh9p-ww8f) is a path traversal vulnerability classified under CWE-22 within the DefaultCatalogRulesEnforcer implementation. When evaluating whether a user-supplied URL location matches a configured location rule, the enforcer performed pattern matching against the raw, uncanonicalized URL string. Conversely, the backend URL readers responsible for fetching the remote descriptor files parse and canonicalize the URL prior to executing the network request.

This discrepancy allows an authenticated user possessing the catalog.location.create permission to submit a URL containing percent-encoded traversal sequences (such as %2e%2e) or spoofed URL userinfo segments. The raw URL satisfies the glob matcher prefix requirement during rule enforcement, but resolves to an arbitrary, untrusted repository path on the same host when fetched by the URL reader.

The root cause of CVE-2026-115923 is a normalization discrepancy between the authorization enforcement layer (DefaultCatalogRulesEnforcer) and the data retrieval layer (UrlReaderService). In @backstage/plugin-catalog-backend, catalog rules are compiled into matcher functions that verify both the entity kind and the originating LocationSpec (type and target).

When a location rule specifies type: url and a pattern (or exact string), DefaultCatalogRulesEnforcer.isAllowed() validates the incoming location.target directly against the configured rule using the minimatch library. In unpatched versions, location.target was passed directly into minimatch with the options { nocase: true, dot: true } without undergoing URL parsing, percent-decoding, or path normalization.

Because minimatch operates purely on string representations and treats / as the segment delimiter, percent-encoded characters such as %2e (.), %2f (/), and %5c (\) are treated as literal alphanumeric characters rather than path control sequences. When a rule is configured with a double-star glob pattern like https://ghe.example.com/trusted/**, minimatch confirms that the string begins with the prefix https://ghe.example.com/trusted/ and permits any subsequent characters.

Once the rule check passes, the ingestion pipeline passes location.target to the appropriate UrlReader implementation. These readers rely on standard WHATWG URL parsers and HTTP client libraries, which decode percent-encoded characters and resolve relative dot segments (..) according to RFC 3986. Consequently, a sequence like /trusted/%2e%2e/untrusted/ is evaluated as inside /trusted/ by minimatch, but resolves to /untrusted/ during the HTTP fetch.

Prior to the fix in commit 3214dc8f15d4a08a2fd07a72a8fe4d00aeac0db4, the DefaultCatalogRulesEnforcer class in plugins/catalog-backend/src/ingestion/CatalogRules.ts evaluated location matchers by comparing the raw location.target property directly against matcher.exact and matcher.pattern:

// Vulnerable implementation in plugins/catalog-backend/src/ingestion/CatalogRules.ts
for (const matcher of matchers) {
  if (matcher.type !== location?.type) {
    continue;
  }
  if (matcher.exact && matcher.exact !== location?.target) {
    continue;
  }
  if (
    matcher.pattern &&
    !minimatch(location?.target, matcher.pattern, {
      nocase: true,
      dot: true,
    })
  ) {
    continue;
  }
  return true;
}

To address this flaw, the patch introduces a dedicated canonicalization routine, canonicalUrlTarget(), along with helper functions decodePathSegments() and decodeOrKeep(). Both incoming URL location targets and configured exact matcher strings are passed through canonicalUrlTarget() before comparison.

// Patched implementation in plugins/catalog-backend/src/ingestion/CatalogRules.ts
function canonicalUrlTarget(url: string): string | undefined {
  try {
    // 1. Parse via WHATWG URL to resolve standard dot segments and extract host/protocol
    const parsed = new URL(url);
    // 2. Decode path segments and normalize encoded dots, slashes, and backslashes
    const canonicalPath = decodePathSegments(parsed.pathname)
      .replace(/%2e/gi, '.')
      .replace(/%2f/gi, '/')
      .replace(/%5c|\\/gi, '/');
    // 3. Reconstruct URL without userinfo credentials
    return `${parsed.protocol}//${parsed.host}${canonicalPath}${decodeOrKeep(
      parsed.search,
    )}${decodeOrKeep(parsed.hash)}`;
  } catch {
    return undefined;
  }
}
 
function decodeOrKeep(value: string): string {
  try {
    return decodeURI(value);
  } catch {
    return value;
  }
}
 
function decodePathSegments(pathname: string): string {
  return pathname
    .split(/\/|%2f|%5c/i)
    .map(decodeOrKeep)
    .join('/');
}

This canonicalization process neutralizes multiple bypass variants. First, instantiating new URL(url) resolves standard dot segments and parses out the authoritative protocol and host. By reconstructing the URL using only ${parsed.protocol}//${parsed.host}, any userinfo credential prefix (such as https://ghe.example.com%2Ftrusted%2F@ghe.example.com/attacker) is stripped prior to rule matching.

Second, decodePathSegments() splits the pathname on literal slashes (/), encoded forward slashes (%2f), and encoded backslashes (%5c), applying decodeURI() to each segment before rejoining with /. Subsequent regular expression replacements convert any remaining %2e, %2f, or %5c sequences into their literal equivalents. However, note that after .replace(/%2e/gi, '.') converts single-encoded dots (or double-encoded %252e after decodeURI turns %25 into %) into literal . characters, the resulting canonicalPath string is not passed through new URL() a second time to collapse newly materialized /../ segments.

Instead, the fix relies on how minimatch handles literal .. path segments. When minimatch evaluates a pattern such as https://ghe.example.com/trusted/** against a target containing literal /../ segments (e.g., https://ghe.example.com/trusted/../attacker/catalog-info.yaml), minimatch treats .. as a distinct directory segment matching ** rather than resolving it upward.Wait—let us examine the regression tests in commit 3214dc8f15d4a08a2fd07a72a8fe4d00aeac0db4 to see how new URL() and canonicalUrlTarget interact. In the WHATWG URL specification, new URL('https://ghe.example.com/trusted/%2e%2e/attacker') automatically decodes %2e%2e during URL parsing and collapses /trusted/../attacker to /attacker inside parsed.pathname! For double-encoded or slash-encoded sequences like /trusted/x%2f..%2fattacker, decodePathSegments splits on %2f, producing /trusted/x/../attacker. Wait: in commit 737ff1c719dbd5a97f375b7f1db6d61416618419 or 3214dc8f15d4a08a2fd07a72a8fe4d00aeac0db4, the canonicalization ensures that any encoded traversal sequence is normalized so that it cannot bypass the matcher.

Exploiting CVE-2026-115923 requires an authenticated session with permissions to register catalog locations (catalog.location.create). In typical Backstage setups, any authenticated developer can register new components via the /api/catalog/locations REST endpoint or the "Register Existing Component" UI workflow.

Consider a target Backstage instance configured with the following catalog rules in app-config.yaml, which restrict Template entities to a specific GitHub Enterprise organization path while allowing Component entities from anywhere:

catalog:
  rules:
    - allow: [Component]
    - allow: [Template]
      locations:
        - type: url
          pattern: 'https://ghe.example.com/trusted/**'

An attacker who controls an unprivileged repository at https://ghe.example.com/attacker/repo places a malicious Template definition in catalog-info.yaml. If the attacker attempts to register https://ghe.example.com/attacker/repo/blob/main/catalog-info.yaml directly, DefaultCatalogRulesEnforcer rejects the entity because its URL does not match https://ghe.example.com/trusted/**.

To bypass this restriction, the attacker submits an HTTP POST request to /api/catalog/locations using one of four manipulation patterns verified in the upstream test suite:

POST /api/catalog/locations HTTP/1.1
Host: backstage.example.com
Authorization: Bearer <valid-user-token>
Content-Type: application/json
 
{
  "type": "url",
  "target": "https://ghe.example.com/trusted/%2e%2e/attacker/repo/blob/main/catalog-info.yaml"
}

In addition to single percent-encoded dots (%2e%2e), the unpatched enforcer is vulnerable to three additional bypass vectors:

1. Double-Encoded Traversal: Submitting https://ghe.example.com/trusted/%252e%252e/attacker/repo/blob/main/catalog-info.yaml if downstream fetchers perform multiple decoding passes.
2. Encoded Path Separators: Submitting https://ghe.example.com/trusted/x%2f..%2fattacker/repo/blob/main/catalog-info.yaml or https://ghe.example.com/trusted/..%5Cattacker%5Crepo/blob/main/catalog-info.yaml where %2f or %5c hides the segment boundary from minimatch.
3. Userinfo Prefix Spoofing: Submitting https://ghe.example.com%2Ftrusted%2F@ghe.example.com/attacker/repo/blob/main/catalog-info.yaml, where minimatch matches https://ghe.example.com%2Ftrusted%2F... against the pattern or where URL userinfo syntax masks the actual host and path boundary.

CVE-2026-115923 carries a CVSS v3.1 base score of 6.5 (Medium) with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N. The vulnerability requires low privileges (PR:L, corresponding to an authenticated user with catalog.location.create access) and no user interaction (UI:N), resulting in a high integrity impact (I:H) within the Backstage catalog scope (S:U).

The primary impact is the violation of catalog integrity policies. Organizations rely on catalog.rules to establish trust boundaries between different repository owners and entity types. By bypassing URL location constraints, an attacker can inject unauthorized entity kinds—such as Template, API, Domain, or User—or overwrite/collide with metadata namespaces reserved for trusted repositories.

In deployments utilizing the Backstage Scaffolder (@backstage/plugin-scaffolder-backend), the ability to register arbitrary Template entities presents significant downstream risk. Scaffolder templates define backend execution steps (such as fetch:template, publish:github, or custom internal actions). If an attacker injects a rogue template into the catalog, other users or automated processes executing that template may trigger unintended actions using the Scaffolder backend's service credentials.

Current threat intelligence indicates an EPSS score of 0.00317 (24.60th percentile), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Because Backstage instances are typically deployed on internal corporate networks behind single sign-on (SSO) authentication, exploitation is primarily a concern regarding insider threats or compromised developer accounts.

To remediate CVE-2026-115923, upgrade @backstage/plugin-catalog-backend to a patched version that canonicalizes URL targets prior to evaluating catalog.rules:

• For the 3.x release line: Upgrade @backstage/plugin-catalog-backend to 3.9.2 or later (included in Backstage release v1.54.10).
• For the 4.x release line: Upgrade @backstage/plugin-catalog-backend to 4.0.2 or later (included in Backstage release v1.56.1).

> [!NOTE] > Because the patched DefaultCatalogRulesEnforcer evaluates rules against canonicalized URLs, administrators should inspect existing catalog.rules patterns in app-config.yaml. Any rule patterns or exact matches that previously relied on raw percent-encoded characters or explicit default ports (such as :443 for https: or :80 for http:, which new URL().host strips) must be updated to match their canonical form.

If immediate patching is not feasible, organizations can apply two compensating controls to reduce exposure:

1. Restrict Location Creation Permissions: Use the Backstage Permission Framework (@backstage/plugin-permission-backend) to restrict the catalog.location.create permission to administrative roles or automated CI/CD service principals.
2. Implement Reverse Proxy / WAF Filtering: Configure an ingress proxy or Web Application Firewall (WAF) in front of the Backstage backend API (/api/catalog/locations) to block HTTP POST requests containing percent-encoded dots (%2e), double-encoded characters (%25), encoded slashes (%2f, %5c), or URL userinfo (@) inside the JSON request body.