CVE-2026-106562: 
JavaScript vulnerability analysis and mitigation

CVE-2026-106562 is an incorrect authorization vulnerability in Backstage's search engine permission filtering that allows authenticated users to receive search results they are not authorized to view. It affects @backstage/plugin-search-backend versions prior to 2.1.6, @backstage/plugin-search-backend-module-elasticsearch versions prior to 1.8.7, and Backstage core versions prior to 1.54.1. The vulnerability was first published by GitHub Advisory (GHSA-9325-vq29-gp3v) on August 28, 2026, and added to the NVD on October 7, 2026. It carries a CVSS v3.1 base score of 4.3 (Medium) (Github Advisory, Red Hat).

The root cause is an improper check for unusual or exceptional conditions (CWE-754) combined with incorrect authorization logic (CWE-863) in the AuthorizedSearchEngine and ElasticSearchSearchEngine components. When the permission framework evaluates a user's access and all document types are subject to a DENY policy, the resulting authorized types list becomes an empty array. Instead of returning empty results, the code previously passed this empty array downstream — causing the Elasticsearch/OpenSearch engine to query all indices without type filtering, effectively bypassing the DENY policy. The fix adds an explicit early-return check: if authorizedTypes.length === 0 in AuthorizedSearchEngine.ts, an empty result set is returned immediately without querying the backend; a parallel guard was added in ElasticSearchSearchEngine.ts for the same edge case (Github Advisory, Backstage Commit). Exploitation requires the deployment to have permission.enabled: true and use an Elasticsearch or OpenSearch backend; the attacker must be an authenticated Backstage user subject to a blanket DENY policy on one or more search document types.

Successful exploitation results in unauthorized disclosure of restricted search documents to authenticated users who should be denied access — a confidentiality impact with no effect on integrity or availability. Affected users could retrieve internal developer portal content (e.g., catalog entities, TechDocs pages, or other indexed resources) that their organization's permission policies explicitly prohibit. The scope is limited to the Backstage search index contents and does not directly enable lateral movement or code execution, but exposure of sensitive internal documentation or service metadata could facilitate further reconnaissance (Github Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The EPSS score is 0.0, reflecting very low probability of near-term exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation is not automatable and requires low privileges (a valid Backstage account), limiting the realistic attacker pool to insiders or users with compromised credentials (Github Advisory).

1. Identify a vulnerable deployment: Confirm the target Backstage instance uses permission.enabled: true and an Elasticsearch or OpenSearch search backend, and is running @backstage/plugin-search-backend < 2.1.6 or @backstage/plugin-search-backend-module-elasticsearch < 1.8.7.
2. Authenticate: Log in to the Backstage instance with any valid user account that is subject to a blanket DENY policy on one or more search document types (e.g., a restricted user role).
3. Issue a search query: Submit a search request via the Backstage UI or directly to the search backend API (e.g., GET /api/search/query?term=<keyword>) without specifying document type filters, or with all permitted types denied by policy.
4. Observe unauthorized results: Because the permission layer passes an empty authorizedTypes array to the search engine rather than short-circuiting, the Elasticsearch/OpenSearch backend queries all indices and returns results across document types the user should not access.
5. Exfiltrate data: Review the returned search results for sensitive internal content such as catalog entity metadata, TechDocs pages, or other indexed Backstage resources that the DENY policy was intended to restrict (Github Advisory, Backstage Commit).

• Logs: Backstage search backend logs showing authenticated users with DENY-only permission policies successfully receiving non-empty search result sets; Elasticsearch/OpenSearch query logs showing wildcard index queries (*) originating from the Backstage search service account when no document types should have been permitted.
• Network: Unusual volume of search API requests (/api/search/query) from accounts known to have restrictive DENY policies, particularly returning HTTP 200 responses with populated result bodies.
• Application Behavior: Search audit logs (if enabled) recording result delivery to users whose permission decisions resolved entirely to AuthorizeResult.DENY for all queried document types.

Upgrade @backstage/plugin-search-backend to version 2.1.6 and @backstage/plugin-search-backend-module-elasticsearch to version 1.8.7; for full Backstage installations, upgrade to v1.54.1 or later (Github Advisory, Backstage Release). If immediate patching is not possible, two workarounds are available: (1) replace blanket DENY policies for search document types with CONDITIONAL decisions that perform per-result filtering, and (2) restrict Elasticsearch/OpenSearch index access at the cluster level so the Backstage search service account can only reach expected indices, limiting the blast radius of any authorization bypass (Github Advisory).