Backstage Kubernetes Backend CVE-2026-106487

Exploitation requires ALL of the following, drawn directly from the advisory description: (1) the deployment must use catalog cluster discovery (the CatalogClusterLocator), a non-default cluster-sourcing mode; (2) the attacker must be a catalog contributor able to create or modify kubernetes-cluster Resource entities, matching PR:L; (3) the required endpoint permissions must be granted; and (4) the backend pod must have RBAC allowing its in-cluster service account to read the targeted Kubernetes resources - the disclosure is bounded by exactly what that service account can already read. Limiting factors: the credential is only ever used against the local in-cluster API endpoint and is never sent to the catalog-supplied endpoint, authentication as a catalog contributor is mandatory, and the multiple stacked preconditions (AC:H) make opportunistic or automated exploitation unlikely.

This is a genuinely low-priority, low-real-risk issue despite being network-reachable. The supplied CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N) scores only 3.5 (Low), and every signal reinforces that: AC:H and PR:L mean the attacker must already be an authenticated catalog contributor AND several environmental preconditions must line up, while impact is limited to C:L with 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 evidence of active or automated exploitation. The flaw is a classic confused-deputy pattern (CWE-441): a catalog-supplied kubernetes-cluster entity requesting the unsupported serviceAccount auth provider caused the backend to fall back to its own in-cluster identity, so a malicious catalog entry could read cluster resources that the backend's service account can see. Note the official vector does not conflict with the description; both point to a config/authorization-dependent, insider-leaning weakness rather than a mass-exploitable remote bug. The strongest limiting factors (catalog write access, specific endpoint permissions, pod RBAC, and the non-default catalog cluster discovery mode) are exactly why real-world risk is far below what 'network vector' alone might suggest.

A user who can author or edit catalog entities adds or modifies a kubernetes-cluster Resource entity declaring the serviceAccount auth provider; a deployment using catalog cluster discovery then has the backend connect to that cluster using its own in-cluster service account identity, returning Kubernetes resources readable by that identity back to the actor. No public exploit code is known, and AC:H/PR:L means the attacker needs existing catalog-contributor access plus matching endpoint permissions and pod RBAC for the disclosure to occur.