☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
CVSS: 4.3 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N 🐛 CWE-754
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2026-106562

CVE-2026-106562 Vulnerability in Backstage
📅 PUBLISHED: 2026-10-07 00:00 UTC 🔄 UPDATED: 2026-10-08 23:08 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.20%
👁️
0.20% probability
4.9× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
🥷 MITRE: T1213
👁️
MITRE ATT&CK Tactic - Describes the strategy hackers use to execute this attack.
VULNERABLE: version not auto-detected — verify your deployed version locally
CVSS VECTOR BREAKDOWN 4.3
AV: N Attack Vector Network
AC: L Attack Complexity Low
PR: L Privileges Required Low
UI: N User Interaction None
S: U Scope Unchanged
C: L Confidentiality Low
I: N Integrity None
A: N Availability None
4.3
THREAT LEVEL
INTEL SOURCES NVD EPSS HOW WE SCORE →
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2026-106562 is an improper authorization vulnerability in the Backstage developer portal framework affecting the @backstage/plugin-search-backend and @backstage/plugin-search-backend-module-elasticsearch packages. An authenticated user who is explicitly subject to a DENY policy for specific search document types can still receive those denied documents in search results when the deployment has permission.enabled set to true and uses an Elasticsearch or OpenSearch backend. The impact is limited to confidentiality (CVSS 4.3), as unauthorized document disclosure may expose sensitive internal documentation, metadata, or developer resources to users who should not have access.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Technical Analysis

Backstage is an open framework for building developer portals, and its search subsystem aggregates documents from multiple sources (catalogs, TechDocs, plugins) into a unified search index. When Backstage's permission framework is enabled via permission.enabled: true, the search backend is expected to apply permission filtering to search results, ensuring that a user only receives documents for which an explicit ALLOW decision exists — or, conversely, that documents for which a DENY decision applies are excluded.

The vulnerability class here is CWE-754 (Improper Check for Unusual or Exceptional Conditions), mapped to a failure in authorization enforcement during search result filtering. The NVD description states that "search engine permission filtering could return documents denied by policy." This indicates that the filtering logic, when interfacing with an Elasticsearch or OpenSearch backend, does not correctly exclude documents that a DENY policy should have removed from the result set. In effect, the permission filter is applied in a way that can be bypassed or is incomplete for the deny case, so an authenticated user under a DENY policy receives unauthorized results.

Because the issue is tied to the Elasticsearch/OpenSearch backend module and the search backend, the flaw exists at the intersection of the permission enforcement layer and the query construction or post-query filtering used against the external search engine. The specific function or query parameter where the deny filtering fails is not named in the provided advisory, so the exact code-level mechanism (for example, whether the deny list is omitted from a filter clause or whether filtering is applied only to a subset of document types) cannot be confirmed from the available data. What is confirmed is that the defect is only exploitable when permission enforcement is enabled and when the search backend uses Elasticsearch or OpenSearch. Deployments using other search backends, or where permission.enabled is false, are not described as affected.

Exploitation Scenarios

No public PoC or exploit code is available for this CVE, and no Nuclei template exists. The attack chain is therefore inferred from the vulnerability class (improper authorization / incorrect deny-policy enforcement in search result filtering) and the conditions stated in the advisory.

  1. Reconnaissance/target identification: An attacker identifies a Backstage instance that exposes a search interface and is configured with permission.enabled: true and an Elasticsearch or OpenSearch search backend. This may be a publicly reachable developer portal or an internal portal accessible to the attacker through valid low-privilege credentials.

  2. Triggering the flaw: The attacker authenticates as a normal user who has been placed under a DENY policy for one or more search document types. As an authenticated user, the attacker issues a search query through the Backstage search UI or the underlying search API. Under correct behavior, documents of the denied type should be filtered out of the response.

  3. Payload/execution method: The attacker uses a broad or targeted search query designed to match documents of the types that their policy denies. Because the search backend's permission filtering fails to exclude denied documents when backed by Elasticsearch or OpenSearch, the response includes results the user should not see. No special payload is required beyond a normal search request; the exploitation consists of submitting queries and observing that denied document types are returned.

  4. Post-exploitation impact: The attacker gains read access to search documents that policy intended to deny, potentially disclosing internal technical documentation, catalog entities, or other indexed content. This is a confidentiality-only impact; the vulnerability does not permit modification or deletion of data and does not by itself enable remote code execution.

Impact Assessment

The CVSS 3.1 vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, giving a base score of 4.3 (Medium). Network accessibility (AV:N) means the vulnerable search interface can be reached over the network. Attack complexity is Low (AC:L) once the preconditions are met. Privileges Required is Low (PR:L) because the attacker must be an authenticated Backstage user. No user interaction is needed (UI:N), and the scope is Unchanged (S:U). The only impacted CIA property is Confidentiality (C:L), confirming a limited information disclosure; Integrity and Availability are both None.

