Backstage Catalog Backend EUVD-2026-94054

Exploitation is limited to deployments that use affected value-based catalog permission conditions (property-matching rules) as a confidentiality boundary in @backstage/plugin-catalog-backend before 3.9.1; installations without such value-based restrictions are not exposed. The attacker must be an authenticated Backstage user (CVSS PR:L), and abuse relies on the inconsistent matching behavior - case-sensitivity differences in property keys/values and mishandling of falsy scalar values (false, 0, empty string) - so the specified restricted property must be reachable via a case- or value-variant that the rule failed to match. No user interaction is required, but the authentication requirement and the non-default dependence on value-based permission conditions meaningfully narrow realistic exposure.

All signals point to a genuine but low-severity information-disclosure issue rather than a high-priority emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 4.3/Medium) indicates a network-reachable, low-complexity flaw requiring an already-authenticated user (PR:L), with only limited confidentiality impact and no integrity or availability effect - consistent with the CWE-178 (improper case-sensitivity handling) root cause visible in the commit, where property matching failed to normalize case and mishandled falsy scalar values. No EPSS score was supplied, the CVE is not listed in CISA KEV, and no public exploit code is referenced, so there is no public exploit identified at time of analysis. Crucially, real-world risk is further gated by configuration: the flaw only crosses a confidentiality boundary in deployments that specifically use value-based catalog permission conditions to restrict entity data, so many Backstage instances are unaffected. One data-quality caveat: the description and package metadata say the fix is @backstage/plugin-catalog-backend 3.9.1, but a referenced release tag is v1.54.6 - these are the plugin package version versus the umbrella Backstage release, not a contradiction, but defenders should confirm which version string applies to their deployment.

An authenticated Backstage user whose access to certain catalog entities is meant to be restricted by a value-based permission condition queries the catalog using a property key or value that differs only in letter case (or relies on a falsy scalar value) from what the policy author expected. Because the permission rule matched inconsistently, the backend fails to apply the intended restriction and returns entity data the user should not see. No public exploit code is referenced, so this would be a manual or scripted abuse of the authenticated catalog API.