Backstage EUVD-2026-94052

Exploitation requires the catalog backend to be configured with an allowedLocationTypes restriction list AND an attacker with authenticated permission to register or influence a Location entity. The specific flaw: the pre-patch orchestrator only enforced the allowed-type check when the processed location type differed from the parent location's type (type !== context.location.type), so a disallowed type (e.g. 'file') that was inherited from the parent/origin location bypassed enforcement and was processed, enabling file access on the backend host. Limiting factors: non-default configuration (allowedLocationTypes must be set), authenticated access (PR:L), and high complexity (AC:H) due to the inheritance-matching edge case; default deployments without allowedLocationTypes restrictions, or without untrusted location-registration access, are not meaningfully exposed.

This is a genuinely low-priority issue despite the network attack vector. The CNA (GitHub) CVSS:3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N) scores only 3.1 (Low), and the signals are consistent with that: exploitation requires authenticated access (PR:L), carries high attack complexity (AC:H) because it depends on a non-default allowedLocationTypes configuration plus a specific type-inheritance edge case, and yields only limited impact. No EPSS score, CISA KEV listing, or public POC is present in the provided data - no public exploit identified at time of analysis - so there is no evidence of real-world exploitation pressure. One conflict worth flagging: the description states the flaw leads to 'unintended file access on the backend host,' which reads like a confidentiality (file read) impact, yet the vendor vector sets C:N and instead assigns I:L - verify with the vendor advisory whether the realistic impact is reading backend files (confidentiality) or catalog data integrity. Overall this is a legitimately low-severity hardening fix, not an urgent priority.

An authenticated user able to register catalog locations submits a Location entity whose type (e.g. 'file:') is normally excluded by the configured allowedLocationTypes list, but is crafted so the type is inherited from the parent/origin location and therefore skips the enforcement check. The catalog backend then processes the location and reads an unintended file from the backend host filesystem. No public exploit is identified; attack complexity is high and a non-default allowedLocationTypes configuration is required.