Backstage EUVD-2026-94013

Exploitation requires (1) a Backstage deployment version prior to 1.54.6 that is configured to use a cloud storage catalog provider - specifically an Azure Blob Storage source (via @backstage/plugin-catalog-backend-module-azure) or an AWS S3 source (via @backstage/plugin-catalog-backend-module-aws / backend-defaults cloud URL readers); and (2) the attacker being a principal already authorized to create or rename objects (object keys / blob names) within that configured storage source. The attacker must craft an object name containing dot-path segments, including URL-encoded forms such as %2e%2e, %2E%2E, or backslash-delimited variants, to escape the intended prefix. Exploitation is LIMITED by: the need for pre-existing write access to the trusted catalog storage (not a default-open remote condition), the requirement that the target data be reachable only with the backend's own configured credentials (no privilege escalation beyond the backend's existing storage access), and confidentiality-only impact (read of catalog descriptors, no write or availability effect). It does NOT apply to Backstage instances that do not use Azure Blob or AWS S3 catalog sources.

This is a genuinely low-priority issue despite being a path traversal (CWE-22) weakness. The provided CVSS:3.1 vector (AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:N = 3.0, Low) tells a consistent story: although the attack vector is network-based, exploitation requires HIGH privileges (PR:H) and HIGH attack complexity (AC:H), and the impact is confidentiality-only and limited (C:L, I:N, A:N). The prerequisite - being a principal already able to create or rename objects in a configured Azure Blob Storage or AWS S3 catalog source - means the attacker must already hold write access to a trusted catalog backend, which heavily constrains the population of potential abusers to insiders or already-compromised writers. The scope change (S:C) is the only aggravating signal, reflecting that the backend can be coerced into reading descriptors from storage locations outside the intended boundary, but even that is bounded to locations reachable with the backend's own configured credentials. No EPSS score, KEV listing, POC, or SSVC decision data was supplied in the input; absence of these is not itself a risk indicator, but there is nothing here suggesting mass or automatable exploitation. The CVSS network/local signals are not contradictory - the storage is accessed over the network, but the real gating factor is the required write privilege, so defenders should treat this as an authenticated/insider confidentiality concern rather than a remote-exploitable critical flaw.

An actor who already has permission to create or rename objects in an organization's AWS S3 bucket or Azure Blob container used as a Backstage catalog source uploads or renames an object so its key/blob name contains encoded dot-segments (e.g. %2e%2e). When Backstage's catalog backend resolves that path, it is tricked into reading a catalog descriptor from outside the intended storage prefix, exposing content reachable with the backend's configured storage credentials. No public exploit identified at time of analysis, so any attempt would require an actor to craft the traversal payload themselves.