Bug 2519896 (CVE-2026-76827)

Summary: CVE-2026-76827 search-indexer: search-indexer: UPDATE/DELETE operations not scoped to caller's cluster (cross-tenant data tampering)
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: gparvin, rhaigner, security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in search-indexer. This vulnerability allows a registered and authenticated managed cluster to tamper with or delete another cluster's indexed search data. This is possible because the delta-sync write paths in search-indexer do not properly restrict UPDATE/DELETE operations to data owned by the calling cluster. An attacker could exploit this by crafting specific user identifiers (UIDs) with a different cluster's prefix.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-19 19:59:01 UTC 
Delta-sync write paths in search-indexer do not constrain UPDATE/DELETE mutations to rows owned by the authenticated cluster. UIDs are conventionally <clusterName>/<k8s-uid> by collector convention, but the indexer never enforces this prefix. A registered managed cluster can submit a payload with a victim cluster's UID in updateResources or deleteResources and mutate/delete that cluster's indexed data, even when posting to its own /clusters/<self>/sync path. The INSERT path's ON CONFLICT (uid) DO UPDATE also overwrites an existing row's data regardless of which cluster owns it, since the cluster column is not part of the conflict target or re-checked.

This is a defense-in-depth failure independent of authentication/identity-binding gaps tracked separately -- exploiting it requires already being a legitimately registered, authenticated managed spoke cluster with valid addon-framework credentials, not an anonymous or low-privilege caller.

Upstream Jira: ACM-42544