Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-10533

CVE-2026-10533: OpenShift Container Platform DoS Vulnerability

CVE-2026-10533 is a denial of service flaw in OpenShift Container Platform where non-privileged users can exploit pod creation to flood etcd with events, degrading API server performance. This article covers technical details, impact, and mitigation.

Published:

CVE-2026-10533 Overview

CVE-2026-10533 affects Red Hat OpenShift Container Platform. The flaw allows a non-privileged user with pod creation rights in a namespace to bypass ResourceQuota pod limits. Completed pods configured with restartPolicy: Never do not count toward quota enforcement. Kubernetes events generated by these pods are not quota-scoped either. An attacker can use this gap to generate a high volume of events that accumulate in etcd. The resulting storage and processing load degrades API server performance across the entire cluster. The issue is classified under [CWE-770] (Allocation of Resources Without Limits or Throttling).

Critical Impact

A low-privileged tenant in one namespace can exhaust etcd resources and degrade Kubernetes API server performance for every workload in the cluster.

Affected Products

  • Red Hat OpenShift Container Platform
  • Workloads relying on ResourceQuota to limit pod counts per namespace
  • Multi-tenant Kubernetes clusters using OpenShift

Discovery Timeline

  • 2026-06-01 - CVE-2026-10533 published to NVD
  • 2026-06-01 - Last updated in NVD database

Technical Details for CVE-2026-10533

Vulnerability Analysis

The vulnerability is a resource exhaustion flaw in how OpenShift accounts for pods and Kubernetes events. ResourceQuota objects enforce limits on active resources within a namespace. When a pod with restartPolicy: Never reaches a terminal phase such as Succeeded or Failed, the quota controller stops counting it against the namespace's pod limit. The pod object continues to exist in etcd, and its lifecycle still produces Kubernetes events. These events are stored cluster-wide and are not subject to per-namespace quota controls.

An attacker repeatedly creating short-lived pods can therefore produce an unbounded number of event records. Each event consumes etcd storage and triggers watch notifications across controllers. As event volume grows, the API server spends increasing CPU and I/O resources serving list and watch requests. Cluster-wide latency rises and scheduling, controller reconciliation, and admission decisions slow for all tenants.

Root Cause

The root cause is missing throttling on a resource that the quota system does not track. Completed pods are excluded from pod-count quota, and events have no quota object that limits their creation rate per principal or namespace. Together these two design choices allow a single low-privilege identity to generate persistent load on shared infrastructure.

Attack Vector

The attacker requires only authenticated access to the cluster and the create pods permission in a single namespace. The attacker scripts a loop that creates pods with restartPolicy: Never and a short-running command. Each pod completes, frees its slot in the pod quota, and produces multiple lifecycle events. Repeating the loop at high rate inflates the event store in etcd and degrades API server responsiveness for the entire cluster.

No verified public exploit code is available. See the Red Hat CVE-2026-10533 Advisory and Red Hat Bug Report #2483727 for vendor technical details.

Detection Methods for CVE-2026-10533

Indicators of Compromise

  • Sustained high creation rate of pods with restartPolicy: Never from a single service account or user.
  • Rapid growth of the Kubernetes event count in etcd and rising etcd database size.
  • Increasing API server request latency and etcd request duration metrics without a corresponding workload change.
  • Large numbers of Succeeded or Failed pods in one namespace within a short interval.

Detection Strategies

  • Audit kube-apiserver logs for repeated create requests against the pods resource from the same subject in a short window.
  • Alert on anomalous spikes in etcd_object_counts{resource="events"} and apiserver_storage_objects{resource="events"}.
  • Correlate event creation rate with pod completion rate per namespace to identify abusive patterns.

Monitoring Recommendations

  • Track etcd database size, compaction duration, and apiserver_request_duration_seconds to detect performance degradation early.
  • Monitor per-namespace pod churn and flag namespaces creating short-lived pods at rates above a defined baseline.
  • Forward Kubernetes audit logs to a centralized analytics platform for behavioral baselining of pod and event creation.

How to Mitigate CVE-2026-10533

Immediate Actions Required

  • Apply Red Hat patches for OpenShift Container Platform as they become available through the Red Hat CVE-2026-10533 Advisory.
  • Review RBAC and restrict the create pods verb to identities that require it, especially in shared or untrusted namespaces.
  • Investigate namespaces showing abnormal pod or event creation patterns and revoke credentials if abuse is confirmed.

Patch Information

Refer to the Red Hat CVE-2026-10533 Advisory for the list of fixed OpenShift Container Platform releases and the upstream Kubernetes changes that adjust quota accounting for completed pods and event throttling.

Workarounds

  • Enforce stricter LimitRange and admission policies to cap pod creation rates per namespace using tools such as Kyverno or OPA Gatekeeper.
  • Reduce the --event-ttl value on the API server so events expire faster and consume less etcd storage.
  • Apply API priority and fairness (APF) flow schemas to throttle high-frequency pod creation by low-priority service accounts.
  • Isolate untrusted tenants in separate clusters or virtual clusters to limit blast radius against shared etcd.
bash
# Example: limit pod create rate for a low-trust service account via APF FlowSchema
kubectl apply -f - <<EOF
apiVersion: flowcontrol.apiserver.k8s.io/v1
kind: FlowSchema
metadata:
  name: throttle-untrusted-pod-creates
spec:
  matchingPrecedence: 100
  priorityLevelConfiguration:
    name: catch-all
  rules:
  - subjects:
    - kind: ServiceAccount
      serviceAccount:
        name: tenant-sa
        namespace: tenant-a
    resourceRules:
    - verbs: ["create"]
      apiGroups: [""]
      resources: ["pods"]
EOF

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.