HIGH 7.1

CVE-2026-10840: OpenShift Pipelines Operator RBAC Misconfiguration – Unauthorized Workload & Certificate Access

A misconfiguration in the OpenShift Pipelines operator allows any authenticated user on a cluster to gain unauthorized control over workload scheduling and certificate management. The tekton-scheduler-rolebinding grants excessive permissions to all authenticated users, enabling them to disrupt job scheduling, alter priorities, delete other users' workloads, or manipulate TLS certificates—including those protecting ingress controllers. This is a privilege escalation issue that turns cluster authentication into a foothold for operational sabotage.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.1 HIGH · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
Weaknesses (CWE)
CWE-732
Affected products
0 configuration(s)
Published / Modified
2026-06-04 / 2026-06-30

NVD description (verbatim)

A flaw was found in the OpenShift Pipelines operator. The tekton-scheduler-rolebinding ClusterRoleBinding grants the system:authenticated group write access to Kueue and cert-manager custom resources via the tekton-scheduler-role ClusterRole. When Kueue or cert-manager CRDs are present on the cluster, any authenticated user can disrupt workload scheduling, tamper with scheduling priorities, delete other tenants' Workload objects, or induce cert-manager to overwrite TLS Secrets including the default ingress controller certificate.

5 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-10840 involves an overly permissive ClusterRoleBinding (tekton-scheduler-rolebinding) that associates the tekton-scheduler-role ClusterRole with the system:authenticated group. This grants write access to Kueue and cert-manager custom resources. Any user with valid cluster credentials can invoke write operations on these CRDs, manipulating workload scheduling behavior, modifying Workload objects belonging to other tenants, or triggering cert-manager to overwrite TLS Secrets. The vulnerability stems from CWE-732 (Incorrect Permission Assignment), where the role scope is too broad relative to the principle of least privilege.

Business impact

Operational continuity is at risk. Authenticated attackers can delay or prevent legitimate workloads from executing, starve critical applications of resources by manipulating scheduling priorities, or erase other teams' job definitions. Additionally, TLS certificate tampering—especially overwriting ingress controller certificates—can break external service access, trigger SSL errors for end users, and potentially enable man-in-the-middle attacks. In multi-tenant environments, this enables cross-tenant interference and data exposure.

Affected systems

OpenShift Pipelines operator installations are affected. The vulnerability manifests only when Kueue or cert-manager CRDs are present on the cluster. Organizations running OpenShift with Pipelines, Kueue for workload management, and cert-manager for certificate automation are at highest risk. Single-tenant or isolated lab clusters without these components are not exposed to the full impact.

Exploitability

Exploitability is straightforward for any authenticated cluster user. No special elevation, complex exploitation chains, or zero-days are required—the attacker simply needs valid credentials (PR:L). The attack is network-accessible (AV:N) and requires no user interaction (UI:N). Attack complexity is low (AC:L). The primary barrier is cluster authentication; once inside, the abuse is trivial. Organizations using OpenShift with default RBAC and broad authentication groups amplify risk.

Remediation

Remove or restrict the overly permissive tekton-scheduler-rolebinding. Audit the tekton-scheduler-role to limit write access to Kueue and cert-manager CRDs only to dedicated service accounts that legitimately manage scheduling. Apply the principle of least privilege by binding the role only to specific ServiceAccounts rather than system:authenticated. Verify that cert-manager secrets are protected via additional RBAC rules and that scheduling decisions cannot be overwritten by untrusted users. Monitor cluster events for unauthorized Workload deletions or Secret modifications.

Patch guidance

Consult the OpenShift Pipelines operator release notes and Red Hat security advisories for patched versions. Verify the vendor advisory for explicit version numbers and update timelines. In the interim, implement manual RBAC corrections: recreate the tekton-scheduler-rolebinding to reference only necessary ServiceAccounts, or delete it entirely if Pipelines does not require cluster-wide scheduler role access. Test changes in a non-production environment first to ensure scheduling operations continue as expected.

Detection guidance

Monitor Kubernetes audit logs for write operations on Kueue Workload objects or cert-manager Certificate/Secret resources initiated by users outside the system:serviceaccount:* namespace. Watch for rapid deletions of Workload objects or unexpected modifications to TLS Secrets, particularly ingress-related certificates. Set up alerts on ClusterRoleBinding changes involving system:authenticated. Review RBAC policies regularly and cross-reference with your Pipelines deployment to catch misconfigurations. Use tools like kubectl auth can-i to simulate whether unexpected users can write to these resources.

Why prioritize this

HIGH severity (CVSS 7.1) reflects significant availability and integrity risk. While confidentiality is not directly impacted, the ability to disrupt scheduling, delete workloads, and tamper with certificates creates widespread operational harm. In production environments running multi-tenant Pipelines workloads, prioritize remediation within 2–4 weeks. The low barrier to exploitation (any authenticated user) and the cluster-scoped nature of the vulnerability elevate urgency, especially if Kueue and cert-manager are actively used.

Risk score, explained

The CVSS 3.1 score of 7.1 (HIGH) is driven by: (1) Low attack complexity and no required user interaction, making exploitation trivial once authenticated; (2) Integrity impact via Workload and Secret manipulation, causing data loss or service misconfiguration; (3) High availability impact from workload deletion and scheduling disruption; (4) Network accessibility broadens the threat surface; (5) Low privileges required—any authenticated user qualifies. The impact is scoped to the local system (S:U), as the attack does not break out of the cluster, but the effects are severe enough to warrant priority remediation in production.

Frequently asked questions

Do we need Kueue and cert-manager installed for this vulnerability to matter?

Yes and no. The vulnerability exists in the OpenShift Pipelines operator regardless, but the stated impact—workload manipulation and certificate tampering—only manifests if Kueue and/or cert-manager CRDs are present. If your cluster runs Pipelines without these components, the excessive RBAC binding is still a configuration flaw, but the attack surface is narrower. Audit your cluster inventory to know your exposure.

If we restrict cluster access to a small group of trusted admins, are we safe?

Partially. If your authentication policy already restricts the system:authenticated group to a handful of trusted engineers, the risk is lower—but not eliminated. The vulnerability principle remains: the operator grants permissions that shouldn't exist. A misconfigured identity provider, a compromised service account, or a rogue insider still poses a threat. Fix the root cause by adjusting RBAC, don't rely on perimeter defense alone.

Will patching break our existing Pipelines workflows?

Unlikely, but verify. Patches will tighten RBAC to bind the scheduler role only to necessary ServiceAccounts. If your Pipelines workflows already use dedicated service accounts (the recommended practice), you'll see no disruption. If workflows depend on arbitrary authenticated users manipulating Kueue objects directly, they may break—a sign that your configuration was insecure anyway and needs redesign.

How quickly should we apply a patch once it's available?

Given the HIGH severity and low barrier to exploitation, target 2–4 weeks for production environments. If you're in a tightly controlled single-tenant lab, the timeline can be longer. For any cluster exposed to multiple internal teams or external contractors, prioritize faster. The fix is likely a YAML reconfiguration, not a risky operator upgrade, so the change risk is low.

This analysis is based on published vulnerability data and general Kubernetes security practices. Verify all patch version numbers, timelines, and specific workarounds against official Red Hat and OpenShift security advisories before implementation. The severity and exploitability of CVE-2026-10840 depend on your cluster configuration, authentication setup, and presence of Kueue and cert-manager. Conduct your own risk assessment in your environment. SEC.co does not provide warranty for the accuracy of third-party vendor information or guarantee that patches will resolve the issue in all deployments. Always test remediation in a non-production environment first. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).