The blast radius is constrained to the search index contents that a given user's DENY policy should have shielded. In environments where the search index aggregates sensitive internal documentation, architecture diagrams, incident data, or catalog metadata, the disclosure could expose information useful for further reconnaissance or social engineering. Business impact includes potential violation of internal need-to-know policies and regulatory obligations around data handling. Because the vulnerability requires authentication and a specific permission configuration, the practical exposure is lower than a pre-authentication flaw, but the affected population is precisely the set of users whose access was intentionally restricted.

Detection Guidance

Sigma Rule

title: Potential Backstage Search Permission Deny Bypass (CVE-2026-106562)
id: 8f3a2c1e-4b6d-4c9a-9f2e-backstage-deny-bypass
status: experimental
description: Detects search requests to Backstage search backends that may return documents denied by policy when permission filtering fails.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-106562
author: Threat Intelligence
date: 2026/01/01
logsource:
    category: application
    product: backstage
detection:
    selection_path:
        url|contains:
            - '/api/search/query'
    selection_status:
        status: 200
    selection_response:
        response_body|contains:
            - 'documentType'
    condition: selection_path and selection_status and selection_response
fields:
    - user
    - url
    - status
    - response_body
falsepositives:
    - Legitimate searches by users whose policies permit the returned document types
level: medium
tags:
    - attack.t1213
    - cve.2026.106562

YARA Rule

rule CVE_2026_106562_Backstage_Search_Deny_Bypass
{
    meta:
        description = "Detects Backstage search backend artifacts potentially related to CVE-2026-106562 permission filtering failure"
        author = "Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-106562"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $pkg1 = "@backstage/plugin-search-backend" ascii wide
        $pkg2 = "@backstage/plugin-search-backend-module-elasticsearch" ascii wide
        $perm1 = "permission.enabled" ascii wide
        $eng1 = "elasticsearch" ascii nocase wide
        $eng2 = "opensearch" ascii nocase wide
        $query = "/api/search/query" ascii wide

    condition:
        (uint16(0) == 0x0A0D or true) and
        (($pkg1 or $pkg2) and ($perm1 or $eng1 or $eng2)) and
        $query
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-106562 Possible Backstage Search Permission Deny Bypass Attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"/api/search/query"; http.uri; content:"documentType"; nocase; reference:cve,2026-106562; classtype:attempted-recon; sid:2026106562; rev:1;)

Elastic Detection

sequence by user.id with maxspan=5m
  [ network where network.protocol == "http" and url.path == "/api/search/query" and http.request.method == "GET" ]
  [ network where network.protocol == "http" and url.path == "/api/search/query" and http.response.status_code == 200 and http.response.body contains "documentType" ]

Splunk SPL Query

index=web OR index=proxy sourcetype=access_combined OR sourcetype=backstage
| search uri_path="/api/search/query"
| eval denied_doc = if(match(_raw, "(?i)documentType") AND match(_raw, "(?i)(deny|permission)"), 1, 0)
| where status=200 OR denied_doc=1
| stats count values(uri_path) as paths values(user) as users by src_ip
| where count > 5

Wazuh OSSEC Rule

<group name="backstage,web,">
  <rule id="106562" level="7">
    <if_sid>31100</if_sid>
    <url>/api/search/query</url>
    <description>CVE-2026-106562: Possible Backstage search permission deny bypass - search query to Elasticsearch/OpenSearch backend</description>
    <group>cve_2026_106562,access_control,</group>
    <mitre>
      <id>T1213</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The advisory states a fix exists in newer package versions, but this report's tracked patch sources provide no confirmation, so confidence is recorded as unpatched pending verification.

  1. Immediate mitigations: If the affected packages are in use and cannot be upgraded immediately, consider disabling the search backend or restricting search access to trusted roles until the packages can be upgraded. Where operationally feasible, set permission.enabled considerations aside only after a risk review; note that disabling the permission framework broadly may have its own security consequences and should not be treated as a safe default. Limit who can authenticate to the Backstage instance and review DENY policies to understand which document types are at risk of disclosure.

  2. Patch/upgrade steps: Upgrade @backstage/plugin-search-backend to version 2.1.6 or later and @backstage/plugin-search-backend-module-elasticsearch to version 1.8.7 or later. Rebuild and redeploy the Backstage application, and re-run regression tests on search permission enforcement to confirm that DENY policies are respected in results returned from the Elasticsearch or OpenSearch backend.

  3. Long-term hardening: Enforce a least-privilege model for search document types, regularly audit DENY and ALLOW policies, and add automated tests that verify denied document types are excluded from search responses. Monitor search query logs for anomalous patterns that suggest a user is harvesting denied document types. Track the Backstage project's release notes and the NVD entry for further updates.

References

👁️ SHODAN DORKS (THREAT HUNTING)

What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.

product:"Backstage"
title:"Backstage"
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2026-106562/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.