CVE-2026-70496: search-v2-operator Privilege Escalation

CVE-2026-70496 Overview

CVE-2026-70496 is a privilege management flaw affecting the search-v2-operator, a Kubernetes operator used within Red Hat Advanced Cluster Management environments. The operator ships with a ClusterRole that grants permissions equivalent to a cluster administrator. These permissions include the ability to impersonate other entities, modify Role-Based Access Control (RBAC) configurations, approve Certificate Signing Requests (CSRs), and manage ManifestWork resources. An attacker who compromises the operator's service account can escalate privileges across the entire cluster. The issue is tracked as [CWE-250: Execution with Unnecessary Privileges].

Critical Impact
Compromise of the search-v2-operator service account allows an attacker to assume cluster-admin authority, forge identities, and manipulate RBAC to persist inside the Kubernetes control plane.

Affected Products

Red Hat search-v2-operator
Kubernetes clusters deploying the operator via Red Hat Advanced Cluster Management
Downstream distributions that inherit the operator's default ClusterRole bindings

Discovery Timeline

2026-08-19 - CVE-2026-70496 published to NVD
2026-08-20 - Last updated in NVD database

Technical Details for CVE-2026-70496

Vulnerability Analysis

The search-v2-operator is designed to index and query Kubernetes resources across managed clusters. To perform its function, it requires read access to cluster state. However, the shipped ClusterRole grants far more than read access. It includes verbs and resources that unlock full administrative control of the cluster. The flaw is a violation of the principle of least privilege, categorized under [CWE-250].

An attacker who gains code execution inside the operator pod, or who otherwise obtains its bound service account token, inherits every permission the ClusterRole grants. Because the role permits impersonation, the attacker can act as any user or service account in the cluster. Because it permits RBAC writes, the attacker can create persistent backdoor bindings. Because it permits CSR approval, the attacker can mint client certificates trusted by the API server.

Root Cause

The root cause is an overly permissive ClusterRole manifest bundled with the operator. Rules should have been scoped to the specific resources the operator reads and writes. Instead, the role includes broad verbs such as impersonate, create, update, and approve on sensitive resources including users, groups, serviceaccounts, rolebindings, clusterrolebindings, certificatesigningrequests/approval, and manifestworks.

Attack Vector

Exploitation requires that an attacker already hold some level of access to the cluster. Access to the operator's namespace, or the ability to schedule workloads that mount its service account token, is sufficient. From there, the attacker uses kubectl --as style impersonation or direct API calls with the operator token to assume administrative identities. The attacker then creates a ClusterRoleBinding granting a controlled principal cluster-admin and approves a forged CSR to obtain long-lived credentials. Full technical background is available in the Red Hat CVE-2026-70496 Advisory and Red Hat Bugzilla Report #2511032.

// No verified proof-of-concept code is published for this issue.
// See the Red Hat advisory linked above for technical details.

Detection Methods for CVE-2026-70496

Indicators of Compromise

Kubernetes audit log entries where user.username equals system:serviceaccount:<ns>:search-v2-operator and the verb is impersonate, escalate, or bind.
Creation of new ClusterRoleBinding or RoleBinding objects sourced from the operator's service account.
Approval events on certificatesigningrequests/approval originating from the operator.
Unexpected ManifestWork objects targeting managed clusters outside the operator's normal workflow.

Detection Strategies

Enable Kubernetes API audit logging at RequestResponse level for RBAC, CSR, and impersonation verbs.
Alert on any use of the Impersonate-User or Impersonate-Group headers by workload service accounts.
Baseline the operator's normal API call pattern and flag deviations, especially write verbs on identity resources.

Monitoring Recommendations

Ship Kubernetes audit logs to a centralized analytics platform and retain them for at least 90 days.
Continuously enumerate ClusterRoleBinding and RoleBinding objects and diff against a known-good baseline.
Monitor CSR approvals and correlate approver identity with expected automation accounts.

How to Mitigate CVE-2026-70496

Immediate Actions Required

Inventory clusters running search-v2-operator and review the bound ClusterRole for the verbs listed in the advisory.
Restrict access to namespaces hosting the operator and prevent untrusted workloads from mounting its service account token.
Rotate any service account tokens and client certificates that may have been exposed.
Audit RBAC bindings and CSR approvals for unauthorized changes since the operator was deployed.

Patch Information

Red Hat is tracking remediation through the Red Hat CVE-2026-70496 Advisory. Apply the vendor-provided update that replaces the operator's ClusterRole with a least-privilege equivalent as soon as it becomes available in your channel.

Workarounds

Manually edit the operator's ClusterRole to remove impersonate, escalate, bind, RBAC write verbs, and CSR approval verbs where the operator does not require them.
Apply a Kubernetes admission policy such as Kyverno or OPA Gatekeeper to deny creation of ClusterRoleBindings initiated by the operator service account.
Isolate the operator on dedicated nodes and enforce network policies that limit egress to the API server only.

bash

# Inspect the ClusterRole bound to the operator's service account
kubectl get clusterrolebinding -o json \
  | jq '.items[] | select(.subjects[]?.name=="search-v2-operator") | {name:.metadata.name, roleRef:.roleRef}'

# Review the rules granted by the referenced ClusterRole
kubectl get clusterrole <role-name> -o yaml