CVE-2026-106562

LOWCVSS 4.3 · MEDIUM

Signal is active with 1 mentions in latest observed window

Immediate actions

  • Track advisory updates for patch or workaround availability

Recommended action window: Monitor and triage in normal cycle

NVD description

Backstage is an open framework for building developer portals. Prior to 2.1.6 in @backstage/plugin-search-backend and 1.8.7 in @backstage/plugin-search-backend-module-elasticsearch, search engine permission filtering could return documents denied by policy. An authenticated Backstage user subject to a DENY policy for search document types could receive unauthorized results in deployments with permission.enabled set to true and an Elasticsearch or OpenSearch backend. This issue is fixed in @backstage/plugin-search-backend 2.1.6 and @backstage/plugin-search-backend-module-elasticsearch 1.8.7.

0.0/ 10 priority

Sources & remediation

Weakness type (CWE)
CWE-754CWE-863

Priority

LOW

Exploitation

NONE

PoC

NONE

Patch

NONE

Momentum

NONE

Threat summary

  • 1 mentions across 1 observed day

What's happening

  • 1 total mentions across 1 day

Deep dive

Activity timeline1 mentions / 1d
00111Mentions · 2026-10-08: 110-08
Full discourse1 post
  • Roland Brüggemann | EVELIQ Trace@eveliqTrace

    EVIDENCE INTELLIGENCE • A DENY POLICY IS NOT PROOF THAT ACCESS WAS DENIED A security advisory from the Backstage project illustrates an important boundary in enterprise authorization systems. CVE-2026-106562 concerns incorrect permission filtering in search backends. Under the documented conditions, an authenticated user could receive search results that an explicit DENY policy was intended to prevent. The issue affected specific deployments using enabled permission enforcement with Elasticsearch or OpenSearch. The maintainers have addressed the vulnerability in corrected releases. That is meaningful security maintenance. But the broader assurance boundary deserves attention: DENY POLICY DECLARED ≠ DENY POLICY ENFORCED An organization may have an authorization policy. It may have a policy engine. It may evaluate access decisions. Yet the effective security property depends on whether those decisions remain enforced throughout the complete data-access path. The stronger evidence chain is: IDENTITY → RESOURCE → POLICY → AUTHORIZATION DECISION → SEARCH FILTER → RETURNED RESULT → VERIFIED ACCESS This distinction matters wherever enterprise systems expose information through search indexes, dashboards, APIs and AI-assisted retrieval. A correctly defined policy does not automatically prove that every downstream component preserves its intended restrictions. The relevant assurance question is not simply: "Was access denied by policy?" It is: "Was the denied information actually prevented from reaching the consumer?" The advisory does not establish that every Backstage deployment is affected. Nor does it prove that underlying records were manipulated. It demonstrates a specific authorization-enforcement failure under defined conditions. For evidence-sensitive systems, the next step is independently verifying that declared restrictions remain effective across the entire information-delivery chain. EVELIQ Trace • Evidence Intelligence Platform. We don't score people. We verify project reality. Founder: Roland Brüggemann AI-assisted research, structure, architecture & concept development: OpenAI ChatGPT Source: Backstage Security Advisory GHSA-9325-vq29-gp3v / CVE-2026-106562. #EvidenceIntelligence #Authorization #AccessControl #CyberSecurity #EVELIQTrace

    0000020
    61 followersView on X

Explore more