REDHAT-BUG-2519896: Medium severity search-indexer vulnerability
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
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
Exploitation requires a legitimately registered and authenticated managed spoke cluster with valid addon-framework credentials. Anonymous callers and low-privilege callers are not sufficient.
What access does a successful attacker gain over other clusters' data?
A registered cluster can submit another cluster's UID through its own sync path to update or delete that cluster's indexed resources. Insert operations can also overwrite an existing row with the same UID, regardless of the owning cluster.
Are only update and delete operations affected?
No. UPDATE and DELETE mutations are not constrained to rows owned by the authenticated cluster, and the INSERT ON CONFLICT behavior can overwrite an existing UID without re-checking cluster ownership.