CVE-2026-55226: Strimzi Privilege Escalation Vulnerability

CVE-2026-55226 Overview

CVE-2026-55226 affects Strimzi, the open-source project that runs Apache Kafka clusters on Kubernetes and OpenShift. In Strimzi 1.0.0 and earlier, deploying only the Topic Operator or only the User Operator through the Kafka custom resource leaves the shared Entity Operator ServiceAccount with role-based access control (RBAC) permissions for both components. The excess permissions can grant access to KafkaUser custom resources and Secrets when the User Operator is absent, or access to KafkaTopic custom resources when the Topic Operator is absent. The issue is classified as improper privilege management [CWE-269] and is fixed in Strimzi versions 1.0.1 and 1.1.0.

Critical Impact
A workload sharing the Entity Operator ServiceAccount can read or manipulate Kafka user credentials, Secrets, or topic configurations that the deployed operator was never intended to manage.

Affected Products

Strimzi Kafka Operator 1.0.0 and earlier
Kubernetes deployments using the Strimzi Kafka custom resource with only Topic Operator configured
OpenShift deployments using the Strimzi Kafka custom resource with only User Operator configured

Discovery Timeline

2026-09-15 - CVE-2026-55226 published to the National Vulnerability Database (NVD)
2026-09-16 - Last updated in NVD database
Fixes released in Strimzi versions 1.0.1 and 1.1.0 via Strimzi Pull Request #12844

Technical Details for CVE-2026-55226

Vulnerability Analysis

Strimzi provisions an Entity Operator pod that can host the Topic Operator, the User Operator, or both. The ServiceAccount attached to the Entity Operator pod historically received the union of RBAC permissions required for both operators. When operators only deploy one of the two components through the Kafka custom resource, the ServiceAccount still carries the permissions of the missing component. This violates least-privilege and creates a lateral access path from the running container to Kubernetes resources it should not touch.

An adversary with adjacent network access and access to the Entity Operator pod, its token, or a colocated workload can enumerate and modify KafkaUser or KafkaTopic custom resources and read the Secrets that store SCRAM credentials or TLS material for Kafka users.

Root Cause

The root cause is improper privilege management [CWE-269] in the Entity Operator deployment model. The cluster operator generated a single Role and RoleBinding covering both sub-operators regardless of which sub-operator was declared in the Kafka custom resource. The fix introduces a STRIMZI_ENTITY_OPERATOR_WATCHED_NAMESPACE_ENABLED configuration flag and separates the permission surfaces for the Topic Operator and User Operator.

Attack Vector

Exploitation requires adjacent network access, low privileges within the cluster, and no user interaction. An attacker who compromises the Entity Operator container, or a pod that can assume its ServiceAccount token, can call the Kubernetes API to list or modify custom resources belonging to the absent operator. Where the User Operator is absent, this includes reading Secret objects containing Kafka user credentials.

java

// Patch: introduce a config flag that gates the watched-namespace permission set
// Source: https://github.com/strimzi/strimzi-kafka-operator/commit/b3bfeffcc30754c3e62e6f4afd8a76942cac440d
public static final ConfigParameter<Boolean> POD_DISRUPTION_BUDGET_GENERATION =
    new ConfigParameter<>("STRIMZI_POD_DISRUPTION_BUDGET_GENERATION", BOOLEAN, "true", CONFIG_VALUES);

/**
 * Set true to enable watched namespace feature for Entity Operators (Topic Operator and User Operator)
 */
public static final ConfigParameter<Boolean> ENTITY_OPERATOR_WATCHED_NAMESPACE_ENABLED =
    new ConfigParameter<>("STRIMZI_ENTITY_OPERATOR_WATCHED_NAMESPACE_ENABLED", BOOLEAN, "false", CONFIG_VALUES);

Detection Methods for CVE-2026-55226

Indicators of Compromise

Kubernetes audit log entries showing the Entity Operator ServiceAccount performing get, list, create, update, or delete on KafkaUser resources when only the Topic Operator is deployed.
Audit log entries showing the same ServiceAccount performing operations on KafkaTopic resources when only the User Operator is deployed.
Reads of Secret objects holding Kafka user SCRAM or TLS material by the Entity Operator ServiceAccount in namespaces where the User Operator is not configured.

Detection Strategies

Inventory every Strimzi Kafka custom resource and compare the declared spec.entityOperator sub-components against the Role and RoleBinding attached to the corresponding -entity-operator ServiceAccount.
Run RBAC review commands such as kubectl auth can-i --as=system:serviceaccount:<ns>:<cluster>-entity-operator <verb> <resource> for both kafkatopics.kafka.strimzi.io and kafkausers.kafka.strimzi.io to confirm expected privileges.
Alert on any Kubernetes API activity from the Entity Operator ServiceAccount targeting resources outside its configured sub-operator scope.

Monitoring Recommendations

Enable Kubernetes API server audit logging at RequestResponse level for kafka.strimzi.io resources and namespace-scoped Secret reads.
Forward audit logs and container runtime telemetry to a centralized analytics tier and correlate ServiceAccount identity with the declared Kafka custom resource state.
Track Strimzi cluster operator versions across clusters and alert when any deployment remains on 1.0.0 or earlier.

How to Mitigate CVE-2026-55226

Immediate Actions Required

Upgrade the Strimzi cluster operator to version 1.0.1 or 1.1.0 and allow it to reconcile existing Kafka custom resources so the corrected RBAC is applied.
Rotate Kafka user credentials and any Secrets referenced by KafkaUser resources in clusters where only the Topic Operator was deployed.
Audit Kubernetes API server logs for prior access to KafkaUser, KafkaTopic, or Secret objects by the Entity Operator ServiceAccount.

Patch Information

The fix is available in Strimzi Release 1.0.1 and Strimzi Release 1.1.0. The code changes are described in the Strimzi Security Advisory GHSA-r427-j2h7-wv3m and implemented in commit b3bfeff and commit f6c5207.

Workarounds

Deploy both the Topic Operator and the User Operator so the granted RBAC matches the running components, eliminating the excess-permission gap until the patch is applied.
Apply a Kubernetes NetworkPolicy that restricts pod-to-API-server traffic and limits which workloads can share a node with the Entity Operator pod.
Manually replace the Entity Operator Role with a scoped Role that grants only the permissions required by the deployed sub-operator.

bash

# Verify Strimzi cluster operator version and Entity Operator RBAC scope
kubectl -n kafka get deployment strimzi-cluster-operator \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

# List effective permissions of the Entity Operator ServiceAccount
kubectl -n kafka get rolebinding -o json | \
  jq '.items[] | select(.subjects[]?.name | test("-entity-operator$"))'

# Confirm the ServiceAccount cannot access resources for the absent operator
kubectl auth can-i get kafkausers.kafka.strimzi.io \
  --as=system:serviceaccount:kafka:my-cluster-entity-operator -n kafka
kubectl auth can-i get secrets \
  --as=system:serviceaccount:kafka:my-cluster-entity-operator -n kafka