Backstage EUVD-2026-94375

Exploitation requires a deployment with permission.enabled set to true AND an Elasticsearch or OpenSearch search backend (not Backstage's default in-memory Lucene engine), plus an authenticated user who is subject to a DENY policy for one or more search document types. The concrete trigger is the permitted-document-type list resolving to empty, which caused the search engine to run an unfiltered query across all indices rather than returning no results. Limiting factors: the attacker must already hold a valid Backstage account (PR:L), the permissions framework must be explicitly enabled, the backend must be ES/OpenSearch, and the user must actually be governed by a DENY policy - deployments without permissions enabled or using the default search engine are not affected.

This is a genuine but low-urgency information-disclosure issue, not 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 = 4.3 Medium) is internally consistent with the description: a network-reachable search API, low attack complexity, requiring an already-authenticated user (PR:L), with only limited confidentiality impact and no integrity or availability effect. No EPSS score, no CISA KEV listing, and no public exploit were provided in the intelligence, so exploitation status is 'no public exploit identified at time of analysis.' There is no conflict among the available signals - a low-ish CVSS, absence of KEV/EPSS/POC, and a precondition-heavy trigger all point the same direction: a real authorization-boundary defect worth patching on a normal cadence rather than an actively exploited threat. The main caveat is that impact depends entirely on how sensitive the indexed documents are and how broadly DENY policies are relied upon; in a multi-tenant portal the confidentiality consequence could matter more than the 'Low' rating suggests. Note the CWE is CWE-754 (improper check for exceptional conditions), which matches the root cause (an empty permitted-type list mishandled) better than the 'Authentication Bypass' tag, which overstates the issue - this is authorization/permission-filter bypass by an already-authenticated user, not an authentication bypass.

An authenticated Backstage user who is subject to a DENY permission policy for certain search document types issues a normal search query. Because an empty permitted-type list caused the Elasticsearch/OpenSearch engine to query all indices instead of returning empty results, the user receives documents that policy should have withheld. No public exploit code is referenced; exploitation requires only a valid account in a deployment with permission.enabled=true and an ES/OpenSearch backend.