CVE-2026-76827: Search-indexer: search-indexer: update/delete operations not scoped to caller's cluster (cross-tenant data tampering)

Published Aug 19, 2026
·
Updated

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.

Other sources

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

Red Hat

Affected Software

1 affected component
search-indexer

Event History

Aug 19, 2026
Data Sourced
via Red Hat·07:59 PM
DescriptionSeverityAffected Software
CVE Published
via MITRE·08:56 PM
Data Sourced
via MITRE·08:56 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Who can exploit this issue?

A registered and authenticated managed cluster can exploit it. The attacker needs privileges sufficient to use the delta-sync write paths and must craft UIDs using another cluster's prefix.

2

What is the impact on other tenants?

An attacker can tamper with or delete indexed search data belonging to another cluster. The available data indicates integrity impact, not confidentiality or availability impact.

3

Are default deployments affected?

The provided information does not state whether the vulnerable delta-sync write paths are enabled or reachable in a default deployment.

4

How can teams determine whether they may be affected?

Review whether managed clusters can perform delta-sync UPDATE or DELETE operations and whether those operations validate that each UID belongs to the calling cluster. Systems where caller ownership is not enforced for UID prefixes may be affected.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203