CVE-2026-106497: Backstage Information Disclosure Vulnerability

CVE-2026-106497 Overview

CVE-2026-106497 is an authorization flaw in the Backstage @backstage/plugin-catalog-backend package. Backstage is an open framework for building developer portals. The vulnerability stems from inconsistent catalog property permission evaluation prior to version 3.9.1. Deployments relying on value-based catalog permission conditions as a confidentiality boundary are affected. An authenticated user can retrieve catalog entity data that policy authors intended to restrict. The issue is classified under [CWE-178: Improper Handling of Case Sensitivity] and is fixed in version 3.9.1.

Critical Impact
Authenticated users can access restricted catalog entity data when value-based permission conditions are used to enforce confidentiality boundaries.

Affected Products

Backstage @backstage/plugin-catalog-backend prior to version 3.9.1
Backstage deployments using value-based catalog property permission conditions
Backstage release trains prior to v1.54.6

Discovery Timeline

2026-10-06 - CVE CVE-2026-106497 published to NVD
2026-10-07 - Last updated in NVD database

Technical Details for CVE-2026-106497

Vulnerability Analysis

The vulnerability resides in the createPropertyRule permission rule factory within the catalog backend. The rule evaluates catalog entity property matches to decide whether a user may read a given entity. The evaluation path used by the permission rule did not align with the catalog's underlying search indexing logic. As a result, requests that should have been filtered by value-based conditions returned entities the policy intended to hide.

The mismatch primarily affects deployments that treat property-based permission conditions as a confidentiality boundary. In these configurations, operators restrict visibility of entities based on metadata or spec property values. Authenticated users without matching attributes could still receive those entity records through catalog read operations.

Root Cause

The original implementation used lodash.get to resolve property values during permission evaluation. This path accessor did not normalize values the same way the catalog's entity search index does during stitching. The inconsistency produced divergent match results between permission checks and persisted search data, allowing restricted entities to leak through filtered queries.

Attack Vector

Exploitation requires an authenticated session against the Backstage instance. No user interaction is required beyond issuing standard catalog API requests. An attacker queries the catalog backend for entities that should be blocked by a value-based permission condition. Because of the inconsistent matching, the response includes entities whose property values do not match the user's authorized scope.

typescript

// Security patch in plugins/catalog-backend/src/permissions/rules/createPropertyRule.ts
 import { catalogEntityPermissionResourceRef } from '@backstage/plugin-catalog-node/alpha';
 import { createPermissionRule } from '@backstage/plugin-permission-node';
-import { get } from 'lodash';
 import { z } from 'zod/v3';
+import { buildEntitySearch } from '../../database/operations/stitcher/buildEntitySearch';

 export const createPropertyRule = (propertyType: 'metadata' | 'spec') =>
   createPermissionRule({

Source: Backstage commit 21424fa. The patch replaces direct lodash.get lookups with buildEntitySearch, aligning permission evaluation with the stitcher's search index semantics.

Detection Methods for CVE-2026-106497

Indicators of Compromise

Catalog read API responses that include entities whose property values do not match the requesting user's permission scope.
Unexpected GET /api/catalog/entities traffic from accounts that should be restricted by value-based conditions.
Audit log entries showing successful entity reads inconsistent with configured permission policies.

Detection Strategies

Compare the output of catalog queries made by low-privilege test accounts against expected policy results in staging.
Enable Backstage audit logging and review permission decision events for mismatches between evaluated conditions and returned entities.
Inventory running Backstage installations and flag any @backstage/plugin-catalog-backend version prior to 3.9.1.

Monitoring Recommendations

Monitor Backstage backend logs for anomalous catalog listing volumes from standard user accounts.
Alert on authenticated API access to catalog entities tagged as sensitive in metadata or spec fields.
Track package versions in CI/CD pipelines to prevent regression to vulnerable @backstage/plugin-catalog-backend releases.

How to Mitigate CVE-2026-106497

Immediate Actions Required

Upgrade @backstage/plugin-catalog-backend to version 3.9.1 or later.
Upgrade the Backstage release train to v1.54.6 or later to pick up the fixed plugin version.
Review existing catalog permission policies that depend on property value matching for confidentiality.
Audit catalog access logs for the exposure window to identify potential unauthorized disclosure.

Patch Information

The fix is delivered in @backstage/plugin-catalog-backend 3.9.1 and bundled in the Backstage v1.54.6 release. Technical details are documented in the GitHub Security Advisory GHSA-8429-xpcj-3cg5 and the upstream commit.

Workarounds

Avoid treating value-based catalog permission conditions as a sole confidentiality boundary until patched.
Partition sensitive catalog data into separate Backstage instances or namespaces with coarser access controls.
Restrict authenticated catalog API access to trusted user groups via upstream authentication proxies.

bash

# Upgrade the affected package to the fixed version
yarn up @backstage/plugin-catalog-backend@^3.9.1

# Verify the installed version
yarn why @backstage/plugin-catalog-backend